Shared publicly  - 
I don't get it.

#systemd is a pile of crap, not only conceptually speaking, but its inner code is absolute junk.
Please fellow programmers around, have a look at this and tell me you don't feel like a 8 years old beginner programmer commited this.
So, what the F*CK is happening to the GNU/Linux world? It's not even about portability, but about the quality of one of the most important part of the system that is becoming some kind of microsoft-windows-like-quality software.
Watching +Redhat importing that mess does not surprise me more than that, they're used to it ( hey, they hired +Lennart Poettering ), but #Archlinux   ? Some other distros are thinking about it, did they actually read that messy code ? Hardcoded paths everywhere, bugs, mistakes, unmaintainable spaghetti all around...
Please, it's no more about the concept (which is inherently stupid) but about the stability of GNU/Linux, either on the desktop but most of all on the server.
That kind of sh*t happened before and is happening again, please distros (+Debian and friends), watch out before that pig makes it even harder to fix... which is what they're looking for.

Remember UNIX philosophy: Write programs that do one thing and do it well.
Yuri Albuquerque's profile photoNicolas Vigier's profile photoCirrus McMinor's profile photoDavid Delassus's profile photo
"Remember UNIX philosophy: Write programs that do one thing and do it well."

It's about the shell, not the whole system.

But, what the hell is that code ? Oo
L.P doesn't follow UNIX/POSIX philosophy on purpose, because he thinks it's outdated and it does not allow him to implement the 'features' he wants. Let's proove him wrong.
Crappy code ! Hah ! Why don't we send him patches? Because at this state of bloatness, it'd be better to rewrite everything from scratch.

It's funny, I've heard those critics before ("code sucks", "is buggy"); but was never presented with a list of examples. Because then if you point to the actual flaws, they might actually be fixed…
As technologists we should address the technical concerns, not just throw generic "taste" critics against the wall. The thing is, I trust you have indeed found some (big?) mistakes in the systemd code base. But I'm afraid staying vague only lessens your arguments.
There's this wonderful elegant clean simple system available in a number of different forms to suit all tastes.  Its developers put strong emphasis on code quality and elegance.  It's actually been around in older but similar forms for a lot longer than any of this GNU stuff.

(Anisse, anyone versed in C programming would toss that code, and probably their cookies too, after two seconds of looking at practically any central source module in the link Emile posted!)
Yes, we are departing from BSD ideas and the unix philosophy and is probably gonna hurt purists and people stuck in the 70.. you will have to deal with it.
It's not about purism nor being stuck anywhere, it's about bad design and horrible coding practices; just an example, some people posted screenshots of their servers being stuck because dbus failed to load and systemd was simply incapable of going further. Deal with it? Please, it's not a simple vi vs emacs discussion, more how do I keep my servers out of that nightmare.
systemd requires dbus. if it does not start then there is something else wrong. 
+Cristian Rodriguez people who do not learn from (computing) history get to relive it. I would neither aim to reinvent the wheel before it was made round, nor to redo "abandoned because of unmaintainability" mistakes.
+Cristian Rodriguez yeah right, an init process depending on a desktop oriented IPC daemon, nothing more natural. Anyway, I won't argue on the design, which I find totally absurd, my point here is that this central software is one of the most broken piece of code I've ever read. I'm talking about stability and maintainability, not even elegance, we now are very far from the latter...
+Greg A. Woods : using the "you're not clever enough to understand" argument to sidestep talking about the real problems is exactly what I was criticizing; neither +Emile Heitor nor you provided real examples. Just generic critics, when we have real code, that can be easily reviewed and linked to. It's especially weird because Emile says he's read the code.
Yes, it requires dbus shared libraries in order to support "services of type "dbus".. in the same way a shell and libc are required to boot in other init systems, if any of this components fail then there is trouble.
btw..could you point out exactly what piece of code is broken  ? or is just it does not adhere to your particular prefered style   or that it assumes it will run only in recentish linux/glibc  
Like both Emile and I have said, pick any central source file in the entire project and read it and weep.  All its code is horrid.  Know that all the rest of the main sources are just as bad, if not worse.  I dare say some second year students could write better code.  Attempting to fix it would then invite the burning question of its design, so it's not even worth going there.
+Cristian Rodriguez spot the issue:
static bool check_nss(void) { void *dl; if ((dl = dlopen("", RTLD_LAZY))) { dlclose(dl); return true; } return false; }

first file I opened, first page. I'll skip looking further, thanks.
first hostnamed is not required and does not run from PID1 .. that check is only present to emit a warning when the optional nss_myhostname is not installed in the system., it does no work with that library..that's the task of the OS..
Do you also have an implacable argument for the hardcoded (yes, hardcoded) fstab? hardcoded paths with explicit "\0" in defined strings? loads of repeated integers instead of, at least, a define or a const int? those are only examples...
Anyway, I won't go into this, that's useless. My point here is to warn that something dirty is about to land on our servers, I just want distro developers to look at that mess and think about the average quality of the software before integrating it.
+Cristian Rodriguez since you seem to miss the point: and version 2 of that lib will be the only one possible ever? One flat out doesn't program that way, it's a maintenance nightmare.
the library version is under the control and written by the same author..
some fingers should get cut... for good.

but heh, after pulseaudio what did you expect ? :)
Oh gosh, THAT was uggly code! +Cristian Rodriguez that the "control" are by same author is no excuse.  What happen when we change author of that code?
Distributions will deal with the theorical non-problem you are making up.
+Cristian Rodriguez so you want to put the problem solving on the distributions instead of solving that in the source?  Instead of solving in one place, you suggest to solve it on 10-50 places?  Gooood....
What's more puzzling is how he managed to get a job at RedHat, you'd assume they have technical interviews ;-)
Nope, it's been a decade since I last read code from Linux before +Emile Heitor brought the fun with the tree above :-p
See my recent comment about CLOCK_MONOTONIC_RAW for another sad tale..... and one right in the core, so to speak.
It is just so crazy, just looking at random files in the src and it is really ugly: <= High level of portability and cross-distribution support :p => Sorry, where can I find the path to fsck? just in the middle of this source file:
        cmdline[i++] = "/sbin/fsck";
        cmdline[i++] = "-a";
        cmdline[i++] = "-T";
        cmdline[i++] = "-l"; 
re: hardcoded xml , surprise surprise, that 's the way dbus interfaces are exposed to other processes..and are generally autogenerated..
Re: fsck, yeah that's ugly.. though all distributions have either symlinks or the fsck binary there.. probably will go away someday when fsck provides a shared library interface..
I don't understand the method of criticism here. I can understand if a few think this codebase is unmaintanable, then say why... But so far in this thread I see endless criticism and very few suggestions to the team that has been working hard on this project. What the hell.
not had a problem with the transition to systemd here on arch. only notcable difference from init is faster boot/shutdown. I do miss ye olde rc.conf / init method  , but ill deal , nobody is forcing me to use arch/systemd
John: exactly, it is a futile exercise, fundamentally because it is a clash of cultures. if someone points to an actual bug I might go and fix it myself, so far only style concerns, ad-hominems and I must say, a deep ignorance on how the linux userland works nowdays.
It's not about style, it's about broken code, a subtle difference which you apparently can't grasp
Why the hell aren't you creating a patch for the code? #systemd  may not be the best example of good code, but it is far ahead of its predecessor. So stop whining and go make it a better init system, damn it!

If you don't care about #systemd , you have no obligations of using it.
+S.P. Zeidler If libnss_myhostname changes SONAME then you want dlopen to fail. What do you want the behaviour here to be?
jay kay
+Yuri Albuquerque +Cristian Rodriguez you are also free to pick up all poop you find on your side-walk, you may also call your city's cleaning service.
I prefer beat on the dirty neighbour than cleaning his own poop. you get it?
+jay kay except that on the case of free software, people as YOU AND ME are the poop cleaners. If you want just to whine about how some piece of free software is bad, but has no interest in helping (at least filling bug reports or trying to be polite to the developers on the problems you have with the system), then go away. Free software is not meant for you.

We are a community that creates software based on our needs, and we help each other because we have one common goal. Nobody here creates open source for free only because we're good guys. I guarantee you that the #systemd  developers are not creating #systemd  because you need it for free.

Or are you actually paying the #systemd  developers for them implementing everything as you want them to be? (As you're paying taxes for your city's cleaning service).

I thought not.
+Florent V fsck is (if installed) guaranteed by the FHS to be in /sbin. For comparative purposes, try which contains such gems as:

/* Mount it */
if (run_program(0, "/sbin/mount -rt %s /dev/%s /mnt2", localfs_fs, localfs_dev))


#ifndef NO_LFS
return (access("/sbin/fsck_lfs", X_OK) == 0 &&
access("/sbin/mount_lfs", X_OK) == 0 &&
access("/sbin/newfs_lfs", X_OK) == 0);

When you're writing code targeted at a specific platform, it's perfectly acceptable to depend on assumptions that the platform guarantees are true. systemd is Linux-specific code, just like sysinst is NetBSD-specific code. There really isn't a problem with the code you're quoting.
Have you looked at the *BSD libc's? The only thing that made my eyes bleed more was openssl, glibc and gnu coreutils. Seriously openssl is hideous (grep '#if 0').
What is the problem with hardcoded fstab path ? Is there any reason that someone would want to use something else than /etc/fstab ?

Hardcoding path for things that have no reason to change is not a bad idea I think. If there is any real reason for making a path configurable then it should be easy to add a define as necessary.

There are already some defines for paths that are distro specific :
+Anisse A. You are missing my point. This code looks bad to me, and I don't want my services handled by something that looks like it's developed by people who don't care.
You are dealing with a critical part of the system here, show that you are up to the task and write code that looks robust.

It's really just about trust and confidence.
For now, I am worried that systemd is adopted by more and more distributions. Everything is going way too fast with this project, and I don't want to be in the bus when it will hit the wall...
+Benoit Depail The XML is the D-Bus interface definition. Of course it's hardcoded. It's the equivalent of a prototype - if you changed it without changing any of the backing functions things would be broken. Other than that, your objection seems to be that the functions don't include documentation of the arguments? There's an argument in favour of that(*), but it's hardly ubiquitous. Of the first 10 files I randomly looked at in the NetBSD tree, one had a comment for the single function it contained.

(*) There's another argument that says if your internal code is unclear enough that you need documentation for the arguments, you should rewrite that code.
I'm talking about this :

if (argc == 2 && streq(argv[1], "--introspect")) {
//do something

if (argc != 1) {
log_error("This program takes no arguments.");
// [...]

Why pretending the program takes no arguments when it does ?

As for the D-Bus interface, thanks for the explanation. I guess that since systemd is so tightly bound with dbus there is no real solution here...
+Benoit Depail The introspection code is an internal implementation detail - nobody should be calling it by hand. Whether to expose it as a documented argument is very much a stylistic issue, not a code quality issue.
jay kay
+Yuri Albuquerque nobody's whining here, this is legitimate talk/opinions on a publicly released software. I try (probably in vain) to understand the complicated mind of yours:
- you consider free software a pooping machine.
- you consider +Debian and others like +Slackware a pooping place.
- you consider yourself a "poop cleaner".
- and because people are not paid they have the right to poop everywhere.
for the sake of free software I hope I'm mistaken.
+jay kay yeah, you really didn't follow. I'm just saying that if something is wrong and you know how to correct it, it's better to correct it than whine about it.

I would like to help give this some direction.

I know of a very solid way to judge if something is given enough thought to its design.

There is a phrase in engineering that has merit to test this......

"If you can't put it in writing, then you don't understand it well enough."

People, please follow the link I give in my previous post.

Skip reading replies 1 &2, and look at the third one.

I have given questions that should be answered.

I tried to see if they could be answered. But no one really was able to actually answer them.

I have done a thorough analysis of how systemd is dangerous if these questions can't be answered.

Because, if no one can answer them, then no one understands systemd well enough.

And that is dangerous to go forward with something that isn't really understood.

Please do not argue with me here, because I am not arguing with you.

I am giving you a definitive way of settling this issue.

Please read it to understand why and how it is a solid test of merit.

It is not understood what can go wrong with it if you cannot first identify what it is.

Let that be a judge of the merits of the questions.
+Christoph Thompson
 I understand that -> if you think we are simply complaining, then we should come to the understanding that -> if systemd is not for us then we should simply move on.

However, I believe that you have misjudged what we are saying.

I think that the fundamental message many are presenting is that -> systemd is a hazard, and we are trying to cast a light on this hazard so that others do not fall prey to the dangers of systemd.

This is not so much complaining as it is a heads up to watch out for problems with systemd that will affect people if they use it.

While I respect that others might not agree, I do think it is an important step some must take to warn others of what they think is honestly a hazard to those who might not be able to recognize it.
Add a comment...