(old)Puppy Linux Discussion Forum

Posted: **Tue 19 May 2015, 16:35**

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.

Posted: **Sat 23 May 2015, 18:58**

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.

Posted: **Sat 23 May 2015, 18:58**

Forum glitch.

Posted: **Sat 23 May 2015, 19:44**

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.

Posted: **Mon 25 May 2015, 00:19**

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.

Posted: **Tue 26 May 2015, 17:17**

82.2 Mb... About the size of FF27 inflated with extensions.

Posted: **Mon 01 Jun 2015, 08:32**

Lennart reacts to the release of Devuan

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

Posted: **Mon 01 Jun 2015, 10:30**

James C wrote:Lennart reacts to the release of Devuan

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

Posted: **Mon 01 Jun 2015, 21:18**

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

Posted: **Sat 20 Jun 2015, 07:22**

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!

Posted: **Thu 25 Jun 2015, 05:09**

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

Posted: **Thu 25 Jun 2015, 10:50**

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?

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

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

Posted: **Thu 25 Jun 2015, 11:23**

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

Posted: **Thu 25 Jun 2015, 19:15**

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.

Posted: **Fri 26 Jun 2015, 11:00**

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

Posted: **Fri 26 Jun 2015, 11:58**

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

Posted: **Fri 26 Jun 2015, 18:50**

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.

Posted: **Sat 27 Jun 2015, 06:55**

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

Posted: **Sun 28 Jun 2015, 07:16**

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

Posted: **Sat 21 Nov 2015, 09:22**

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.

(old)Puppy Linux Discussion Forum

boycott systemd

The Gummiboot EFI boot loader tool has been merged into

The Gummiboot EFI boot loader tool has been merged into

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

Lennart reacts to the release of Devuan

Re: Lennart reacts to the release of Devuan

Slackware moves to eudev