LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Closed Thread
 
Search this Thread
Old 06-11-2013, 09:45 AM   #436
commandlinegamer
Member
 
Registered: Dec 2007
Posts: 80

Rep: Reputation: 12

Quote:
Originally Posted by jtsn View Post
I'm able to read C code and I've looked into systemd (and udev). It's poorly written. You can clearly see, that the author doesn't have enough experience for a project of such a scale. The whole design reflects this.

If I want mediocre code to be a central part of my IT, I can just go for a closed-source commercial OS.
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.
 
Old 06-11-2013, 10:05 AM   #437
jtsn
Member
 
Registered: Sep 2011
Location: Europe
Distribution: Slackware
Posts: 800

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
Quote:
Originally Posted by commandlinegamer View Post
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.
 
Old 06-11-2013, 10:08 AM   #438
elvis4526
Member
 
Registered: Aug 2011
Posts: 111

Rep: Reputation: Disabled
Quote:
Originally Posted by jtsn View Post
I'm able to read C code and I've looked into systemd (and udev). It's poorly written. You can clearly see, that the author doesn't have enough experience for a project of such a scale. The whole design reflects this.

If I want mediocre code to be a central part of my IT, I can just go for a closed-source commercial OS.
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.
 
Old 06-11-2013, 02:52 PM   #439
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, Slackware-14.1, PCBSD-10.0
Posts: 2,867
Blog Entries: 15

Rep: Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743
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.

Last edited by ReaperX7; 06-11-2013 at 03:00 PM.
 
Old 06-11-2013, 03:05 PM   #440
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Gentoo
Posts: 15,411
Blog Entries: 2

Rep: Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995
Quote:
Originally Posted by ReaperX7 View Post
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.
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.
 
Old 06-11-2013, 03:58 PM   #441
Myk267
Member
 
Registered: Apr 2012
Location: California
Distribution: Slackware, Debian
Posts: 89
Blog Entries: 8

Rep: Reputation: Disabled
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.

Quote:
Originally Posted by ruario View Post
Yeah but that it is not like I have to do equivalents to "priming the carburettor, setting the choke, and hand crank starting the engine" under Slackware's init. I am still just "turning the key" (switching the machine on) and perhaps it takes a little longer to get running but certainly not enough that I would give a crap.
I hope that enough people feel that way, too.

Quote:
Originally Posted by volkerdi View Post
What kind of ancient car do you have? All I have to do is pull the choke knob all the way out, make sure the power to the points is on (or it'll just crank without starting until the battery runs out), hold down the starter button on the dash until it fires up, and then ease the choke back in until it's running smooth.
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.
 
Old 06-11-2013, 05:05 PM   #442
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Gentoo
Posts: 15,411
Blog Entries: 2

Rep: Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995
Quote:
Originally Posted by Myk267 View Post
Did anyone check out this OpenRC vs systemd boot time comparison video? http://youtu.be/4NXMmHYNYfA Pretty speedy!
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.
 
Old 06-11-2013, 05:23 PM   #443
elvis4526
Member
 
Registered: Aug 2011
Posts: 111

Rep: Reputation: Disabled
Quote:
Originally Posted by ReaperX7 View Post
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.
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.

Last edited by elvis4526; 06-11-2013 at 05:24 PM.
 
2 members found this post helpful.
Old 06-11-2013, 05:52 PM   #444
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, Slackware-14.1, PCBSD-10.0
Posts: 2,867
Blog Entries: 15

Rep: Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743
Quote:
Originally Posted by elvis4526 View Post
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.
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.

Quote:
Originally Posted by TobiSGD View Post
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.
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.

Last edited by ReaperX7; 06-11-2013 at 05:58 PM.
 
Old 06-11-2013, 05:54 PM   #445
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 1,919

Rep: Reputation: Disabled
Quote:
Originally Posted by elvis4526 View Post
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.
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.
 
Old 06-11-2013, 06:03 PM   #446
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, Slackware-14.1, PCBSD-10.0
Posts: 2,867
Blog Entries: 15

Rep: Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743
Quote:
Originally Posted by Ser Olmy View Post
he's a poor project manager pushing code to be deployed that hasn't been through proper QA procedures
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.

Last edited by ReaperX7; 06-11-2013 at 06:08 PM.
 
Old 06-11-2013, 06:25 PM   #447
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.0
Posts: 2,242

Rep: Reputation: 614Reputation: 614Reputation: 614Reputation: 614Reputation: 614Reputation: 614
Quote:
Originally Posted by ReaperX7 View Post
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.
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.
Quote:
Originally Posted by ReaperX7 View Post
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.
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).
Quote:
Originally Posted by ReaperX7 View Post
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.
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.
Old 06-11-2013, 06:27 PM   #448
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Gentoo
Posts: 15,411
Blog Entries: 2

Rep: Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995
Quote:
Originally Posted by ReaperX7 View Post
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.
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.
Old 06-11-2013, 07:27 PM   #449
elvis4526
Member
 
Registered: Aug 2011
Posts: 111

Rep: Reputation: Disabled
Quote:
You've never answered mine either
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.
 
Old 06-11-2013, 07:36 PM   #450
elvis4526
Member
 
Registered: Aug 2011
Posts: 111

Rep: Reputation: Disabled
Quote:
when he is the one that just went forward and tried systemd on Slackware.
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.
 
  


Closed Thread

Tags
cgroups


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Slackware: Is Systemd Inevitable? LXer Syndicated Linux News 5 07-22-2013 04:54 AM
[SOLVED] slackware and systemd fl0 Slackware 512 08-29-2012 11:07 AM
slackware and systemd (OT) eloi Slackware 44 08-24-2012 04:36 PM
[SOLVED] systemd and Slackware's future kikinovak Slackware 95 07-14-2012 11:40 AM
Boot Delay 30min: systemd-analyze blame systemd-tmpfiles-setup.service BGHolmes Fedora 0 07-27-2011 09:02 AM


All times are GMT -5. The time now is 11:23 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration