boycott systemd

News, happenings
Message
Author
Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#321 Post by Ibidem »

technosaurus wrote:a complete statically compiled busybox system rings in at ~1mb.
OTOH systemd provides at least an additional 1% functionality for only ... lets do the math:

Code: Select all

(Debian example: duplicate dependencies removed for brevity
 ... note the lack of a shell, and many other tools provided by busybox
 ... but that's OK, you can just roll your own in perl or slang)

systemd : 13,458.0 kB
 |- libc6 : 10,291.0 kB
 |  |- libgcc1 : 129.0 kB
 |  |  |- multiarch-support : 216.0 kB
 |  |  |- gcc-4.9-base : 218.0 kB
 |- libgcrypt20 : 1,033.0 kB
 |  |- libgpg-error0 : 444.0 kB
 |- liblzma5 : 309.0 kB
 |- acl : 258.0 kB
 |  |- libattr1 : 30.0 kB
 |- adduser : 1,066.0 kB
 |  |- debconf : 614.0 kB
 |  |- passwd : 2,132.0 kB
 |  |  |- debianutils : 147.0 kB
 |  |  |  |- sensible-utils : 110.0 kB
 |  |  |- libpam-modules : 852.0 kB
 |  |  |  |- libdb5.3 : 1,812.0 kB
 |  |  |  |- libpam-modules-bin : 248.0 kB
 |  |  |- libsemanage1 : 245.0 kB
 |  |     |- libsemanage-common : 65.0 kB
 |  |     |- libsepol1 : 339.0 kB
 |  |     |- libustr-1.0-1 : 287.0 kB
 |  |- perl-base : 4,643.0 kB
 |     |- dpkg : 7,195.0 kB
 |        |- libbz2-1.0 : 114.0 kB
 |        |- tar : 2,619.0 kB
 |        |- zlib1g : 179.0 kB
 |- initscripts : 165.0 kB
 |  |- coreutils : 14,249.0 kB
 |  |- lsb-base : 72.0 kB
 |  |- sysvinit-utils : 147.0 kB
 |     |- startpar : 95.0 kB
 |- libacl1 : 80.0 kB
 |- libaudit1 : 157.0 kB
 |  |- libaudit-common : 49.0 kB   
 |- libblkid1 : 326.0 kB
 |  |- libuuid1 : 89.0 kB
 |- libcap2 : 61.0 kB
 |- libcap2-bin : 110.0 kB
 |- libcryptsetup4
 |  |- libdevmapper1.02.1 : 330.0 kB
 |  |  |- dmsetup : 123.0 kB
 |- libkmod2 : 134.0 kB
 |- libpam0g : 248.0 kB
 | |- libselinux1 : 213.0 kB
 |  |- libpcre3 : 672.0 kB
 |- libsystemd0 : 181.0 kB
 |- mount : 357.0 kB
 |  |- libmount1 : 357.0 kB
 |  |- libsmartcols1 : 209.0 kB 
 |- sysv-rc OR file-rc : 141.0 kB
 |  *******    |- insserv : 183.0 kB
 |- udev : 5,924.0 kB
 |  |- libudev1 : 98.0 kB
 |  |- procps : 670.0 kB
 |  |  |- libncursesw5 : 388.0 kB
 |  |  |- libprocps3 : 132.0 kB
 |- util-linux : 2,733.0 kB
    |- libncurses5 : 306.0 kB
    |- libslang2 : 1,543.0 kB
    |- libtinfo5 : 480.0 kB
    |- tzdata : 1,546.0 kB
nevermind, that's too much math
... but definitely not something you would want in an initramfs

Code: Select all

cut -d: -f2  | sed -e s/,// -e s/kB/+/ -e 's/\.0//' -e '1i0' -e '$i\\np' | busybox dc 
says 81873 kB (I inserted " : 252.0 kB" after libcryptsetup4).

Note that several of those packages will require a Debian Policy compliant shell; dash provides that in ~190 kilobytes. Both dash and bash are "essential" on a Debian system, meaning that packages should not explicitly depend on them unless they have a versioned dependency.

I've heard of systemd being used in conjunction with busybox, insane as that is; I gather that you can turn off most but not all of the services.
Presumably the result would run at least 1-2 MB extra, besides requiring glibc.

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

The Gummiboot EFI boot loader tool has been merged into

#322 Post by James C »

The Gummiboot EFI boot loader tool has been merged into systemd


http://lists.freedesktop.org/archives/s ... 32147.html

The Gummiboot EFI boot loader tool has been merged into
systemd, and renamed to "systemd-boot". The bootctl tool has been
updated to support systemd-boot.

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

The Gummiboot EFI boot loader tool has been merged into

#323 Post by James C »

Forum glitch.

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

Re: The Gummiboot EFI boot loader tool has been merged into

#324 Post by bark_bark_bark »

James C wrote:The Gummiboot EFI boot loader tool has been merged into systemd


http://lists.freedesktop.org/archives/s ... 32147.html

The Gummiboot EFI boot loader tool has been merged into
systemd, and renamed to "systemd-boot". The bootctl tool has been
updated to support systemd-boot.
I never used it, but what a shame.
James C wrote:Forum glitch.
The forum's glitching? Also a shame.
....

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#325 Post by technosaurus »

Someone must have taught Lennart how to use git submodules (re: gudev). There was no good reason to keep all the systemd code in the same tree. Finally they did 1 thing that makes sense.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
8Geee
Posts: 2181
Joined: Mon 12 May 2008, 11:29
Location: N.E. USA

#326 Post by 8Geee »

82.2 Mb... About the size of FF27 inflated with extensions.
Linux user #498913 "Some people need to reimagine their thinking."
"Zuckerberg: a large city inhabited by mentally challenged people."

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

Lennart reacts to the release of Devuan

#327 Post by James C »

Lennart reacts to the release of Devuan

https://www.youtube.com/watch?v=_cdEFF-ttLw

User avatar
Galbi
Posts: 1098
Joined: Wed 21 Sep 2011, 22:32
Location: Bs.As. - Argentina.

Re: Lennart reacts to the release of Devuan

#328 Post by Galbi »

James C wrote:Lennart reacts to the release of Devuan

https://www.youtube.com/watch?v=_cdEFF-ttLw
:D
Remember: [b][i]"pecunia pecuniam parere non potest"[/i][/b]

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

#329 Post by James C »

Latest AntiX 15 Beta 3-V.

Code: Select all

james@antix1:~
$ cat /etc/devuan_version
jessie
james@antix1:~
$ 

More details.

http://www.murga-linux.com/puppy/viewto ... 886#848886

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

#330 Post by James C »

You may have heard about kdbus by now -- the systemd people were aiming at merging a server component for dbus into the kernel. Well, they didn't get it into 4.1 -- for reasons.

http://thread.gmane.org/gmane.linux.ker ... us=1939166


Linus Torvalds' on the subject....
No, I think you're right, there's the other non-potato choice: "dbus
is seriously screwed up".

That thing has almost no kernel footprint. It's spending all it's time
in user space overhead.

Quite frankly, the whole "kdbus is important for performance" seems to
be *totally* invalidated by even a minimal look at profiles for that
thing. Here's the top-15 offender list:

2.62% gdbus libc-2.20.so [.] _int_malloc
2.43% gdbus libc-2.20.so [.] free
2.31% server libc-2.20.so [.] free
2.12% gdbus libc-2.20.so [.] malloc
1.77% gdbus libglib-2.0.so.0.4200.2 [.] g_utf8_validate
1.43% gdbus libglib-2.0.so.0.4200.2 [.] g_slice_alloc
1.41% gdbus libglib-2.0.so.0.4200.2 [.] g_hash_table_lookup
1.28% server libc-2.20.so [.] _int_malloc
1.27% gdbus libglib-2.0.so.0.4200.2 [.] g_mutex_lock
1.22% gdbus libglib-2.0.so.0.4200.2 [.] g_variant_unref
1.16% server libc-2.20.so [.] malloc
1.14% gdbus libglib-2.0.so.0.4200.2 [.] g_bit_lock
1.07% gdbus libglib-2.0.so.0.4200.2 [.] g_slice_free1
1.05% gdbus libglib-2.0.so.0.4200.2 [.] g_bit_unlock
1.01% gdbus libglib-2.0.so.0.4200.2 [.] g_mutex_unlock

there's not a kernel function in sight in the top-15, and it's all
just overhead. The above is from the server side, but the client looks
similar.

If somebody wants to speed up dbus, they should likely look at the
user-space code, not the kernel side.

My guess is that pretty much the entirely of the quoted kdbus
"speedup" isn't because it speeds up any kernel side thing, it's
because it avoids the user-space crap in the dbus server.

IOW, all the people who say that it's about avoiding context switches
are probably just full of shit. It's not about context switches, it's
about bad user-level code.
And

http://thread.gmane.org/gmane.linux.ker ... us=1939166
So really. The people who talk about how kdbus improves performance
are just full of sh*t. Yes, it improves things, but the improvement
seems to be 100% "incidental", in that it avoids a few trips down the
user-space problems.

The real problems seem to be in dbus memory management (suggestion:
keep a small per-thread cache of those message allocations) and to a
smaller degree in the crazy utf8 validation (why the f*ck does it do
that anyway?), with some locking problems thrown in for good measure.
And finally

http://article.gmane.org/gmane.linux.kernel/1939166
>> That said, either you're running your test on a potato, or dbus is
>> seriously screwed up. No way should it take 4+ seconds to send a 1000b
>> message to back and forth 20k times. But as mentioned, I can't even
>> see what it's doing right now.
>
> Whee! I'm typing this email on a potato!

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

Post Reply