LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
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, 08:46 PM   #451
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, Slackware-14.1, PCBSD-10.0
Posts: 3,004
Blog Entries: 15

Rep: Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753

Quote:
Originally Posted by elvis4526 View Post
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.
Why does that just not sound right?

Last edited by ReaperX7; 06-11-2013 at 08:49 PM.
 
1 members found this post helpful.
Old 06-11-2013, 08:54 PM   #452
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,517
Blog Entries: 2

Rep: Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018
Quote:
Originally Posted by ReaperX7 View Post
Why does that just not sound right?
Yeah, explain please why that doesn't sound right to you? Since systemd comes with its own udev and Xorg has udev as dependency a recompile is simply necessary. So what isn't right about that?
 
Old 06-11-2013, 09:01 PM   #453
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, Slackware-14.1, PCBSD-10.0
Posts: 3,004
Blog Entries: 15

Rep: Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753
It just seems that systemd wants and has to be a required dependency for everything in the system regardless if the udev in it and the stand-alone udev are practically the same thing. Whats so wrong about stating the obvious?

Udev as it is, is extracted from the systemd sources, so why is it not the same udev? Why is the systemd-udev different from the standalone udev if they are from the same systemd source repository?

Isn't that basically a design flaw that somehow two different udevs can exist from the same sources that are supposed from a single source that software can't use the same udev but has to use another?

I though this was all supposed to be a drop-in replacement, not a drop-in and rebuild everything from scratch replacement? Well? Is X11 dependent on udev or systemd? Which is it?

Last edited by ReaperX7; 06-11-2013 at 09:04 PM.
 
Old 06-11-2013, 09:05 PM   #454
elvis4526
Member
 
Registered: Aug 2011
Posts: 112

Rep: Reputation: Disabled
Quote:
Originally Posted by ReaperX7 View Post
Why does that just not sound right?
Standalone udev and the udev in systemd aren't identical.
I'll do some research about this, wait a couple of minutes.

EDIT: Slackware 14 is using udev 182, which is the version right before systemd and udev got merged together. When I built systemd on slackware, I chose the latest upstream version. Hell, between udev-182 and systemd-204, there has been like 20 release of systemd.
I think it's reasonable if packages compiled against an udev version which is one year old can't always be executed correctly on a machine with the latest udev version (systemd).

Last edited by elvis4526; 06-11-2013 at 09:29 PM.
 
Old 06-11-2013, 09:25 PM   #455
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, Slackware-14.1, PCBSD-10.0
Posts: 3,004
Blog Entries: 15

Rep: Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753
Seems like systemd is more trouble than it's worth even in maintaining the packages built around it.

Another question, but if, for example, a system is built around systemd-1.88_x86_64, and a security patch comes out for version 1.89, wouldn't you basically have to rebuild all the software that's tied to systemd to work with the 1.89 version to prevent any problems? I know some programs can work with a baseline version like building for GTK2-2.10.4 and you have GTK2-2.12.9, but aren't core critical systems different?

Last edited by ReaperX7; 06-11-2013 at 09:27 PM.
 
Old 06-11-2013, 10:14 PM   #456
fatalfrrog
Member
 
Registered: May 2011
Distribution: Slackware
Posts: 46

Rep: Reputation: 15
Quote:
Originally Posted by elvis4526 View Post
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.
I would love to see this. I don't think I could contribute much other than testing though, which I'd definitely do.
 
Old 06-11-2013, 10:14 PM   #457
jtsn
Member
 
Registered: Sep 2011
Location: Europe
Distribution: Slackware
Posts: 803

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
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.
This is not about snippets. The whole codebase is a undocumented mess. Many source files without a single comment in it, poorly named identifiers, mile-long functions with dozens of locals, literal constants scattered all over the code and so on...

You can read code from the Linux-Kernel and instantly know what it is doing, thanks to Documentation/CodingStyle and rigid commit rules. In comparison systemd code looks like disassembler output.

It's just hacked ad-hoc, there is no concept and no design behind it. That's fine for a dostuff.c with less than 10k LOC in a single source file, but not for a project of this size. Once LP moves on, this thing will become completely unmaintainable and follow hald into the abyss.

But way more funnier is, how DISTRO_PORTING has changed since 2010:
Code:
        We are interested in merging your changes upstream, if they
        are for a big, and well-known distribution. Unfortunately we
        don't have the time and resources to maintain
        distribution-specific patches for all distributions on the
        planet, hence please do not send us patches that adds systemd
        support to non-mainstream or niche distributions.
Since 2013:
Code:
        We are generally do no longer accept distribution specific
        patches to systemd upstream. If you have to make changes to
        systemd's source code to make it work on your distribution:
        unless your code is generic enough to be generally useful we
        are unlikely to merge it. Please always consider adopting the
        upstream defaults. If that's not possible please maintain the
        relevant patches downstream.
 
1 members found this post helpful.
Old 06-11-2013, 10:17 PM   #458
elvis4526
Member
 
Registered: Aug 2011
Posts: 112

Rep: Reputation: Disabled
Quote:
Originally Posted by ReaperX7 View Post
Seems like systemd is more trouble than it's worth even in maintaining the packages built around it.

Another question, but if, for example, a system is built around systemd-1.88_x86_64, and a security patch comes out for version 1.89, wouldn't you basically have to rebuild all the software that's tied to systemd to work with the 1.89 version to prevent any problems? I know some programs can work with a baseline version like building for GTK2-2.10.4 and you have GTK2-2.12.9, but aren't core critical systems different?
From a distribution maintainer point of view:

For distributions that do not accept new versions in their repos (like debian stable), if this is a serious security issue, they will just have to backport the patch to the version of systemd that they currently use, so nothing needs to be recompiled since it is almost the same version. This process is applied by several distribution. Even Pat is backporting security patch for Slackware !

For the rolling-release, they will just update to the latest version available upstream and they will rebuild all the reverse-dependencie of systemd (aka the stuff that need to be recompiled against systemd).

For both point view, it doesn't change anything for the end-user of the distribution.

I hope I answered your question.
 
Old 06-11-2013, 10:28 PM   #459
jens
Senior Member
 
Registered: May 2004
Location: Belgium
Distribution: Debian, Slackware, Fedora
Posts: 1,193

Rep: Reputation: 159Reputation: 159
Quote:
Originally Posted by ReaperX7 View Post
Why does that just not sound right?
Quote:
Originally Posted by ReaperX7 View Post
It just seems that systemd wants and has to be a required dependency for everything in the system regardless if the udev in it and the stand-alone udev are practically the same thing. Whats so wrong about stating the obvious?

Udev as it is, is extracted from the systemd sources, so why is it not the same udev? Why is the systemd-udev different from the standalone udev if they are from the same systemd source repository?

Isn't that basically a design flaw that somehow two different udevs can exist from the same sources that are supposed from a single source that software can't use the same udev but has to use another?

I though this was all supposed to be a drop-in replacement, not a drop-in and rebuild everything from scratch replacement? Well? Is X11 dependent on udev or systemd? Which is it?
Survey answers part 1: systemd has too many dependencies, or it is bloated, or it does too many things, or is too complex (2013-06-09)

The top concern shared by most people is:

systemd has too many dependencies, or it is bloated, or it does too many things, or is too complex

Now this concern actually has a lot of different facets, and I am trying to share my opinion on each of them.

http://people.debian.org/~stapelberg...emd-bloat.html

systemd’s dependencies and installation footprint

This page lists systemd 204’s dependencies and explains what they are used for. It is supposed to contain facts, not opinion. For the corresponding opinion blog post, see http://people.debian.org/~stapelberg...emd-bloat.html. In case you want to reproduce these findings, the .deb I used to gather data can be downloaded.

http://people.debian.org/~stapelberg...endencies.html

...from Michael Stapelberg’s Blog.

PS: ... and seriously, systemd is _very_ well documented.
If you don't understand it's code that's mostly your problem.

Last edited by jens; 06-11-2013 at 10:54 PM.
 
Old 06-11-2013, 10:34 PM   #460
elvis4526
Member
 
Registered: Aug 2011
Posts: 112

Rep: Reputation: Disabled
Quote:
Originally Posted by jtsn View Post
This is not about snippets. The whole codebase is a undocumented mess. Many source files without a single comment in it, poorly named identifiers, mile-long functions with dozens of locals, literal constants scattered all over the code and so on...

You can read code from the Linux-Kernel and instantly know what it is doing, thanks to Documentation/CodingStyle and rigid commit rules. In comparison systemd code looks like disassembler output.

It's just hacked ad-hoc, there is no concept and no design behind it. That's fine for a dostuff.c with less than 10k LOC in a single source file, but not for a project of this size. Once LP moves on, this thing will become completely unmaintainable and follow hald into the abyss.

But way more funnier is, how DISTRO_PORTING has changed since 2010:
Code:
        We are interested in merging your changes upstream, if they
        are for a big, and well-known distribution. Unfortunately we
        don't have the time and resources to maintain
        distribution-specific patches for all distributions on the
        planet, hence please do not send us patches that adds systemd
        support to non-mainstream or niche distributions.
Since 2013:
Code:
        We are generally do no longer accept distribution specific
        patches to systemd upstream. If you have to make changes to
        systemd's source code to make it work on your distribution:
        unless your code is generic enough to be generally useful we
        are unlikely to merge it. Please always consider adopting the
        upstream defaults. If that's not possible please maintain the
        relevant patches downstream.
Indeed the sources files of systemd don't contain a lot of comments. I can't judge if it is a bad thing or not, but it is not because there are no comment in it that it is badly designed. What I can say is that the sources of all the different component of systemd are clearly seperated.

Oh and they documented almost all their APIs, they wrote big man page against all the utilites they ship, etc...

If it is that poorly designed and you can't show me a real example of something they did that you could have done better, I guess it's not that bad.

They want their stuff to be standarized across all distributions, it doesn't make sense anymore to accept all distro-specific patch if they want systemd to be the same on all distro using it.

Last edited by elvis4526; 06-11-2013 at 10:36 PM.
 
Old 06-11-2013, 10:52 PM   #461
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, Slackware-14.1, PCBSD-10.0
Posts: 3,004
Blog Entries: 15

Rep: Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753
Quote:
Originally Posted by elvis4526 View Post
Indeed the sources files of systemd don't contain a lot of comments. I can't judge if it is a bad thing or not, but it is not because there are no comment in it that it is badly designed. What I can say is that the sources of all the different component of systemd are clearly seperated.

Oh and they documented almost all their APIs, they wrote big man page against all the utilites they ship, etc...

If it is that poorly designed and you can't show me a real example of something they did that you could have done better, I guess it's not that bad.

They want their stuff to be standarized across all distributions, it doesn't make sense anymore to accept all distro-specific patch if they want systemd to be the same on all distro using it.
Software that isn't well documented, even in source gets easily complex when attempting to deal with it. Linux distributions and software by nature all revolve around software being well documented.

Being standardized means vanilla code has to work on all distributions equally, but often if downstream patches are needed, it's very few to minimize the problems when dealing back with the upstream.

Quote:
Originally Posted by jens View Post
systemd’s dependencies and installation footprint

This page lists systemd 204’s dependencies and explains what they are used for. It is supposed to contain facts, not opinion. For the corresponding opinion blog post, see http://people.debian.org/~stapelberg...emd-bloat.html. In case you want to reproduce these findings, the .deb I used to gather data can be downloaded.

http://people.debian.org/~stapelberg...endencies.html
204 dependencies?! Are you f---ing kidding me?

Are these even part of your standard minimalist Linux installation and/or basic GNU/OS?

Last edited by ReaperX7; 06-11-2013 at 10:55 PM.
 
1 members found this post helpful.
Old 06-11-2013, 10:56 PM   #462
jens
Senior Member
 
Registered: May 2004
Location: Belgium
Distribution: Debian, Slackware, Fedora
Posts: 1,193

Rep: Reputation: 159Reputation: 159
Quote:
Originally Posted by ReaperX7 View Post
204 dependencies?! Are you f---ing kidding me?
Yes.
I like spreading fud about init systems.

Read the bloody code or move on (non of your arguments make any sense).

Last edited by jens; 06-11-2013 at 11:08 PM.
 
Old 06-11-2013, 11:17 PM   #463
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, Slackware-14.1, PCBSD-10.0
Posts: 3,004
Blog Entries: 15

Rep: Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753
Quote:
Originally Posted by jens View Post
Yes.
I like spreading fud about init systems.

Read the bloody code or move on (non of your arguments make any sense).
No need to be rude also...

...and I'm not the only person not making sense either.

Last edited by ReaperX7; 06-11-2013 at 11:25 PM.
 
Old 06-11-2013, 11:34 PM   #464
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,517
Blog Entries: 2

Rep: Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018
Quote:
Originally Posted by ReaperX7 View Post
204 dependencies?! Are you f---ing kidding me?

Are these even part of your standard minimalist Linux installation and/or basic GNU/OS?
It is not 204 dependencies, it is systemd 204's dependencies. Like in Debian 7's repositories.
 
Old 06-11-2013, 11:38 PM   #465
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.1
Posts: 1,473

Rep: Reputation: 412Reputation: 412Reputation: 412Reputation: 412Reputation: 412
Quote:
Originally Posted by jens View Post
Yes.
I like spreading fud about init systems.

Read the bloody code or move on (non of your arguments make any sense).
Code:
# ldd /sbin/init | wc -l
3
#
Am I missing something?
 
2 members found this post helpful.
  


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 05:47 AM.

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