SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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?
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?
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).
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?
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.
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.
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.
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
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.
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.
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
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.