boycott systemd

News, happenings
Message
Author
User avatar
James C
Posts: 6618
Joined: Thu 26 Mar 2009, 05:12
Location: Kentucky

#331 Post by James C »

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

http://lkml.iu.edu/hypermail/linux/kern ... 05492.html
We don't merge kernel code just
because user space was written by a retarded monkey on crack. Kernel
code has higher standards.........

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#332 Post by jamesbond »

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/kern ... 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/kern ... 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 :shock:

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/kern ... 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 ... uitei_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: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

bark_bark_bark
Posts: 1885
Joined: Tue 05 Jun 2012, 12:17
Location: Wisconsin USA

#333 Post by bark_bark_bark »

If any systemd code made it into linux, you know it's time to switch to FreeBSD.
....

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#334 Post by greengeek »

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.

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#335 Post by mcewanw »

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

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#336 Post by mcewanw »

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/ ... iscussion/

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

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#337 Post by greengeek »

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.

User avatar
James C
Posts: 6618
Joined: Thu 26 Mar 2009, 05:12
Location: Kentucky

#338 Post by James C »

Devuan Jessie x86-64.

https://devuan.org/

Code: Select all

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: Select all

james@nosystemd:~$ cat /proc/1/comm 
init
Attachments
Devuan Jessie x86-64.jpg
(35.48 KiB) Downloaded 912 times

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#339 Post by mcewanw »

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

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

Slackware moves to eudev

#340 Post by peebee »

http://www.slackware.org.uk/slackware/s ... ngeLog.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.
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

oui

#341 Post by oui »

James C wrote:Devuan Jessie x86-64.

https://devuan.org/

Code: Select all

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: Select all

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 :roll:

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!

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#342 Post by 01micko »

Code: Select all

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: Select all

 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 :lol: ) 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

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#343 Post by amigo »

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.

anikin
Posts: 994
Joined: Thu 10 May 2012, 06:16

#344 Post by anikin »

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. ... 640#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: Select all

#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 ...

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#345 Post by Iguleder »

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.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#346 Post by mavrothal »

anikin wrote: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 ...
Not that I think will change anything, but you might want to check a puppy too.
Not even that, just check the script in woof-CE.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

anikin
Posts: 994
Joined: Thu 10 May 2012, 06:16

#347 Post by anikin »

The script in Woof-CE *testing* says:
33a48d0 26 days ago
@dimkr dimkr Disabled ipinfo's querying by default
I presume, iguleder disabled it for his Trisquel Pup. What about the master branch - Slacko and Tahr Pups? I posted this earlier in another thread http://murga-linux.com/puppy/viewtopic. ... 461#796461 It shows an earlier version of Slacko saying hello to icanhazip. Has that changed?
Attachments
switch.jpeg
(25.71 KiB) Downloaded 1000 times

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#348 Post by BarryK »

Just for the record, Quirky has used eudev almost from its inception.
[url]https://bkhome.org/news/[/url]

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#349 Post by mavrothal »

anikin wrote:The script in Woof-CE *testing* says:
33a48d0 26 days ago
@dimkr dimkr Disabled ipinfo's querying by default
I presume, iguleder disabled it for his Trisquel Pup. What about the master branch - Slacko and Tahr Pups?
That would not be too difficult to check if you were really interested. Would it?
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

anikin
Posts: 994
Joined: Thu 10 May 2012, 06:16

#350 Post by anikin »

Of course it would not, you're right, and I did check it ... I know, I shouldn't bring this up, should stay above pettiness ... but so much emotional energy has been expended on What and Why?! It should've never been an issue in the first place. That's a welcome and long overdue step, if I were you, I'd make a separate announcement ... OK, let's move on, I'm not here to point a finger. Get it out *completely* from the GUI - it has no business being there. The benevolent dictator of Slackware, that Micko is referring to doesn't have it and with good reason.

Post Reply