On Tue, Aug 12, 2014 at 9:38 PM, Christopher Barry
<[email protected]> wrote:
> So why would very smart people who love and use Linux want to create or
> embrace such a creepy 'Master of All' daemon? Ostensibly, it's for the
> reasons they say, as I mentioned at the top. But partially I think it's
> from a lack of experience. Not a lack as in programming hours, but a
> lack as in time on the Planet. Intelligence alone is not a substitute
> for life experience and, yes I'll say it, wisdom. There's no manual for
> wisdom. Implementing systemd by distros is not a wise move for them over
> the long term. It will, in fact, be their ultimate undoing.
>
> Partially it's the larger-than-life egos of the people involved. Has
> anyone actually read what Poettering says about things? Wow. This guy
> is obviously convinced he has all the answers for everyone. Traditional
> ideas about simplicity and freedom are quaint, but have no real place
> in a 'modern' OS. Look, he's just smarter than you, so get over it and
> move aside. He knows what's best, and he has it under control. How old
> is this guy anyway? 12 or so? He's a fucking tool (IMHO).
Yes, this is *exactly* the problem with systemd.
Not the quality of the code. Not the desire to fix some
old design problems of SystemV-style init.
Code quality is good. The goals are legitimate.
The problem is: the author is a control freak.
I don't mean this to be an insult, it's my honest assessment
of his personality. He wants to control everything.
And I am convinced he is knowingly lying about it.
He pretends that he wants to add stuff to systemd to improve
this or that aspect of the user's experience, but in reality
he just wants to "privatize" more and more of the OS
to his project.
He probably understands that this is not a right thing to do,
that modularity is a good thing, but it conflicts with his character,
so he won't split up the projects into independent subprojects.
(Say, a semi-recent addition to systemd, the logging daemon,
HAD TO BE a separate tool)
I no longer think that talking to Lennart about this is useful.
I and other people tried. It doesn't work.
I am just waiting for a sufficient number of people to get pissed off,
fork the project, and bring sanity to it, which in this case means
splitting it up into modular bits, and probably dropping
some parts.
On Wed, Apr 8, 2015 at 8:12 AM, Denys Vlasenko <[email protected]> wrote:
> On Tue, Aug 12, 2014 at 9:38 PM, Christopher Barry
> <[email protected]> wrote:
>> So why would very smart people who love and use Linux want to create or
>> embrace such a creepy 'Master of All' daemon? Ostensibly, it's for the
>> reasons they say, as I mentioned at the top. But partially I think it's
>> from a lack of experience. Not a lack as in programming hours, but a
>> lack as in time on the Planet. Intelligence alone is not a substitute
>> for life experience and, yes I'll say it, wisdom. There's no manual for
>> wisdom. Implementing systemd by distros is not a wise move for them over
>> the long term. It will, in fact, be their ultimate undoing.
>>
>> Partially it's the larger-than-life egos of the people involved. Has
>> anyone actually read what Poettering says about things? Wow. This guy
>> is obviously convinced he has all the answers for everyone. Traditional
>> ideas about simplicity and freedom are quaint, but have no real place
>> in a 'modern' OS. Look, he's just smarter than you, so get over it and
>> move aside. He knows what's best, and he has it under control. How old
>> is this guy anyway? 12 or so? He's a fucking tool (IMHO).
>
> Yes, this is *exactly* the problem with systemd.
Not to me.
I responded to systemd the way I responded to udev, "that's too
complicated, lemme see if I can clone a subset of it". In busybox this
resulted in mdev, so you had an alternate implementation that did the
same thing and could swap between them. (This lead to me butting heads
with Greg KH and Kay Sievers on more than one occasion, because they
were convinced sysfs was a private export from their kernel software
to their userspace software which nobody else would ever use and they
could force upgrades on both sides in lockstep. And they continued to
act this way even after Linus chewed them out about it, but I worked
around it and moved on.)
But systemd has no clear goals, no specification, the single
implementation is a moving target... it's basically a microsoft
product. Remember the days when the *.doc file format was "what
microsoft offices produces and is capable of consuming", and the
staroffice guys went to GREAT LENGTHS to reverse engineer it made
possible only by the fact that Microsoft went years between releases
so they had time to work out what the office 6 format was before
office 7 came out, and so on. Same for the Excel file format being
"what microsoft's implementation produces and consumes is correct by
definition, every strange corner case bug of that one magic
implementation _is_ the spec and there is no other."
Samba reverse engineered windows NT's network protocols the same way,
producing a giant "if it's this version, do this. If it's this
versino, do this. Avoid doing this because it bluescreens this
specific version of NT for no apparent reason..."
i thought we'd moved _on_ from the days of "this site optimized for
internet explorer", but systemd is that all over again. Linux is all
about modularity where you swap out openssh for libressh (or dropbear)
and swap out xfree86 for x.org and swap out glibc for eglibc (or
uclibc or musl) and you have at least a fighting chance to make it
work. Unfortunately, the systemd developers take the suggestion that
you might want to keep the option of doing that open as some sort of
personal attack.
I don't care what they're doing. I don't want to _have_ to care what
they're doing. I want a description of the problem space from which I
can write a new implementation. If I can't even reverse engineer such
a thing because it's still too much of a moving target several years
into the project, then what they're doing is crazy and I refuse to get
any of it on me.
> Not the quality of the code. Not the desire to fix some
> old design problems of SystemV-style init.
I'm still unclear on what problem they were actually trying to solve.
(In my defense, _they_ seem unclear. We're way beyond Zawinski's law
here...)
> Code quality is good. The goals are legitimate.
1) Not really, but that's beside the point. 2) What _are_ the goals?
They keep changing...
> The problem is: the author is a control freak.
I don't care. Honestly don't care. We used cdrecord for years from a
solaris bigot who openly insulted linux in the README, Openssl's
maintainer wasn't that much happier about Linux (until he needed
money), put up with xfree86's insular development for a couple
_decades_ before that maintainer finally went over the line.
Heck, the FSF's entire "It's GNU Linux, Dammit! Call it by its proper
name: GNU/Linux/dammit" campaign is seriously irritating, and part of
what I was doing with busybox was trying to create a linux development
system without a single gnu package in it (busybox, uclibc, tinycc)
capable of rebuilding itself under itself, and then ask Stallman "I
know you're going to insist this isn't a Linux system but a
GNU/Linux/Dammit system, I'd just like you to try to explain _how_."
(Preferably capturing this on video.) But that was only a small part
of my motivation or I wouldn't have bothered to spend years poking at
busybox (and more years poking at toybox to make android
self-hosting).
My problem is the blank incomprehension on their part when I go "If I
were to clone a minimal subset of systemd in busybox or toybox, where
would I start reading?" and they can't fit in their head the idea that
anybody would _want_ to do that, and if they think I'm serious they
feel threatened and start changing stuff faster. It's a bit like Adobe
going "you want to... clone the flash plugin? Why would you do that?
You don't need a fresh implementation, we've got one! See, we're
giving it to you. Take what we give you, it's free, you ungrateful
little..."
I don't care about the personality of the developers behind the
project. I don't want to use their code, I want to write a new one.
Unfortunately the systemd developers seem to treat linux machines
without systemd the way microsoft treated PCs sold without their OS
preinstalled. ("Bare machines are piracy!" No really, they had a web
page to that effect last decade.)
> I don't mean this to be an insult, it's my honest assessment
> of his personality. He wants to control everything.
>
> And I am convinced he is knowingly lying about it.
I don't care if he's stabbing kittens. I want a modular design
consisting of interchangeable parts available from multiple sources.
This is why Linux succeeded. This is why the PC succeeded. When
netscape released its source code and mozilla spent its first 5 years
floundering like a beached whale (before galeon forked off and threw
out 90% of the code, and then firefox forked off from _that_ to
finally get a usable browser), the KDE guys didn't wait and wrote
Konqueror, which Apple forked as webkit and then Google forked that as
Chrome. This is how it _works_. You have multiple competing
implementations.
The systemd guys are very all-or-nothing, and treat simply asking
"what else is out there" as an attack.
Look, the systemd problem is self-limiting: the smartphone is to the
PC what the PC was to the minicomputer and mainframe before it. A
decade from now you'll plug your phone into a USB3 hub with a
keyboard, mouse, and HDMI adapter (or chromecast) and that will _be_
your workstation. All the "my vax is way more powerful than your dinky
little compaq and I will cling to it unto death" arguments will
resolve themselves in time via the obvious solution.
Android has a no GPL in userspace policy, systemd is gpl. Android has
its own init system it's not moving off of, and android is shipping a
billion devices annually while the PC gets kicked up into the server
space the way big iron always is by the next generation of devices
everyone actually interacts with. (This time that's called "the
cloud", and it's every bit as lucrative and boring as punch cards and
JCL and timesharing and so on.)
Since systemd is excluded from android, I'm not getting particularly
worked up about it because if I didn't care what the mainframe guys
were doing when I was learning DOS, I don't see why I should care what
the cloud guys are doing while trying to bring up a native development
environment on my phone. I gave a talk about this in 2013
(http://landley.net/talks/celf-2013.txt).
> I no longer think that talking to Lennart about this is useful.
> I and other people tried. It doesn't work.
I actually had a brief interaction with the guy a few years back
because I was the one saying "separate /bin and /usr/bin directories
are a historical artifact we've outgrown" back in 2001, and he wanted
to reference my 2010 busybox post on the subject to support what he
was doing there and I went "sure". (And thus the old post went viral
and I wound up doing an updated version of it for some magazine with a
couple numbers corrected and citations to primary sourcess... where is
that... http://landley.net/writing/hackermonthly-issue022-pg33.pdf)
Anyway, he seemed nice enough at the time. I'd switch to BSD before
using a Linux distro based on systemd, but I have nothing personally
against its author.
> I am just waiting for a sufficient number of people to get pissed off,
> fork the project, and bring sanity to it, which in this case means
> splitting it up into modular bits, and probably dropping
> some parts.
Last time around this was me (udev->mdev). I've pondered doing this
for systemd (I have half a design for a "lunchd" loosely based on
macosx launchd without xml config files), but it hasn't been a
priority because I don't _care_ what big iron is doing while I'm
trying to turn android into a development environment. One is the
future, the other really isn't.
As long as android isn't merging systemd, the problem should solve
itself. It may take conventional linux down with it, but the FSF was
trying pretty hard with its GNU/Linux/Dammit campaign and the
community at large avoided that (and I gave a talk about _that_ too:
http://landley.net/talks/ohio-2013.txt
If you're more worked up about it than I am: write an alternative. The
main reason I haven't bothered yet is I don't see the _point_ of
systemd. I don't have a clear understanding of the problem they're
trying to solve, let alone how they're going about it. I'm told all
sorts of packages now have systemd hooks, which seems a bit like
bundling RPM and DEB build recipes in with your source tarball. It's a
thing people largely stopped doing when portage and pacman and bitbake
and so on cropped up and there were enough _different_ ones it became
somebody else's problem. Just because systemd has Red Hat's big
pointy-haired weight thrown behind it and ubuntu went "well it can't
be a worse idea than redirecting #!/bin/sh to point to dash" doesn't
make it interesting technology.
Rob
On Thu, Apr 9, 2015 at 2:37 AM, Rob Landley <[email protected]> wrote:
> On Wed, Apr 8, 2015 at 8:12 AM, Denys Vlasenko <[email protected]> wrote:
> But systemd has no clear goals, no specification, the single
> implementation is a moving target... it's basically a microsoft
> product.
I think the actual goal is to control everything.
To satisfy the control freak.
And yes, it is the M$ way of seeing things.
> i thought we'd moved _on_ from the days of "this site optimized for
> internet explorer", but systemd is that all over again. Linux is all
> about modularity where you swap out openssh for libressh (or dropbear)
> and swap out xfree86 for x.org and swap out glibc for eglibc (or
> uclibc or musl) and you have at least a fighting chance to make it
> work. Unfortunately, the systemd developers take the suggestion that
> you might want to keep the option of doing that open as some sort of
> personal attack.
Yes. They want you to use their stuff, and in their way.
> I don't care what they're doing. I don't want to _have_ to care what
> they're doing. I want a description of the problem space from which I
> can write a new implementation. If I can't even reverse engineer such
> a thing because it's still too much of a moving target several years
> into the project, then what they're doing is crazy and I refuse to get
> any of it on me.
>
>> Not the quality of the code. Not the desire to fix some
>> old design problems of SystemV-style init.
>
> I'm still unclear on what problem they were actually trying to solve.
>
> (In my defense, _they_ seem unclear. We're way beyond Zawinski's law
> here...)
>
>> Code quality is good. The goals are legitimate.
>
> 1) Not really, but that's beside the point. 2) What _are_ the goals?
> They keep changing...
The _stated_ goal, initially, was a better service, a daemon babysitter.
It is a legitimate goal because "industry standard" one, SysV,
leaves a lot to be desired.
But then it suddenly started having unrelated functionality
added to it. Again. And again.
>> The problem is: the author is a control freak.
>
> I don't care. Honestly don't care.
>
> My problem is the blank incomprehension on their part when I go "If I
> were to clone a minimal subset of systemd in busybox or toybox, where
> would I start reading?" and they can't fit in their head the idea that
> anybody would _want_ to do that, and if they think I'm serious they
> feel threatened and start changing stuff faster.
Yes. You are agreeing with me: they are control freaks.
> I don't care about the personality of the developers behind the
> project. I don't want to use their code, I want to write a new one.
I only care to the extent necessary to figure out how,
and whether it is possible, to cooperate with the people on the project.
It's possible to cooperate even with people with whom you have
lots of disagreements in details.
When someone's core desire is to make you use _their_ code,
and not being able to switch parts with reasonable expenditure
of time/effort, it is not possible for me.
>
> Look, the systemd problem is self-limiting: the smartphone is to the
> PC what the PC was to the minicomputer and mainframe before it. A
> decade from now you'll plug your phone into a USB3 hub with a
> keyboard, mouse, and HDMI adapter (or chromecast) and that will _be_
> your workstation. All the "my vax is way more powerful than your dinky
> little compaq and I will cling to it unto death" arguments will
> resolve themselves in time via the obvious solution.
>
> Android has a no GPL in userspace policy, systemd is gpl. Android has
> its own init system it's not moving off of, and android is shipping a
> billion devices annually while the PC gets kicked up into the server
> space the way big iron always is by the next generation of devices
> everyone actually interacts with. (This time that's called "the
> cloud", and it's every bit as lucrative and boring as punch cards and
> JCL and timesharing and so on.)
>
> Since systemd is excluded from android, I'm not getting particularly
> worked up about it because if I didn't care what the
Uh there is a "suggestion" of kdbus replacing android binder so yeah
systemd might be close behind.
I would not be surprised if they try to ram systemd down google's throat...
Hi,
On Wed, Apr 08, 2015 at 07:37:15PM -0500, Rob Landley wrote:
> Heck, the FSF's entire "It's GNU Linux, Dammit! Call it by its proper
> name: GNU/Linux/dammit" campaign is seriously irritating, and part of
> what I was doing with busybox was trying to create a linux development
> system without a single gnu package in it (busybox, uclibc, tinycc)
> capable of rebuilding itself under itself, and then ask Stallman "I
> know you're going to insist this isn't a Linux system but a
> GNU/Linux/Dammit system, I'd just like you to try to explain _how_."
> (Preferably capturing this on video.)
What was the result of this work? Did you manage to build
a self-hosting system? What implementation of "make" did you use
to build the kernel?
A.
On Fri, Apr 10, 2015 at 4:20 PM, Aaro Koskinen <[email protected]> wrote:
> Hi,
>
> On Wed, Apr 08, 2015 at 07:37:15PM -0500, Rob Landley wrote:
>> Heck, the FSF's entire "It's GNU Linux, Dammit! Call it by its proper
>> name: GNU/Linux/dammit" campaign is seriously irritating, and part of
>> what I was doing with busybox was trying to create a linux development
>> system without a single gnu package in it (busybox, uclibc, tinycc)
>> capable of rebuilding itself under itself, and then ask Stallman "I
>> know you're going to insist this isn't a Linux system but a
>> GNU/Linux/Dammit system, I'd just like you to try to explain _how_."
>> (Preferably capturing this on video.)
>
> What was the result of this work?
http://landley.net/aboriginal/about.html
My old self-hosting system was 7 packages: linux, busybox, uClibc,
gmake, gcc, binutils, and bash.
The new one I'd like to do is 4 packages: linux, toybox, musl, and
qcc. Right now, I'm focusing on getting toybox to 1.0 as fast as
possible, then I worry about other stuff.
> Did you manage to build a self-hosting system?
Yeah, but it's still using a gcc toolchain. (The last gplv2 release of
gcc, binutils, and make, circa 2006.)
I was going to replace it with http://landley.net/code/tinycc (and
then http://landley.net/code/qcc). The idea was to take my tcc fork
and make it a multiplexer like busybox (so it could run as cc, ld,
strip, as, and so on depending on what name you called it under; one
binary with lots of symlinks to it).
The qcc idea was to rip out tcc's code generator and replace it with
QEMU's tcg (tiny code generator), so you'd turn the compiler behind
http://bellard.org/tcc/tccboot.html (I.E. this already _built_ a
working kernel at one point, albeit with a lot of cheating that I was
working to fix) and make it support all the targets qemu does,
leveraging qemu's developer base to keep them well-supported. _AND_ I
got permission to BSD license his tcc code, and qemu's tcg is already
BSD licensed, so that fixes the license problem.
But I got distracted by toybox (the history is
https://lwn.net/Articles/478308/ then
https://www.youtube.com/watch?v=SGmtP5Lg_t0 then
https://lwn.net/Articles/629362/ and I'm currently dealing with
merging http://lists.landley.net/pipermail/toybox-landley.net/2015-April/004024.html
and yes that's the Android Core maintainer posting to the toybox
list).
So I've been kinda busy with other things of late. :)
These days I'm waiting for llvm to mature, but a month or two back
somebody picked up my qcc idea (combine tinycc's front end with tcg's
back end to get a simple bsd licensed C99 compiler that supports a lot
of targets) and actually started seriously working on it. So at this
point I'm looking to contribute to _his_ project. (I'd link to him but
I'm in japan at the moment and those files are back in texas. Ping me
after the 20th if you're still curious.)
> What implementation of "make" did you use to build the kernel?
I plan on writing my own, but it's a bit down on the todo list. For
qcc it was going to be one of the multiplexer commands like nm and
objdump. Maybe I should implement it in toybox instead, but it's not
in the 1.0 roadmap at http://landley.net/toybox/roadmap.html and I'm
not adding more stuff to that until _after_ the release. (Well not
that I have to implement, somebody wants to send me a command already
written I'll certainly look at it...)
I note that the hard part with getting the kernel to build with tinycc
was actually the more obscure binutils things. When I was trying to
get my tinycc fork to build the kernel (without using any parts of gcc
or binutils) one of the first things that failed was generating a
header file that did either nm or objdump -d on a binary (I forget
which) and ran the result through sed to generate a header file with
structure offsets. Tinycc had an assembler but not a disassembler, you
see...
These days I'm waiting for http://ellcc.org and similar to bear fruit.
For the linker they're either using http://lld.llvm.org but the
musl-cross toolchain is using
https://github.com/sabotage-linux/libelf-compat and before they were
using https://fedorahosted.org/releases/e/l/elfutils/ and I still
haven't had a chance to look at the LLVM toolchain AOSP is building.
It's all up in the air right now as everybody works to clean up after
the "career limiting move" that was GPLv3.
The android guys are using their own weird make setup (the Android.mk
files), and they tell me they have a brand new build tool to replace
make that they're they're porting the AOSP build to, which I should go
take a look at and maybe come up to speed on. But really, I wrote my
own "sed" and made Linux From Scratch build with it, and then did it
AGAIN from scratch under a different license. I'm partway through
writing my own shell for toybox and am supporting bash syntax in it.
Writing my own make that handles gmake stuff packages actually use
isn't that much harder if it comes to it.
(But as with init systems, it's a ways down on my todo list at the
moment. Get toybox to 1.0 so we have a public domain posix+LSB command
line that can build Linux From Scratch, _then_ see where toolchains
and such are. I know musl-libc.org is in good shape, llvm is
progressing without me, if I need to write a make I can do that...)
Rob