Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 06 Dec 2019, 23:56
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Announcements
boycott systemd
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 23 of 26 [384 Posts]   Goto page: Previous 1, 2, 3, ..., 21, 22, 23, 24, 25, 26 Next
Author Message
James C


Joined: 26 Mar 2009
Posts: 6734
Location: Kentucky

PostPosted: Thu 25 Jun 2015, 01:09    Post subject:  

A bit more from Linus on kdbus ......

http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05492.html

Quote:
We don't merge kernel code just
because user space was written by a retarded monkey on crack. Kernel
code has higher standards.........
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3384
Location: The Blue Marble

PostPosted: Thu 25 Jun 2015, 06:50    Post subject:  

Long post ... sorry, can't resist.

Another post from the same thread is also enlightening - how the systemd team is putting pressure to accept the kdbus patch ASAP with no regards for quality or review.

http://lkml.iu.edu/hypermail/linux/kernel/1506.2/04958.html
Martin Steigerwald wrote:
I hope you kernel developers will still review kdbus carefully as you did so
far, instead of giving in to any downstream pressure by distros.

It is exactly this attitude and this approach of systemd upstream that I
feel uneasy about. Instead of humbly waiting and working towards having
kdbus accepted to the kernel, systemd developers seem to use any means to
create indirect pressure to have it included eventually.

I hope that it will still be technical excellence as entry barrier for
anything that goes into the kernel.

Please note: I do not judge upon the technical quality of kdbus. I think
others are more knowledgeable to do it.


And here is the Andy (original poster of the thread) confirms that his was moved to raise the question exactly because systemd people pushed it that way:
http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05233.html
Andy Lutomirski wrote:
FWIW, once there are real distros with kdbus userspace enabled,
reviewing kdbus gets more complicated -- we'll be in the position
where merging kdbus in a different form from that which was proposed
will break existing users.


In other words, trying to force fait accompli on the kernel developers TO GET IT IN QUICK QUICK RIGHT NOW, regardless of various design and implementation issues - future issues and forward compatibility be damned! You wonder why? Wink

Very typical of systemd people.

If you read comments from other sites about this, it is very enlightening - anyone who questions kdbus will get mocked, insulted, called as a luddite, anti-progress, told to write-your-own-IPC-stuff, told as holding Linux back --- while *NEVER* addressing the issues being raised (such as, code quality, API attack surface, exposition of unnecessary kernel stuff, and host of other stuff, dumping of large patches that cannot be reviewed properly because it touches many part of the kernels at once, etc). Basically - not good engineering. Yet, systemd people still want to get it merged *RIGHT NOW* (actually yesterday, as they already shipped systemd with kdbus support enabled *THAT CANNOT BE DISABLED* unless you patch the source yourself), ignoring all these issues.

Exactly how systemd pushed its way to be "included in most distros" in the first place.

It's very sad to see that technical decisions are being pushed to be made not by technical and engineering merits but by pressure, insults, and various bullying tactics. If this gets to Linux kernel that would be the end of it Shocked

Lastsly, I have a lot of respect for GKH (Greg Koah Hartmann) - he is effectively Linus's right-hand man, and he is the LTS kernel maintainer, but his response (http://lkml.iu.edu/hypermail/linux/kernel/1506.2/04860.html) and position on this matter is indefensible and shows a very bad personal bias. Greg is personally involved with kdbus - he is one of the developers of kdbus (or at least manage the people who does it - you know, people like Kay Sievers - if that doesn't make you shudder, what will), so perhaps that's just a mother hen protecting his baby, but being in the position he is, he should *NOT* apply a different standard to his (or his team) own works vs the standard he applies to anybody else.

Unfortunately, Linus kind of handwaved through this. This is obvious from his unusually toned down response. He lashes at kdbus freely, and his only reason still wanting to do it is because GKH recommends it - yet he keeps silent about GKH himself. Linus hands are tied, perhaps because GKH is his most trusted lieutenant and his *publicly named* successor too (see: http://www.theregister.co.uk/2015/06/17/now_i_can_die_happy_what_linus_didnt_iquitei_say/); so he can't just throw out his weight like he usually does. But when the crown prince makes a basic mistake like this, the king must dicipline him, otherwise the history has told us what will happen after the king abdicates ....

_________________
Fatdog64 forum links: Latest version | Contributed packages | ISO builder
Back to top
View user's profile Send private message 
bark_bark_bark

Joined: 05 Jun 2012
Posts: 1935
Location: Wisconsin USA

PostPosted: Thu 25 Jun 2015, 07:23    Post subject:  

If any systemd code made it into linux, you know it's time to switch to FreeBSD.
_________________
....
Back to top
View user's profile Send private message 
greengeek


Joined: 20 Jul 2010
Posts: 5624
Location: Republic of Novo Zelande

PostPosted: Thu 25 Jun 2015, 15:15    Post subject:  

jamesbond wrote:
But when the crown prince makes a basic mistake like this, the king must dicipline him, otherwise the history has told us what will happen after the king abdicates ....
Probably already too late. The core functionality of recent Linux offerings is probably deeply contaminated and compromised. These efforts towards making it more centralised and Windows-like reveal a higher agenda as far as i can see. Well out of Torvalds hands by now I suspect.
Back to top
View user's profile Send private message 
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Fri 26 Jun 2015, 07:00    Post subject:  

Well, I have always liked the idea of having a more accessible from the shell IPC system, since pretty much all that is there by default is 'named pipes'. And perhaps having a more sophisticated IPC merged into the kernel itself, will allow all sorts of security and perfomance improvements and the ability to transfer large amounts of data via the IPC mechanism. However... dbus has been around for around ten years and kdbus is to a large extent based on dbus albeit not in 'user-space'.

Trouble is, mere mortals have no chance of understanding how to interface to dbus (or kbus for that matter) since these use object oriented models which are alien to the typical old-fashioned C or shell-script programmer (such as myself) - that is my main concern - I can't imagine ever being able to write programs that 'talk' via dbus... Maybe there are people on this forum who can do that - I fear that I will never be one of them and that takes a lot of fun out of programming in Linux (which for the most part has been relatively simple). I suspect I am just old-fashioned and the skills I do have are destined for extinction.

Aside from these practical concerns, I have no particular opinion about systemd or kdbus or grub2 for that matter - they are all alien to what I know, but I can see where they are coming from but its a foreign language to me. I remember reading a bit about 'COM' a long time ago, and it was all just crazy impossible stuff, so thank goodness for the relative simplicity of shell scripting, gtkdialog (and even gtk programming itself) and, to me, wonderful C (cryptic but pretty simple really)! All that OO stuff, on that large IPC scale, leaves the programming to a few 'geniuses', which is sad and more than a trifle boring for those of us who enjoy playing with old-fashioned UNIX programming philosophy.

William

_________________
github mcewanw
Back to top
View user's profile Send private message Visit poster's website 
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Fri 26 Jun 2015, 07:58    Post subject:  

Now, this is the kind of post I do like. This is UNIX-philosophy type thinking as far as I see it:

https://blogs.gnome.org/uraeus/2015/04/16/kdbus-discussion/


Quote:

Joe
April 18, 2015 at 5:18 pm

No. Kdbus does not need to be tied to the design of dbus to implement dbus in userspace. The kernel does not understand HTTP or websockets, but we can use it just fine. Why? Because the bits than should be in the kernels are (though even that could be reduced). This is about changing the implementation of dbus to take advantage of some future kernel ipc mechanism, and for that the kernel does not need to understand dbus. Instead, the model (which should be much simpler than dbus) should have the building blocks needed for dbus and preferably also other ipc mechanisms.

Even if this only benefits dbus, having the kernel side of things be simple helps maintainability tremendously because ipc systems are not standalone things like drivers. The design affects how you can build containers and what security mechanisms you can provide (at the very least. I’m sure there’s more).


Okay, systemd and kdbus are separate items, albeit being bonded together. I suspect similar comments to the above post could be made about the systemd approach itself, but I'm just guessing.

EDIT: it is a pity perhaps, I feel, that the AF_BUS was rejected some time back. I probably could have understood and used that for simpler IPC needs - but then again, maybe not... IPv4 sockets are about my limit:

https://lwn.net/Articles/504970/

William

_________________
github mcewanw
Back to top
View user's profile Send private message Visit poster's website 
greengeek


Joined: 20 Jul 2010
Posts: 5624
Location: Republic of Novo Zelande

PostPosted: Fri 26 Jun 2015, 14:50    Post subject:  

mcewanw wrote:
All that OO stuff, on that large IPC scale, leaves the programming to a few 'geniuses', which is sad and more than a trifle boring for those of us who enjoy playing with old-fashioned UNIX programming philosophy.
I think the strength of Linux has been the ease with which "ordinary" programmers such as yourself can access, scrutinise and improve the code. Moving the system code into the hands of the 'geniuses' you mentioned carries the risk of removing scrutiny and requiring complete trust from the rest of us. Just like Microsoft code does. If the code is not readily understandable and accessible it becomes more or less the same thing as proprietary code.
Back to top
View user's profile Send private message 
James C


Joined: 26 Mar 2009
Posts: 6734
Location: Kentucky

PostPosted: Sat 27 Jun 2015, 02:55    Post subject:  

Devuan Jessie x86-64.

https://devuan.org/

Code:
james@nosystemd:~$ uname -a
Linux nosystemd 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux
james@nosystemd:~$


Code:
james@nosystemd:~$ cat /proc/1/comm
init
Devuan Jessie x86-64.jpg
 Description   
 Filesize   35.48 KB
 Viewed   888 Time(s)

Devuan Jessie x86-64.jpg

Back to top
View user's profile Send private message 
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Sun 28 Jun 2015, 03:16    Post subject:  

greengeek wrote:
the strength of Linux


For me, the longevity of UNIX more generally comes from the simple use of text files for most configuration purposes. Most shell utilities are thus text processors of one sort or another, which are made so very powerful through the relatively simple concepts of pipes and redirects and the implemention of stardard input, output and error devices and so on.

Okay, so XML is generally a specially formatted text file, which is also human-readable, but conceptually such configurations tend to come along with a great deal of technically difficult baggage, since the XML text is itself but a small part of the overall story. Perhaps it could be argued that such structure helps produce standards, which it does in a way. However, I fear that comes at the cost of great complexity overall and loss of flexibility and simple elegance. Next thing we know, bash and sh more generally will be relegated to antiquity and some new object-oriented Linux Powershell will become the standard; wonderful I suppose... but despite its quirkiness, the typical UNIX shell is a fun environment and incredibly powerful and so close in operation and programming philosophy to the C structures and libraries that were used to create it and underly it all. We don't need to copy Microsoft's way of doing things.

William

_________________
github mcewanw
Back to top
View user's profile Send private message Visit poster's website 
peebee


Joined: 21 Sep 2008
Posts: 4089
Location: Worcestershire, UK

PostPosted: Sat 21 Nov 2015, 05:22    Post subject: Slackware moves to eudev  

http://www.slackware.org.uk/slackware/slackware-current/ChangeLog.txt
slackware wrote:
Fri Nov 20 05:25:18 UTC 2015
We've made the switch from udev to eudev, and everything seems to be working
perfectly. Big thanks to the eudev team for helping us bring Slackware's
udev up to date!

http://alien.slackbook.org/blog/slackware-live-edition/
Alien wrote:
With the abandoned ConsoleKit replaced by ConsoleKit2 which is actively maintained by the Slackware-friendly XFCE crew, and Gentoo’s eudev taking the place of udev, we are well equipped to keep systemd out of our distro for a while. Basically eudev contains the udev code as found in the systemd sources, but then stripped from all standards-violating systemd crap and with a sane build system. Hooray, we’re back in business and eudev gained some more traction. Win-win.

_________________
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Back to top
View user's profile Send private message Visit poster's website 
oui

Joined: 20 May 2005
Posts: 3499
Location: near Woof (Germany) :-) - 3 PC's: DELL SX280 750 MB Pentium4, Acer emachines 2 GB AMD64. DELL XPS15

PostPosted: Sat 21 Nov 2015, 05:38    Post subject:  

James C wrote:
Devuan Jessie x86-64.

https://devuan.org/

Code:
james@nosystemd:~$ uname -a
Linux nosystemd 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux
james@nosystemd:~$


Code:
james@nosystemd:~$ cat /proc/1/comm
init


my experience is that you don't need some devuan to avoid systemD in jessie but very well now if you want to do that in SID Rolling Eyes

but I don't see some depository for dev1 + SID now

next problem is that debian creates installations isos with "live" and not with the most modern ubuntu's casper. and you can continue that very unpleasant constatation along the all line debian / ubuntu: all ubuntu derivates use casper. the debian ones not!
Back to top
View user's profile Send private message 
01micko


Joined: 11 Oct 2008
Posts: 8736
Location: qld

PostPosted: Sat 21 Nov 2015, 07:46    Post subject:  

Code:
testing/packages/eudev-3.1.5-i586-1.txz: Added.
Thanks to Jean-Philippe Guillemin.
Expect problems (especially with an initrd) unless everything depending upon
libudev.so.0 is recompiled. Those packages include: ConsoleKit2,
ModemManager, NetworkManager, aaa_elflibs, bluez, dhcpcd, gutenprint, gvfs,
intel-gpu-tools, kde-workspace, kdelibs, libatasmart, libcanberra, libgphoto2,
libgpod, libmbim, libmtp, libusb, libusb-compat, lvm2, network-manager-applet,
qt, sane, system-config-printer, udisks, udisks2, usbmuxd, usbutils,
util-linux, xf86-input-evdev, xf86-input-vmmouse, xf86-video-ati,
xf86-video-intel, xf86-video-modesetting, xf86-video-nouveau,
xf86-video-openchrome, and xorg-server.


and

http://www.slackware.com/changelog/

Code:
 Fri Nov 20 21:52:15 UTC 2015
a/eudev-3.1.5-i586-4.txz: Rebuilt.
       rc.udev: Don't update the hardware database index until / is read-write.
       Remove obsolete /lib/udev/udevd symlink.
a/udisks-1.0.5-i586-3.txz: Rebuilt.
       Eliminate redundant udev rule trying to call pci-db.
+--------------------------+
Fri Nov 20 05:25:18 UTC 2015
We've made the switch from udev to eudev, and everything seems to be working
perfectly. Big thanks to the eudev team for helping us bring Slackware's
udev up to date! Make sure you remove the old udev and install both of the
new packages (eudev and libgudev), and then the changeover to eudev should
go as smooth as silk. Really, the icu4c upgrade seemed more disruptive. :)
A reboot after this is probably better than "/etc/rc.d/rc.udev force-restart",
but that worked fine here, too. It would also be a good idea to regenerate
the initrd so that it uses eudev, but once again things worked fine here
either way. Have fun!
a/aaa_elflibs-14.2-i586-6.txz: Rebuilt.
a/etc-14.2-i586-4.txz: Rebuilt.
       Added input group, GID 71.
       Added SDDM user/group, UID 64, GID 64.
a/eudev-3.1.5-i586-3.txz: Added.
       This replaces the udev package.
       rc.udev: Fix mounting /dev/shm.
       rc.udev: Remove devtmpfs check.
       rc.udev: Remove persistent CD rules support.
       udev.conf: Remove obsolete udev_root setting.
       Patch 60-cdrom_id.rules to create alternate device names.
       Move system installed hwdb files under /lib.
       Remove obsolete udev_root references from the manpages, and install them.
       Thanks to Robby Workman.
a/libgudev-230-i586-1.txz: Added.
       This library is required to use eudev.
a/lvm2-2.02.134-i586-1.txz: Upgraded.
a/sysvinit-scripts-2.0-noarch-22.txz: Rebuilt.
       rc.S: Remove obsolete UMSDOS related error messages.
a/udev-182-i486-7.txz: Removed.
       This is replaced by the eudev and libgudev packages.
a/udisks-1.0.5-i586-2.txz: Rebuilt.
a/udisks2-2.1.5-i586-2.txz: Rebuilt.
a/usbutils-007-i586-3.txz: Rebuilt.
a/util-linux-2.26.2-i586-2.txz: Rebuilt.
ap/gphoto2-2.5.9-i586-1.txz: Upgraded.
ap/gutenprint-5.2.10-i586-2.txz: Rebuilt.
ap/hplip-3.15.11-i586-1.txz: Upgraded.
ap/nano-2.4.3-i586-1.txz: Upgraded.
ap/sqlite-3.9.2-i586-2.txz: Rebuilt.
ap/usbmuxd-1.1.0-i586-1.txz: Upgraded.
d/gcc-5.2.0-i586-2.txz: Rebuilt.
       Patched to fix problems with Wine (and possibly other things.)
       Thanks to Spinlock.
d/gcc-g++-5.2.0-i586-2.txz: Rebuilt.
d/gcc-gfortran-5.2.0-i586-2.txz: Rebuilt.
d/gcc-gnat-5.2.0-i586-2.txz: Rebuilt.
d/gcc-go-5.2.0-i586-2.txz: Rebuilt.
d/gcc-java-5.2.0-i586-2.txz: Rebuilt.
d/gcc-objc-5.2.0-i586-2.txz: Rebuilt.
d/mercurial-3.6.1-i586-1.txz: Upgraded.
       Renamed bash-completion file from mercurial to hg, otherwise it doesn't work.
       Thanks to Audrius Kazukauskas.
d/subversion-1.9.2-i586-3.txz: Rebuilt.
kde/calligra-2.9.9-i586-2.txz: Rebuilt.
kde/kde-workspace-4.11.22-i586-2.txz: Rebuilt.
kde/kdeconnect-kde-0.8-i586-3.txz: Rebuilt.
       Patched to fix problems with OpenSSH 7.x. Thanks to Eric Hameleers.
kde/kdelibs-4.14.14-i586-2.txz: Rebuilt.
kde/kig-4.14.3-i586-3.txz: Rebuilt.
l/ConsoleKit2-1.0.0-i586-3.txz: Rebuilt.
l/akonadi-1.13.0-i586-2.txz: Rebuilt.
l/apr-util-1.5.4-i586-2.txz: Rebuilt.
l/boost-1.59.0-i586-1.txz: Upgraded.
       Shared library .so-version bump.
l/gtk+3-3.18.5-i586-1.txz: Upgraded.
l/gvfs-1.26.2-i586-2.txz: Rebuilt.
l/harfbuzz-1.0.6-i586-1.txz: Upgraded.
l/icu4c-56.1-i586-1.txz: Upgraded.
       Shared library .so-version bump.
l/libatasmart-0.19-i586-2.txz: Rebuilt.
l/libcanberra-0.30-i586-3.txz: Rebuilt.
l/libgphoto2-2.5.9-i586-1.txz: Upgraded.
l/libgpod-0.8.3-i586-2.txz: Rebuilt.
l/libmtp-1.1.10-i586-1.txz: Upgraded.
l/libsoup-2.52.2-i586-2.txz: Rebuilt.
l/libusb-1.0.20-i586-1.txz: Upgraded.
l/libusb-compat-0.1.5-i586-2.txz: Rebuilt.
l/libvisio-0.1.3-i586-2.txz: Rebuilt.
l/qt-4.8.7-i586-2.txz: Rebuilt.
l/raptor2-2.0.15-i586-2.txz: Rebuilt.
l/system-config-printer-1.3.13-i586-2.txz: Rebuilt.
n/ModemManager-1.4.10-i586-2.txz: Rebuilt.
n/NetworkManager-1.0.6-i586-2.txz: Rebuilt.
n/bluez-4.101-i586-2.txz: Rebuilt.
n/dhcpcd-6.8.2-i586-2.txz: Rebuilt.
n/httpd-2.4.17-i586-2.txz: Rebuilt.
n/libmbim-1.12.2-i586-2.txz: Rebuilt.
n/network-scripts-14.2-noarch-1.txz: Upgraded.
       Add loopback up/down/start/stop features.
       Fix bringing down a single non-bridge interface.
       Thanks to Xsane.
n/nmap-7.00-i586-1.txz: Upgraded.
n/php-5.6.15-i586-1.txz: Rebuilt.
n/tin-2.2.1-i586-3.txz: Rebuilt.
x/intel-gpu-tools-1.9-i586-2.txz: Rebuilt.
x/xf86-input-evdev-2.10.0-i586-3.txz: Rebuilt.
x/xf86-input-vmmouse-13.1.0-i586-3.txz: Rebuilt.
x/xf86-video-ati-7.6.1-i586-2.txz: Rebuilt.
x/xf86-video-intel-git_20151119_666f25b-i586-1.txz: Upgraded.
x/xf86-video-modesetting-0.9.0-i586-5.txz: Rebuilt.
x/xf86-video-nouveau-git_20151119_6e6d8ac-i586-1.txz: Upgraded.
x/xf86-video-openchrome-0.3.3-i586-7.txz: Rebuilt.
x/xorg-server-1.18.0-i586-2.txz: Rebuilt.
x/xorg-server-xephyr-1.18.0-i586-2.txz: Rebuilt.
x/xorg-server-xnest-1.18.0-i586-2.txz: Rebuilt.
x/xorg-server-xvfb-1.18.0-i586-2.txz: Rebuilt.
xap/audacious-3.7-i586-1.txz: Upgraded.
xap/audacious-plugins-3.7-i586-1.txz: Upgraded.
xap/network-manager-applet-1.0.6-i586-2.txz: Rebuilt.
xap/sane-1.0.25-i586-2.txz: Rebuilt.
xfce/exo-0.10.7-i586-1.txz: Upgraded.
xfce/xfce4-screenshooter-1.8.2-i586-2.txz: Rebuilt.
xfce/xfce4-weather-plugin-0.8.6-i586-2.txz: Rebuilt.
isolinux/initrd.img: Rebuilt.
       Removed udev, added eudev and libgudev.
       Fixed partition size output.
usb-and-pxe-installers/usbboot.img: Rebuilt.
       Removed udev, added eudev and libgudev.
       Fixed partition size output.
+--------------------------+




IMHO Slackware switching from udev to eudev is a significant development.

Slackware is important. Why? It is the oldest surviving Linux distro. DuckDuckGo it.

It is also the last independent distro that has its original benevolent dictator in charge (DuckDuckGo that too).

It is also one of the very few Linux distros that adheres to UNIX standards. There aren't many, perhaps Gentoo, Crux.. but they are even less user friendly (if you are of the mindset that MS Windows is user friendly Laughing ) than Slack. Otherwise look to BSD.

Is this the death of SystemD? Hardly (yet). Will it be noticed? Absolutely!

_________________
Puppy Linux Blog - contact me for access
Back to top
View user's profile Send private message Visit poster's website 
amigo

Joined: 02 Apr 2007
Posts: 2647

PostPosted: Sat 21 Nov 2015, 11:46    Post subject:  

Yeah, I just saw today that Slack has changed to eudev.

This won't do much to stave off systemd elsewhere, though, as anyone using gnome or other things are depending on other bits of the systemd suite, especially logind. Unfortunately, none of the alternates to systemd which provide 'shims' have gained much traction either -nor vdev either.

But, I recently came across 'nosh' which is a new init for BSD, and it provides shims for nearly everything, and can integrate with systesm using sysvinit-style scripts, systemd 'service' files or upstart config files (maybe openRC too). I haven't achieved a full build of it yet as it uses some unusual build tools: 'redo' & Co. But, it is supposed to build on linux. It sounds like the most viable contender yet -especially if it gets acceptance in the BSD world.
Back to top
View user's profile Send private message 
anikin

Joined: 10 May 2012
Posts: 1020

PostPosted: Sat 21 Nov 2015, 14:55    Post subject:  

Yes, eudev might be big news for Slackware proper. However, for Slacko, Tahrpup, Quirky, or any other Woof/CE based pup it's not really that important. Firstly, it's not quite clear whether Puppy is still alive. What's all the fuss about Woof CE, can you guys tell me what's been accomplished? Not the seventeen thousand lines of code as one of the gatekeepers is claiming, but the real stuff? Show me the goods - has the booting routine been rectified? Have you considered implementing simargl's workaround for Archpup instead of using the half-assed xorgwizard? What's the use of eudev, systemd or no systemd if Puppy is continuing to demonstrate malicious functionality - connecting my machine to icanhazip or ping Google without my consent and knowledge. That's what needs to be discussed, not the big, red herring, that Micko threw on the table. BTW, Barry discussed eudev a couple years ago http://bkhome.org/blog2/?viewDetailed=00168

As a side note, I recently had a look at goingnuts' pupngo. Haven't run it yet, (it won't run off of ext4 I think) just unsquashed it to check to see what's inside. I did so after reading jamesbonds' review here http://murga-linux.com/puppy/viewtopic.php?p=872640#872640 a very positive review, I should add. The first thing I checked was the ipinfo script (call me paranoid). Please, folks have a look at it:
Code:
#20121005:heavy mods by goingnuts porting to gtkdialog1, ash, no gettext & no xmessage or yafsplash
#20140115: deactivated external ip look up - modified layout

   # external ip
   var0=""
   #var0="$(wget -O - -q icanhazip.com)"   #deact for privacy
   #var0="External IP: $var0"            #deact for privacy
   # tab 1 - interfaces
   var01=$(echo "Hostname: $HOSTNAME")
   var02=$(ifconfig)
   # write2file
   echo "$var01
${var0}
${var02}" > /tmp/interfaces
That's what responsible, well-minded, well-dressed developers do. They deactivate the crap, because they care about me, the user. Compare this to what you'll see in any other Puppy ...
Back to top
View user's profile Send private message 
Iguleder


Joined: 11 Aug 2009
Posts: 2031
Location: Israel, somewhere in the beautiful desert

PostPosted: Sat 21 Nov 2015, 15:06    Post subject:  

anikin wrote:
What's all the fuss about Woof CE, can you guys tell me what's been accomplished?


See the Slacko 6.3.0 changelog and the commit log of woof-CE.

anikin wrote:
Show me the goods - has the booting routine been rectified? Have you considered implementing simargl's workaround for Archpup instead of using the half-assed xorgwizard?


"Puppy is a do-ocracy" Idea

anikin wrote:
What's the use of eudev, systemd or no systemd if Puppy is continuing to demonstrate malicious functionality - connecting my machine to icanhazip or ping Google without my consent and knowledge.


The first is off by default, the second has been replaced. Again, see the woof-CE commit log. Overall, your reply sounds to me like a complaint and I don't like this attitude.

anikin wrote:
That's what needs to be discussed, not the big, red herring, that Micko threw on the table.


Poor little herring. Where is it? We need to throw it back into the sea as quick as possible.

anikin wrote:
They deactivate the crap, because they care about me, the user. Compare this to what you'll see in any other Puppy ...


... and I don't use AbiWord, but I don't blame developers for not caring about me because it's there. Also, in fact, I want it to be there, for all those who need it. Moreover, woof-CE allows you to build "privacy-oriented" puplets with this modified script you adore - go ahead and do that, I promise to be there to analyze your puplet's traffic and show you how false is your sense of privacy.

_________________
My homepage
My GitHub profile
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 23 of 26 [384 Posts]   Goto page: Previous 1, 2, 3, ..., 21, 22, 23, 24, 25, 26 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Announcements
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0885s ][ Queries: 12 (0.0076s) ][ GZIP on ]