That's not necessarily anything new though. For as long as I can remember Linux has been criticised for having poorly written code compared to the *BSDs.

The kernel itself is okay to my standards, for the parts I've seen so far and I was tinkering with. Of course I haven't looked into every driver in the tree. The GNU userland is a different story, especially GNU autoconf/automake/autobreak/autohell. The base and build system is where BSD shines. Although I don't mind the GNU stuff that much, if something sucks I can replace it.

I'm far away from being a C professional, so I would like to know what exactly do you have to say against systemd code.
From what I saw, the code is understandable and non-portable on non-Linux system.

Elvis... you obviously don't get it when it comes to using stable applications versus unstable applications. Slackware does NOT use unstable projects as part of it's infrastructure. Udev has become just about as bad as systemd because each new release adds some new issue that the previous didn't have. In fact there is a slowly growing consensus that udev has a few flaws the developers aren't able to fix, or unwilling to fix, however save that for another topic.

Systemd is NOT a stabilized project. Far from it. It's still in the Alpha-class of software meaning its under a severe load of testing and development to even get it into the BETA stages, and near enough stability to begin proper deployment.

Slackware has a rigid history of only using stable and trusted software, not unstable, BETA, Alpha, or developmental testing software.

The point of why we are against it, is because we are against it's overly rushed to being mass deployed even while it's Alpha-class software before it can be matured. Given enough time, testing, and the ability of systemd to stabilize and properly mature, it could become the next real successor to SysVInit, but it's NOT there yet.

Lennart isn't the brightest lightbulb when it comes to software classifications and deployment. He has pushed for unstable and developmental/experimental software to be pushed out without proper testing claiming it's ready to use when it isn't. Need proof, go track the history of PulseAudio on Ubuntu. It's really a good doorway into how this man thinks and operates. Granted he is a brilliant developer, but his understanding of how things work in the real world is very slipshod at best.

SysVInit, Upstart, and various other Init projects have been years in development with stable releases whereas systemd hasn't had a single stable release yet. By comparison, OpenRC, Upstart, RUnit, and S6 are far more stable projects even if they haven't released anything new in the last few years.

Not all software needs regular cycle releases to be classed as stable. Some projects can have a release of their last version of software years ago, but it's still stable, works, and may only need a maintenance patch to build on newer systems, but otherwise it's still stable.

The point that systemd is non-portable does raise questions as to why it's being so badly wanted. Linux is a different OS than BSD, Solaris, etc. but all UNIX and UNIX-like operating systems should be able to share things between each other with some degree of commonality. That what makes UNIX and other UNIX-like systems desirable to UNIX Enthusiasts. Portability means more people can use and benefit from your project.

Oh, come on. How can you blame Lennart for mistakes that were obviously made by Canonical? He has not pushed PulseAudio onto Ubuntu, that were the Ubuntu developers.

Today's lesson is that car analogies get out of hand quick.

Did anyone check out this OpenRC vs systemd boot time comparison video? http://youtu.be/4NXMmHYNYfA Pretty speedy!

I'm pretty neutral on the inits, on the whole. I think that each one carries it's set of trade offs around. And despite it's ever growing scope and giant list of features, systemd can't escape having both values and costs associated with it's use. Those things have to be a lot more carefully accounted for than looking on the systemd feature page and noticing that there's a lot more things in the systemd column. I ought to stop, though, because nobody is paying me play backseat BDFL.

I hope that enough people feel that way, too.

I don't; My theoretical car was only created to join in on the hyperbole.
Though, to add some counterpoint: our oldest car is a '72, and the newest is a '06, and even though the new one is pretty dependable, the old one is an order of magnitude easier to debug. Hmm.

This looks like parallel starting of services was disabled in OpenRC (which it is by default). So I would consider this comparison flawed at best (because of not enabling it) or simply useless, because the creator of the video failed to provide that important information.

I asked about why the codebase of systemd isn't clean. I wanted technical proofs (maybe some snippet of the codebase) to show me how systemd code is dirty.
You aren't a programmer, therefore you can't properly answer my question.

2 members found this post helpful.

You've never answered mine either... and I could care less about programming when I know a damn project is still in the Alpha software stages.

You don't get it, and obviously you're too convoluted and biased to even understand that software that isn't in the fully tested release stages will probably never be used in Slackware. Alpha, Beta, Release Candidate, Developmental, and Experimental software will probably never be used in Slackware because it's UNSTABLE and CAN BREAK THE SYSTEM! This is why Slackware has been a success and has lasted for so long.

Obviously if you used Slackware, Elvis, which clearly you don't or lack any real working knowledge of this distribution, you would know that all ton of time and effort goes into Slackware to ensure that the system is going to be as stable as possible.

Slackware isn't like ArchLinux throwing caution to the wind, using unstable, untested, and unrefined software that has a chance of breaking the system even at the lowest levels. Sorry, but if you like this, then please by all means STOP USING SLACKWARE.

Now if you can't read and understand that in plain and simple English then God help you!

Do you build a house on a poor or unstable foundation? No you don't, and the same goes for an operating system. The core programs of the system must be stable for all software to be stable.

Actually Lennart did release PulseAudio as ready and stable when Canonical grabbed it and started using it. It was only later after Canonical started using it that Lennart told them their implementation of PulseAudio was wrong, and that it would break the audio services.

If Lennart had released it under the notion of being Alpha, Beta, or Experimental software Canonical would have probably never touched it.

I'm not much of a programmer either, so I'm hardly qualified to judge the general quality of the codebase. However, I'm sure we can all agree that while shoddy code may actually work a lot of the time, good code should always work.

As I'm sure you know, Mr. Poettering has a less than stellar record when it comes to producing code that works well. Whether that's because he's a mediocre programmer producing substandard code or it's because he's a poor project manager pushing code to be deployed that hasn't been through proper QA procedures is not for me to say, but something is surely amiss.

PS: Not that it necessarily means an awful lot, but few programmers are bestowed the dubious honour of having other programmers create a petition for them to stop writing useless programs.

You kinda said your answer. He does fail miserably at correctly labeling his projects upon release. As I noted earlier, most of the code he has pushed out as "Final Release", is actually more suited to Alpha, Beta, RC, or Experimental class software that should be used with safety precautions.

Yes Shoddy coding can work, and it can work well, but at some point it will break down.

Example:

Final Fantasy 7 was a great game and was well coded for the PSOne. It worked very well and had few bugs that were anywhere near game breaking. There were a few noticeable, but nothing catastrophic. When the game was later ported to the PC by Eidos, the game suffered numerous glitches, bugs, and had a terrible codebase that would allow the game only to be ran on Windows 9x/ME. The port sadly faded into obscurity thanks to being so poorly designed and few people could ever run a system stably enough to get past the Chocobo races. Most people simply crashed at this point and gave up on the game. If you attempted to run the game on 2000 or XP, you were out of luck, and while an XP patch did exist, the game still would break down at the Chocobo races.

I thought, by the title and discussion, that this thread was meant to discuss the possible inevitability of systemd inclusion in Slackware, which suggests a longer timescale. When did it suddenly become a discussion about why systemd isn't ready for inclusion *now*? If we assume that systemd does become more stable and bug-free over time, but retains the same basic principles, will it then be fit for inclusion? You have suddenly departed from your prior vision to suggest that the only reason systemd shouldn't be included is because it is (or should be) in alpha. It is a mixed message at best.
While Slackware does tend to favour stability over bleeding edge, there are new and emerging technologies that have been included in Slackware over the years. HAL, ConsoleKit/PolicyKit, udisks/udisks2, .... And I don't think anyone can say that KDE4 included with Slackware 13.0 was 100% stable. Certainly Slackware waited as long as it could before switching from 3.5 to 4.x, but KDE 4.2.x was rc-level at best. Of course I don't blame Pat or the Slackware team for this -- but the switch to KDE 4.x made me permanently abandon KDE in Slackware (and elsewhere).
The adoption of Pulse was a choice -- it was never forced on anyone. All (or almost all?) existing and new software continued to support ALSA directly. Systemd's adoption of udev is the hand-forcing event and is entirely different than the Pulse situation; any comparison of the two is misguided.

2 members found this post helpful.

PulseAudio 1.0 (1.0 is usally what makes the first stable version in an OSS project) was released in 2011. PulseAudio was first used in Ubuntu in 8.04. This is quite contrary to what you are stating. Pushing PulseAudio into Ubuntu at that state was in no way Lennarts fault, it were Ubuntu developers that have done it and Ubuntu QA that failed with testing it.

Back to systemd, Red Hat is currently testing it in their Alpha for RHEL 7, the Beta is expected to come soon, so systemd can not be as experimental as you claim, otherwise they wouldn't use it in RHEL.

Also, elvis asked specifically jtsn about his claim of the code quality of systemd, this has nothing to do with which state a project must be in to be integrated into Slackware. Also, the claim that elvis does not have "any real working knowledge" of Slackware is quite funny, when he is the one that just went forward and tried systemd on Slackware.

All in all, with your style of heated argumentation and almost personal attacks you are doing yourself and your credibility not a favor, IMHO.

2 members found this post helpful.

I don't have any obligation to answer any of your questions directed to me.
My question about systemd codebase uglyness on the other hand wasn't for you.

For the record the github repo is now offline since it was too cubersome to maintain everything alone.
And yes, I did sucessfully port systemd to slackware, I had it on my laptop, it was working great.
The only problem was maintaining all the packages that need to be recompiled against systemd to be working.
For instance, Xorg would totally freeze at startup if it is not being recompiled against systemd.

I stop working on this port because nobody seems to care about systemd in the Slackware community so when the port was working, I learned what I wanted to learn and I didn't see the point to continue any further since nobody was showing interest in this.