The Politics of systemd Part 2

[ct85711]

the passwords part is an example, the point I was getting at is that you can't blindly trust any kind of software to provide all the security necessary or do the correct actions all the time. You think we trust all the programs we use? Simply no, but the programs we use are ones we know from experience and from history that they are reliable.

There is parts of systemd I do like, seriously. The main part that I'd bet most people have against systemd is how you are forced to use all of it. You can't switch parts out or exclude any of it at all.

[axl]

the passwords part is an example, the point I was getting at is that you can't blindly trust any kind of software to provide all the security necessary or do the correct actions all the time. You think we trust all the programs we use? Simply no, but the programs we use are ones we know from experience and from history that they are reliable.

There is parts of systemd I do like, seriously. The main part that I'd bet most people have against systemd is how you are forced to use all of it. You can't switch parts out or exclude any of it at all.

and the point i was trying to make is that you are trusting: apache/php/mysql, smtp/imap/pop3 type programs, ssh and many more. to start. are you as well worried that they will steal your password? because that would be bad. for you. i'm not worried. in fact, if i were worried that systemd is stealing my password i would look upon the open code and see it's not doing that.

why are we still talking about this? about projections? what would be if it were. it's not!!!

[saellaven]

The good thing with binaries logs, is that now if you break into someone computer with systemd, you just need to corrupt a few bits in its logs...
... and the user will be unable to see if someone has done that, or if systemd corrupt it itself with the "notabug" issue.

That's the point of systemd: security. You can now securely break into a systemd system without fear of been caught.

journalctl has some very nice features. you can lookup by user/command/time. things that simple log files can't do easily, or you have to use grep or other tools. it's a feature. it's good. I THINK.

funny, I thought all of those things were in my traditional log file already. I can't imagine the horror of some poor n00b having to learn tools like grep that might be helpful for them in other areas.

and you can use syslog in parallel. i do. and further more i stream my logs to a log machine that is not accessible through any type of connection from anywhere. (* @log_machine.yourdomain in syslog.conf). problem solved.

EDIT: in fact i am quite sure journalctl was meant more for programs to read logs. not people. people who wanna read logs, especially the old way, should just install their favorite flavor of logger on top of systemd. i really don't understand why people are complaining about this. why complain about redundancy ?

What you call redundancy, some call bloat. I have redundancy already, mirroring syslog to another system that just handles logging. There's no corruption issues to worry about there.

Oh, you want me to be forced to run a logger I don't want that has features I don't need... imagine if every program took that attitude. We'd have to keep buying faster and faster hardware just to keep up with all the crap we don't need, kind of like how Windows systems crawl more and more as they age.

A lot of us, particularly those of us with decades of linux use, specifically don't want Windows nor its ideology on our systems. It's part of why we picked linux to begin with.

[saellaven]

on the other hand, i can see why gnome devels and a lot of other people just want a proper way to talk to the kernel and maybe enter the mobile market. i think it's obvious that this is the target. no one cares about our systems. it's like the talk about rfid chips. or vaccinations. or gmo's.

That's fine... don't infect my desktop with the limitations of your mobile plans.

being afraid of programs talking to each other... on a meta source distribution forum ... is a weird stance.

EDIT: am sure skynet will start in systemd on our systems.

I don't care about programs talking to each other... IPC, piping, etc has been a part of POSIX forever. I am concerned about a central controller that talks to everything being riddled with security problems and requiring tons of unnecessary bloat in my system.

[fhede]

Lkml about debug and binaries logs in systemd.

https://lkml.org/lkml/2016/4/25/782

[Ottre]

Is that with your patch? If you don't allow kmsg open, maybe systemd
doesn't end up logging for reads either?

That said, the worst part of systemd by far is the insane binary
logging crap, and I would not be surprised if you have scrogged logs.

Quite frankly, everything else in systemd at least has an _excuse_ for
it. The binary logging is a pile of unadulterated shit.

QFT.

[krinn]

anyone got the link already of some slashdot with crazy systemd fanboys saying Linus knows nothing now that he did say that?
Klaus Knopper knows nothing, so do Linus no?

[Ant P.]

and the point i was trying to make is that you are trusting: apache/php/mysql, smtp/imap/pop3 type programs, ssh and many more.

There's no problem with trusting programs that I can quarantine, jail and kill as I please. Try doing that with PID1.

With systemd, your computer has one owner, one master, and it is not the system admin.

[tld]

funny, I thought all of those things were in my traditional log file already. I can't imagine the horror of some poor n00b having to learn tools like grep that might be helpful for them in other areas.

Bingo...and this cuts to the very heart of why the Unix philosophy these guys throw away at every turn has worked so well. Unlike journalctl whose sole purpose in life it to read logs from a one-of-a-kind imitation of that Godless Windows event log, the tools that you can use to parse text logs work for any text and do it well.

Years before systemd I always used to hold up 'nix text logging as compared to the Windows event log as a classic example of how clueless MS was...ffs. I love the quote from Linus...he's correct...they don't even have an excuse for that one.

Oh...and the fact that I can forward logs from that cluster fuck to the place and format they should have been in the first place doesn't make it any more attractive.

[axl]

you can't expect the entirety of the opensource world/linux world to follow suit to one philosophy. other people might want to move with the times. maybe some devs want modern tools. like binary logs. and not stick with 70's unix stuff.

i am not a systemd fanboy. or maybe i am. i just adapted to it. considered how i could change it to suit me. and it suits me.

other things i want to mention. can hardly call a C binary bloat. why would i wanna kill my init?! didn't try that with openrc why would i want to try that with systemd? jail it? really? wow. and if you dont trust it, learn c and look in the code. it aint that hard.

ultimately i dont think it's about our approval. i've mentioned that before. devs will do what devs do. and before complaining to gentoo, there are the upstream devs that actually decide what they do with their time and project.

[saellaven]

you can't expect the entirety of the opensource world/linux world to follow suit to one philosophy.

erm, isn't that exactly what the systemd proponents are trying to force? Most of us don't care that systemd exists, we don't want to be forced to use it.

other people might want to move with the times. maybe some devs want modern tools. like binary logs. and not stick with 70's unix stuff.

Those who do not understand Unix are condemned to reinvent it, poorly.

i am not a systemd fanboy. or maybe i am. i just adapted to it. considered how i could change it to suit me. and it suits me.

Cool, it doesn't suit me or lots of other people. I'm happy for you. Don't force me to limit myself to your constraints.

other things i want to mention. can hardly call a C binary bloat. why would i wanna kill my init?! didn't try that with openrc why would i want to try that with systemd? jail it? really? wow. and if you dont trust it, learn c and look in the code. it aint that hard.

systemd is an uncontrolled, bloated, security nightmare. There's a reason why Linus will no longer accept code from Kay Sievers (one of the principle authors of systemd) and why kdbus was abandoned after their attempts to merge it despite it being an absolute mess.

Now, link all of that together with a demon that hands out root level security without credential verification. When you get pwned, don't blame us.

ultimately i dont think it's about our approval. i've mentioned that before. devs will do what devs do. and before complaining to gentoo, there are the upstream devs that actually decide what they do with their time and project.

Devs can do what devs want to do... Devs can also find themselves without a userbase anymore. It's also hard to blame upstream when Gentoo IS the upstream for one of the main systemd competitors, but the lead of that project is a systemd proponent that is in over his head and doesn't know what even a junior programmer should know (like what defines a public API).


Again, if systemd slices your bread and you love it, cool. Don't try to force it on me, since I fully understand what is wrong with it and don't want it anywhere near my system.

[axl]

i hope u realize i am just another gentoo user. not the projection you think of me to be.

how is it uncontrolled?

how would you know if it's bloated? just because you find redundancy a bloat, doesn't mean we still at a point in time where these 2 features (binary log and syslog on top of that) could be considered bloat. these modern computers are not choked by that. be real.

and finally. security nightmare? i am not aware of one single security problem around systemd.


HOWEVER in regards to Kay Sievers I wasn't even aware of his existence. not even sure it changes the overview.

devs want and need these modern non-traditional tools that allows them to look onto new markets. IF guys like this sievers can't delivers these tools, it doesn't mean the concept in itself is wrong and that we should stick in the 70s forever. what i am given to understand is that they are nice tools for devs, and sooner or later we will have to have them one way or another.

NO ONE said this guy sievers has to be the one to deliver. if people are motivated so much by what linus said, pick up the code and fix it.

it is still open source... right?

[Ant P.]

other things i want to mention. can hardly call a C binary bloat. why would i wanna kill my init?! didn't try that with openrc why would i want to try that with systemd? jail it? really? wow. and if you dont trust it, learn c and look in the code. it aint that hard.

The ridiculousness of your original comparison still seems to be lost on you.

[axl]

The ridiculousness of your original comparison still seems to be lost on you.

you mean being afraid of pid 1? or caging it?

no. being just as afraid of other stuff like apache. well, heartbleed. apache was in the victim list for that.

in the grand scheme of things, more people check out systemd code than openssl code. which turned out to be 1.

[Ant P.]

The ridiculousness of your original comparison still seems to be lost on you.

you mean being afraid of pid 1? or caging it?

Claiming that it's fine for PID 1 to have as much responsibility as half a dozen 3-decade-old userspace servers and that we don't worry about those stealing passwords so systemd gets a free pass too.

[axl]

The ridiculousness of your original comparison still seems to be lost on you.

you mean being afraid of pid 1? or caging it?

Claiming that it's fine for PID 1 to have as much responsibility as half a dozen 3-decade-old userspace servers and that we don't worry about those stealing passwords so systemd gets a free pass too.

i really dont know how you got to stealing passwords.

isn't in openrc pid 1 the init? what is the difference?



if i were to venture a guess, it's the unknown.



i mean, it's scary enough to have to deal with openrc. an outdated over-shelled init. that is... OUTDATED. but in order to know that u have to actually know that. but since u dont seem to have the technical competence to understand how openrc is outdated, how could you EVER be comfortable to a new system here to replace the old that you never understood.

that what you openrc guys dont get. and therefor wont ever get systemd. why am i wasting time?

[axl]

also - because it seems not everyone is getting it - not all devices have people crawling inside them. sysadmins.

who says ALL linuxes have to have people crawling inside them? some linuxes could just be ... something else.

and no linux device should be held hostage to you old farts

[Ant P.]

i really dont know how you got to stealing passwords.

Those were the exact words you used first to justify systemd. I simply quoted them back at you and now you're shifting goalposts.

isn't in openrc pid 1 the init? what is the difference?

PID 1 is not a part of openrc at all. The clue is in the name of openrc.

if i were to venture a guess, it's the unknown.

Knowing doesn't cost anything.

i mean, it's scary enough to have to deal with openrc. an outdated over-shelled init. that is... OUTDATED. but in order to know that u have to actually know that. but since u dont seem to have the technical competence to understand how openrc is outdated, how could you EVER be comfortable to a new system here to replace the old that you never understood.

that what you openrc guys dont get. and therefor wont ever get systemd. why am i wasting time?

I use runit, not openrc, and I write my own service scripts for it. You really need to back off and check your facts before you start running your mouth, dear end user.

[axl]

I write my own service scripts for it.

some people milk their own cow. collect their own eggs. plant their own crop. make their own bullets. survivalists. i don't.

i think i finished with slackware before i joined gentoo in 2001. just because i compile my own code doesn't mean i have to live in the past.

PS. i didn't introduce passwords into the conversation. i just replied sarcastically. if that is "shifting goalposts"...

[khayyam]

i hope u realize i am just another gentoo user. not the projection you think of me to be.

axl ... as we all are, your point being? Should people here not respond to the arguments you've made above, would that be too much of a "projection"? You're playing the, now very old, systemd advocate game of retreat into 'persecution' when faced with criticisms of the thing you are endorsing, and when the claims made are laid bare, or countered. Yes, hate, hate, hate ... projection, projection, projection.

how is it uncontrolled?

That is too vague a question, I'm sure saellaven could probably qualify the meaning, but you could pick any number of reasons why this is the case, ie, its constant incorporation of previously separate services/features, the method, and extent to which, it is pushed into the ecosystem, the design and model it has of its role (which is expansive, and ill conceived), the dependency and place in relation to the kernel and userland .... I could go on.

how would you know if it's bloated? just because you find redundancy a bloat, doesn't mean we still at a point in time where these 2 features (binary log and syslog on top of that) could be considered bloat. these modern computers are not choked by that. be real.

The question of bloat isn't necessarily limited to logging, so while "bloat" is something of a relative term, given enough understand/experience, you can probably point to it ... but that is what the 'philosophy' you are dismissive of is effectively about: a way of thinking about a quantitative problem by breaking it down into component parts modelled on their relative, and relational, functions. That's not some legacy "70s" thunk, it is systematic modelling with the goal of understanding how systems (in the broadest sense of the word) function.

and finally. security nightmare? i am not aware of one single security problem around systemd.

... and because you're not aware of them they don't exist? That is not how security works, practically every security flaw is premised by design.

devs want and need these modern non-traditional tools that allows them to look onto new markets. IF guys like this sievers can't delivers these tools, it doesn't mean the concept in itself is wrong and that we should stick in the 70s forever. what i am given to understand is that they are nice tools for devs, and sooner or later we will have to have them one way or another.

You say "modern non-traditional tools" like this is some new-deal, or some sort of innovation, its not, on either count. You act as though "development" started anno systemd, and that "the 70's" (and what followed) were palaeolithic in cognitive terms compared with what systemd offers ... this is laughable, and the fact that you make this leap is more than likely due to your unfamiliarity with the subject.

NO ONE said this guy sievers has to be the one to deliver. if people are motivated so much by what linus said, pick up the code and fix it. it is still open source... right?

... which suggests its a good idea tout court, it just takes someone to take it to completion. No, it was a bad idea at inception, and no matter how much energy and resources thrown at it, it will likely remain so.

best ... khay

[axl]

i've also outgrown the quote by line approach. sorry. am disappointed khay is taking that approach.

if your first line is that you dont know what is my point... why would you post an interline post to fight what exactly?

is opensource code uncontrolled (see heartbleed bug).

can you complain about bloat? no. end of story.

can you quote something of the dimensions of the heartbleed bug dimensions that happened in systemd? no. it's just scary stories about pid1. so security is out.

$arguments = 0;

furthermore

# $arguments = NULL;


just sayin.

[axl]

to me, this discussion might go back to the 90s. back then i found out redhat is doing ports of newer kernel patches for older kernels. and it became a thing. and i was like... why not adopt the full kernel ?

i dislike terribly this tendency to keep your os STATIC.

[axl]

funny thing is, the end result, the gnome 3 desktop is exactly what it aims. a system u dont have to fiddle with. its a stolen idea from mac. but it's a good idea none the less.


and the comparison to m$... unfair.

[khayyam]

i've also outgrown the quote by line approach. sorry. am disappointed khay is taking that approach.

axl ... not by line, but by 'argument' ...

if your first line is that you dont know what is my point... why would you post an interline post to fight what exactly?

It's quite clear, by the fact that there is a quote above, what I'm responding to, and what "point", or lack thereof, I'm refering to. So, stawman argument there ...

is opensource code uncontrolled (see heartbleed bug).

I'm not going to respond to such rhetorical questions ... either have an counter/argument of some sort, or don't bother trying to engage me.

can you complain about bloat? no. end of story.

Conclusion doesn't follow premise ...

can you quote something of the dimensions of the heartbleed bug dimensions that happened in systemd? no. it's just scary stories about pid1. so security is out.

See the point I made above about "security" and respond to that, rather than use a strawman and damand that I answer to it.

$arguments = 0;

furthermore

# $arguments = NULL;

... geez ... with stuff like that you're basically waving a flag that says "I'm a troll".

khay

[miket]

Axl, it's true that any of Apache, PHP, MySQL, the MTA of your choice, or whatever other package might bobble your passwords because of some vulnerability. A strong mitigation, however, is that none of these deal with any but a small subset of the credentials in a system. They run in separate processes under separate logins. It is the kernel, which enforces authorization but has nothing to do with authentication, that keeps any one of these systems from breaching the walls and grabbing things from other parts of the system.

The systemd approach puts both authentication and authorization into one complicated and extensive system. Any breach in that one system breaks open the whole show.

All of these systems, from Apache, to the kernel, to systemd are all of course open-source. That's part of the point. Your tendency to point to systemd's being open-source and therefore inspectable somehow carries the implication that Apache, PHP, MySQL, Dovecot, Linux or whatever else are not inspectable.

More to the point, though, is the fact that the thing to fear is not some obvious backdoor that someone might code but rather the vulnerability that inadvertently got into the code despite the programmer and reviewers very much wanting to guard against vulnerbilities. (In other words, program bugs that have security implications.)

The thing here is that systemd sets things up for a single point of failure. If an attacker can breach that one system, he's got everything at once. If all he could breach were, for example, a PHP script, the damage would be more limited.

The operative adage here is the one that cautions against putting all your eggs into one basket. Drop that basket, and there go all your eggs. Funny, this is an old bit of wisdom. It has been part of the human heritage since before the dawn of recorded history. It dates well before the 1970's.

This brings things to an important point: you seem to want to fall into the fallacy that just because something is old, it is outdated and therefore must be replaced. A corollary is that one holds this position because it guards against the polar opposite: that nothing new is good.

The reality is that some new ideas are truly great things that improve on what we had in the past, but that other new ideas are not so hot. Sometimes these not-so-hot ideas can be tweaked to make them work well, but sometimes not.

Systemd started with a few good insights, but its developers in their ambitiousness took things way too far. The authentication/authorization functionality is just one case in point.


One curious thing I must point out: more than ten percent of all the posts you have ever made in the Gentoo forums (that's since 2002!) were on this one topic in the last three days.