Users/Developers Threatening Fork Of Debian GNU/Linux

[unperson]

If you want to understand why Poettering has won the Hitler-of-the-year-award several times in a row, this video is an eye-opening must-watch: https://www.youtube.com/watch?v=PmTUW-owa2w
Ironically it is not about Poettering/systemd, but about some other guy in the gameing industry. Just replace "Phil Fish" with "Lennart Poettering", "gamer" with "linux user" and "gaming industry" with "open source community" - works perfectly! (For the politically interrested: this also works very well with Julian Assange or Edward Snowden btw.)
[Yep, I registered just to post this, because it fits so well, and is very well done, imho.]

I have no idea what kind of person Ian is, but his proposal sounds reasonable and rational, imho. It might lead to a situation where (almost) everone is (more or less) happy. As long as it doesn't postpone Jessie for months, AND it doesn't turn Debian into an unmaintainable patchfest (that lags even more behind), I support it.

As for the systemd/Poettering hateclub: Learn to read! Then DO IT! It looks kinda low-IQ-ish to emotionally bash something that you obviously didn't even educate yourself about. Any linux-curious windows admin seems to be more knowledgable about systemd than the average hatclub member. The same FUD is just copied&pasted over and over again.

Also please cut the emo/ego/psycho crap! If you want to discuss systemd, why is all this boulevard BS relevant? Poettering is "arrogant"? Then READ about the TEAMs design decisions! READ WHY these decisions were made. Would YOU bow down to the demands of clueless people, if you were in charge of something, just so that no one could call you arrogant? If yes, then I hope you are never in charge of something outside your basement!
Seriously: most of the answers are out there, you just have to READ it! READING makes your brain hurt? And that somehow makes Poettering arrogant? If I was him, I'd have lost my patience a looong time ago and went Torvalds on you. Protip: if you don't understand something, chances are, YOU lack info and reflection, and it is YOUR job to fix that. Not the job of the person who already knows what the hell he/she is doing. Sometimes the arrogant snob actually knows better than the armchair expert who doesn't even read.

And stop jumping to conclusions, born out of fears, who are in turn born out of a lack of knowledge. Please learn to distinguish between the theories in your mind, and reality. For all I care YOU might be a child molester. But that doesn't magically make it a FACT. FACTS are facts, mkay? But I'm SURE Poettering, RedHat, the reptilians and Hitler are having a secret base on the darkside of the moon, and are using systemd as a straightforward tool for world domination ... or something.
Systemd is no more "forced upon you" than the kernel, your distribution, BSD base, HTTP, or anything else that you didn't (co-)develop yourself. You have to understand that someones got to do the job. And THOSE people set the rules of THEIR project. Open source is not a democracy, and never has been. Contribute or say thanks! If no one actually writes the software that provides an actual alternative to the 70something systemD modules, than OF COURSE there is no alternative, and devs/maintainers have no real choice (except being stuck with the status quo). But it seems the people who are actually skilled enough to write something that provides the same things as systemD without being systemD, see no point in that.
Also: one of the main ideas behind systemD IS some unification among distributions. And thats good, if you actually have to get things done in time and in budget. And you STILL have all the freedom. You still have freedom of choice where it matters, without doing shit. And you still have ALL freedoms if you can code and have lots of spare time.

About fragmentation and freedom of choice: I see freedom of choice as a fundamental strength of OS. But not on bullshit like how to set the hostname! Please explain the benefits of having several different ways of doing that. I'm pro choice where it actually makes a difference, and where there are several pros and cons between different solutions. But I'm also against brainless fragmentation just for the illusion of choice.

Everything else I wanted to say, has been mentioned by others.

Some more to READ (that makes me look arrogant, right?) and reflect on:

http://www.johndcook.com/blog/2010/06/30/where-the-unix-philosophy-breaks-down/

http://www.johndcook.com/blog/2012/05/25/unix-doesnt-follow-the-unix-philosophy/

http://lwn.net/Articles/576078/

http://0pointer.de/blog/projects/the-biggest-myths.html

http://en.wikipedia.org/wiki/Cognitive_dissonance

http://en.wikipedia.org/wiki/Fanaticism

PS: Watch the video! Internet mass-psychology 101.

[erendorn]

that was my thought as well

note that i thought about socket activation for use in an init
in practice (best case) it is no where near how it is explained on the blog (blog explains it as "start everything at once and let it resolve itself")
well.. it can be in general, but there are many details that basically make it the same as the "double fork then exit the first fork when ready to provide the service or exit with error if, well, error" approach that almost all daemons do anyway (i think udev doesn''t)

Hum, ok. I guess there's no reason it wouldn't work though (the "start everything" thing).
It's interesting to know, but the important thing to me is "does it work", and in practice it seems to. But I'm mostly sold because of the declarative+templatable config.

[finalzone]

So yea, I'm back to working on those Debian cases, currently updating the end of case 3 (the cross-examination where Ian talks about policy):

http://aceattorney.sparklin.org/V6_Test/player.html?trial_id=58428

And the entirety of case 4:
http://aceattorney.sparklin.org/V6_T...trial_id=60363

Trials failed to load

[pal666]

You are such a pleasant person to be conversing with, your manners and attitude are exemplary. /s

I appreciate you pointing out that journald can export to syslog, that is interesting. It is a pity that you are so aggressive and abrasive - your voice gets lost behind the shouting and insults. Take a chill pill, dude, how can you get so worked up about something like this?

i wouldn't be so abrasive to "bearded_linux_admin" who got enough brains to read the fucking manual before whining in public on topics settled few years ago

[pal666]

why is binary? well pretty much because is way easier to code and is very fast(but requires way more care for commit transactions)

i'd say it is binary because it is an indexed database and no bearded linux moron cries about binary postgres/mysql/etc files

[haplo602]

I think you mean "log formats", since different applications, libraries, and daemons write differently-formatted logs even to the same log file. So yes, with binary logs you need to know different formats for different platforms, but at least for a single platform the format will be consistent.

Does it matter to the discussion ? I think not ... if you are working on a single application (single log format) or a collective logging service for many applications (log formats), it is entirely irrelevant. The same principle applies.

[jrch2k8]

as i said, that blog is extremely imprecise and some times just plain wrong
for example the (now missing) picture that shows how socket activation "works" did not explain in any way how socket activation works and was wrong (incomplete=wrong)
best case socket activation would mean a process runs its startup (__libc_start, reading configs and such) then waits for the process it depends on to start completely
it is practically the same as normal start up because it reading that config/locale/whatever files would make the other process it depends on to fully start start slower
edit: it would also mean nonlinear disk access

stop giving me links
especially ones to propaganda material

well i would not say incomplete, i would say its implied after all is not a 101 guide to socket activation on systemd but more a basic conceptual image of it, anyway

socket activation works roughly like this,

1.) systemd read service and take the port(TCP/UDP) or path(Unix socket) along the service parameters and executable
2.) give the information to the kernel (ELF headers and symbol table have information enough about the process basic enviroment)<-- implicit
3.) CGroups/namespace/etc. created a basic isolation chamber(as requested in service file) including all basic enviroment like process IDs virtual table, variables, etc. <-- implicit, you don't need the actual running process yet.
4.) systemd link the path(in case of UNIX sockets) and open a secondary file descriptor as a buffer and monitor for activity(client socket request) <-- implied
4.a) systemd spawn microhttpd to hold the port and open a secondary file descriptor as a buffer and monitor for activity(client socket request)<-- implied
5.) if an request is processed, it informs systemd and keep the incoming data in the buffer but unlink it while systemd spawn the process
6.) once the process is up and linked(attached) to a socket/port systemd pass the buffer file descriptor and the process continues from there
7.) if certain conditions meet systemd signal(as POSIX signal) the process to stop/sleep/int/etc. and repeat from 4

notes:
* some stuff may have changed, haven't look at that code for a while (would be a good idea to ask in systemd mailling list)
* is an simplification obviously because i don't have the time to go line by line and explain it and there is lot of boiler plate infrastructure that i don't mention because i consider it blatantly obvious
* don't remember exactly if systemd uses libc/fork/execve unix way for starting processes or request it directly to cgroups, since its the actual one in control of the process to be execution context(but it won't be strange that cgroups itself will start the process using the same syscall libc_start_main uses with additional options in the background, ask tejun in LKML )
* don't remember the actual specific signals for each case but that is the general idea
* if i don't remember wrong it can be used this way too for tracking/spawn certain mount points with other config option for ondemand targets

[pal666]

yes
simple answer
i asked him because he was talking shit more then any other kind of information

no, it was not in the links
at least not the "how"

upstart, in contrast, resolves the dependency tree and then just starts the leaves in parallel
so where systemd "starts" a "service" and then starts the things it depends upon
upstart resolves everything then starts everything that has dependencies met at once

id say upstart does it a better way

you, like average dumbass systemd hater, got it wrong
systemd resolves dependencies and starts the leaves in parallel.
upstart has backwards depenencies i.e. when some event happens it does something.
i.e. if you have some device, it starts daemon responsible for it. even if you don't have client and don't need it(yet)
systemd does on demand startup. when it needs to start something it builds dependency graph and starts all leaves in parallel.
for example when client connects to server socket it starts server.
and it has much more leaves available on each step because it does not have false dependencies like "this server needs that server". because server really needs only socket and socket is opened by systemd and so it starts all servers in parallel.

[CanalGuada]

upstart, in contrast, resolves the dependency tree and then just starts the leaves in parallel
so where systemd "starts" a "service" and then starts the things it depends upon
upstart resolves everything then starts everything that has dependencies met at once

id say upstart does it a better way
although the difference is negligible in the end (unless a dependency fails)

best case socket activation would mean a process runs its startup (__libc_start, reading configs and such) then waits for the process it depends on to start completely
it is practically the same as normal start up because it reading that config/locale/whatever files would make the other process it depends on to fully start start slower

Upstart also provides socket activation feature since Natty Narwhal

Anyway, this is an optional feature in both init systems.

Fact is that if you really had to ensure that any service is fully started within a particular leaf of dependency tree, thus serialize more boot process the way sysVinit does, just don't use this feature, whether upstream developers provide you unit files for their own projects using it, and write other ones in order to meet your requirement.

[pal666]

This one I had to reply to.

1. Depending on how the log is serialised, you can lose one message, the whole log or just part of a message in case it is binary (damaged header groups or metadata). If the log is plaintext, you lose one character.
2. Every and I mean EVERY operating system out there has a text editor. In a fix you can move a file and read it anywhere. Guess what happens if you try that with a binary log.
3. see point 2. if you narrow your view only to linux then ok. but even there you have to meet specific requirements to read the binary logs.
4. well the UNIX principles are proven by decades of a rock solid operating system. have a look at how well windows did and how it does now when it started adopting them.

1,2,3 unixes had binary gzipped logs for eternity and somehow nobody cared
4. please name one unix which proved indexed databases in text files
0. JOURNALD CAN EXPORT TO SYSLOG FFS