[systemd-devel] What I think is really wrong with systemd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, sorry for another rant, but I'm a software developer and a user of a Linux-based operating system here. I read the post about at 0pointer.de about "myths about systemd". [1] I want to address the issue of it being monolithic. More specifically, I want to tell what where is that coming from. systemd started an an init system. It had an idea of doing one thing "the proper way" - of system init on Linux-based systems. That made the project easy to understand and follow. Now, as was written in that post, the project consists of over 69 binaries, where most of them are entirely optional. The problem with this project is not how it is written. It is how it is *packaged and distributed* to end-users. Luckily, I use Gentoo. I have Portage, which will happily compile the package on my system and I can tell it by USE flags what to compile and what not to. Other package managers doesn't work this way. They fetch *pre-compiled packages*. Now, what is the PACKAGE "systemd" doing? Init? Is it a HTTP server? A system logger? Something that uses QR codes? Can I replace it with another package? The answer is: no one but the developers know. The package doesn't even have an understandable version numbering. It is one increasing number. How is a package maintainer supposed to know if version change from 340 to 341 introduces major changes? I don't even know *what* changed unless I read a ChangeLog. Normally, you have a major version and a minor version. If the major version changes, it is an alarm to do throught testing to see if everything works wellon the new one. Minor changes are minor, so they require less testing. What this project needs is division of this one big have-it-all package into individual packages, each containing components for a specific purpose. There is nothing wrong with them depending on each other, but they should be in different packages, each having a separate build system and version, for the following reasons: 1) You as developers are more aware of what changes in the project, beause commits are associated with individual componenets. 2) If a component was a failure, you can just drop the package and work on another - nothing else needs work. Most importantly, the main component is not touched. 3) The people that are not involved with the developement are more aware what the suite of packages called systemd is actually composed of. Package maintainers can now block one component if there is something wrong with it, but not all the others. 4) The user can then install the init system from systemd, and keep their system logger. Example: systemd-logind should not pass the messages to another logger. The other projects should be encouraged to use systemd APIs/ABIs on Linux to get them. This makes systemd-logind more lightweight. 5) Most importantly: by such a split you future-proof the project as a whole. Someone might come up with a better solution for a component than you in the future. That someone should not fight with your system in order to use other components. It should be made easy and simple to replace any binary systemd uses now with another - with another PACKAGE. If systemd keeps going the way it does, it will eventually get forked, because it will become an unmaintainable mess when you notice something major in the system could be done better, and that better approach breaks everything else in the system. systemd works fine. NOW. I also would want it to work after 20 years, because I see good ideas here. Actually, I think this project's future is a "Linux-based Init and Service Management System Standard", where the systemd suite of packages is the reference implementation. [1] http://0pointer.de/blog/projects/the-biggest-myths.html -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV+R5zAAoJEDRBz9VZHKuW2psQAKiqMb0H8djvKcWanKsYguIg pUFp2e32rHUGMW7DVtF1pk18rYygq+6vOgi+ACQVLlHOL0nOxhwyjqSkfhVF/Ew6 p6worj+PZIuHiEE6VwMZ9v7ptlPFniLQc73avPv7661YpC7DIsQGlV5GmtmR+Q73 LwQsAm82f1NR8Oh8Ud0MgJRVBpY9NYAmN0PSJnSxfYmmx4epO9MtLAf0aG4pnhKc 13EmVcD3N+bkHk8jWo4X3o1DiDDDJ/afWBIqbHxd0Z7o9JHn2YCyAWcC4t0DO2Tu vUvlzhced8jfFMua+323XNXzSP6BsRoDWiit4qTXGW8ptXW1VNc3wRLtef4i3Jao 6owtN7NIaYHRAKymUJUad5XH7a6EwcOBu3wtZ0jAJMa/1MdmG1VPtXUVobEAzCEj vjm+X0aJMB5JkOPkmT9szm0QSQh0Uj4Cme3e6GwTppteZNga9s1OV068zB/gdDIB y7bHHSO6d4AN4tFQXYyX7P0cBsQ3HWIaqn+IIDnPEz/hwNeh+6yEHPzdktWX5ksg Z4V7IkVOHYS60ejlldhavNOM2fF/57OTC9HtWjU1cbjithKzNzbLmTzbpt/UI6Ha LVFqQnKLqwfMvP+IQMlE4+rTaBa7Jl/VgQaogxScO1W1TBV+Nf4IIubob7BTR834 Mv1H1NT/S3+rp98uMTud =6YJT -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What I think is really wrong with systemd
I wouldn't normally grace such rants with a reply, but I'll try and keep this one short. dott...@gmail.com wrote on 16/09/15 08:47: > Hi, sorry for another rant, but I'm a software developer and a user of > a Linux-based operating system here. > > I read the post about at 0pointer.de about "myths about systemd". [1] > I want to address the issue of it being monolithic. > More specifically, I want to tell what where is that coming from. > > systemd started an an init system. It had an idea of doing one thing > "the proper way" - of system init on Linux-based systems. > That made the project easy to understand and follow. > > Now, as was written in that post, the project consists of over 69 > binaries, where most of them are entirely optional. > > The problem with this project is not how it is written. > It is how it is *packaged and distributed* to end-users. > > Luckily, I use Gentoo. I have Portage, which will happily compile the > package on my system and I can tell it by USE flags what to compile > and what not to. Other package managers doesn't work this way. They > fetch *pre-compiled packages*. So basically you're complaining to the upstream systemd project about how downstreams consume it? You should really take this complaint to downstreams. > Now, what is the PACKAGE "systemd" doing? Init? Is it a HTTP server? > A system logger? Something that uses QR codes? Can I replace it with > another package? > > The answer is: no one but the developers know. Not true, the developers know, but also the downstream package maintainers know too - or at least they should know. It's their job to decide which components to use to build their operating system. > The package doesn't even have an understandable version numbering. It > is one increasing number. How is a package maintainer supposed to know > if version change from 340 to 341 introduces major changes? I don't > even know *what* changed unless I read a ChangeLog. Package maintainers are *expected* to read the changelog. This isn't some minor part of the operating system we're dealing with. These are the key building blocks that make up the very base of the userspace layer. If I'm using a distro, I want my package maintainer to at very least read the changelog, but ideally be much more informed than even that! > Normally, you have a major version and a minor version. If the major > version changes, it is an alarm to do throught testing to see if > everything works wellon the new one. Minor changes are minor, so they > require less testing. Minor, major etc., this doesn't matter. Even minor changes can introduce major bugs. The fact that someone arbitrarily decided "this is a minor change" doesn't make the change safe in any way. Testing of such key components should be the same regardless. Adopting such a scheme in a project like systemd serves no purpose but to create a fake illusion of "safeness". > What this project needs is division of this one big have-it-all > package into individual packages, each containing components for a > specific purpose. There is nothing wrong with them depending on each > other, but they should be in different packages, each having a > separate build system and version, for the following reasons: > > 1) You as developers are more aware of what changes in the project, >beause commits are associated with individual componenets. They already are, both in the commit message and simply by doing "git log" in the appropriate folders. > 2) If a component was a failure, you can just drop >the package and work on another - nothing else needs work. >Most importantly, the main component is not touched. This can still happen and is irrelevant to how the git repo is structured. > 3) The people that are not involved with the developement are more aware >what the suite of packages called systemd is actually composed of. >Package maintainers can now block one component if there is >something wrong with it, but not all the others. If this is how downstream want to work (i.e. provide competing component) then they can package things that way if they like. Doing it upstream has no purpose other than adding overhead. > 4) The user can then install the init system from systemd, and keep >their system logger. Example: systemd-logind should not pass the >messages to another logger. The other projects should be encouraged >to use systemd APIs/ABIs on Linux to get them. >This makes systemd-logind more lightweight. This shouldn't really be about user choice, but distributor choice. Distributors are welcome to package things as they wish within the basic constructs. Your example doesn't make sense. systemd-logind already does not pass message to another logger, it uses the journal exclusively. > 5) Most importantly: by such a split you future-proof the project >as a whole. Someone might come up with a better solution for >a component than you in the future. That someone should n
Re: [systemd-devel] What I think is really wrong with systemd
Thanks Colin for your reply! Colin Guthrie [2015-09-16 11:30 +0100]: > > Normally, you have a major version and a minor version. If the major > > version changes, it is an alarm to do throught testing to see if > > everything works wellon the new one. Minor changes are minor, so they > > require less testing. > > Minor, major etc., this doesn't matter. Even minor changes can introduce > major bugs. The fact that someone arbitrarily decided "this is a minor > change" doesn't make the change safe in any way. Testing of such key > components should be the same regardless. Adopting such a scheme in a > project like systemd serves no purpose but to create a fake illusion of > "safeness". I just want to emphasize this. We've seen the smallest bug fixes cause trouble in totally unexpected corners. Major new features are actually less risky, as nobody is relying on them yet. :-) Especially on desktops/phones/customer devices etc. the software world has pretty much moved from these "major new release every year" towards a continous delivery of features and fixes, together with continuous integration testing of those. The latter ensures that we don't break stuff no matter how big the change is (in theory at least, we all know practice..), and it tremendously helps to take pressure off developers to cram their feature into next week's deadline for feature freezes. I think in the server world stable releases with bug-fix only microreleases (backporting from trunk) are still much more common. This environment is rightfully more conservative, but I daresay that we'll see a shift towards continuous integration and delivery of new features as well. While systemd lives on both servers and clients, it's still being developed rather fast, and I don't think splitting it up into "new and shiny, but totally untested in the world out there" vs. "stable bug fix only releases which are missing features people are asking for" would make sense at this point. TL;DR: Version numbers become more and more meaningless. :-) Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What I think is really wrong with systemd
I actually believe that debian does some splitting, for example pam-systemd module is in a separate package. Actually I feel that particular case is wrong, but it happens there. I mean debian jessie, of course. W dniu 16.09.2015 o 12:30, Colin Guthrie pisze: I wouldn't normally grace such rants with a reply, but I'll try and keep this one short. dott...@gmail.com wrote on 16/09/15 08:47: Hi, sorry for another rant, but I'm a software developer and a user of a Linux-based operating system here. I read the post about at 0pointer.de about "myths about systemd". [1] I want to address the issue of it being monolithic. More specifically, I want to tell what where is that coming from. systemd started an an init system. It had an idea of doing one thing "the proper way" - of system init on Linux-based systems. That made the project easy to understand and follow. Now, as was written in that post, the project consists of over 69 binaries, where most of them are entirely optional. The problem with this project is not how it is written. It is how it is *packaged and distributed* to end-users. Luckily, I use Gentoo. I have Portage, which will happily compile the package on my system and I can tell it by USE flags what to compile and what not to. Other package managers doesn't work this way. They fetch *pre-compiled packages*. So basically you're complaining to the upstream systemd project about how downstreams consume it? You should really take this complaint to downstreams. Now, what is the PACKAGE "systemd" doing? Init? Is it a HTTP server? A system logger? Something that uses QR codes? Can I replace it with another package? The answer is: no one but the developers know. Not true, the developers know, but also the downstream package maintainers know too - or at least they should know. It's their job to decide which components to use to build their operating system. The package doesn't even have an understandable version numbering. It is one increasing number. How is a package maintainer supposed to know if version change from 340 to 341 introduces major changes? I don't even know *what* changed unless I read a ChangeLog. Package maintainers are *expected* to read the changelog. This isn't some minor part of the operating system we're dealing with. These are the key building blocks that make up the very base of the userspace layer. If I'm using a distro, I want my package maintainer to at very least read the changelog, but ideally be much more informed than even that! Normally, you have a major version and a minor version. If the major version changes, it is an alarm to do throught testing to see if everything works wellon the new one. Minor changes are minor, so they require less testing. Minor, major etc., this doesn't matter. Even minor changes can introduce major bugs. The fact that someone arbitrarily decided "this is a minor change" doesn't make the change safe in any way. Testing of such key components should be the same regardless. Adopting such a scheme in a project like systemd serves no purpose but to create a fake illusion of "safeness". What this project needs is division of this one big have-it-all package into individual packages, each containing components for a specific purpose. There is nothing wrong with them depending on each other, but they should be in different packages, each having a separate build system and version, for the following reasons: 1) You as developers are more aware of what changes in the project, beause commits are associated with individual componenets. They already are, both in the commit message and simply by doing "git log" in the appropriate folders. 2) If a component was a failure, you can just drop the package and work on another - nothing else needs work. Most importantly, the main component is not touched. This can still happen and is irrelevant to how the git repo is structured. 3) The people that are not involved with the developement are more aware what the suite of packages called systemd is actually composed of. Package maintainers can now block one component if there is something wrong with it, but not all the others. If this is how downstream want to work (i.e. provide competing component) then they can package things that way if they like. Doing it upstream has no purpose other than adding overhead. 4) The user can then install the init system from systemd, and keep their system logger. Example: systemd-logind should not pass the messages to another logger. The other projects should be encouraged to use systemd APIs/ABIs on Linux to get them. This makes systemd-logind more lightweight. This shouldn't really be about user choice, but distributor choice. Distributors are welcome to package things as they wish within the basic constructs. Your example doesn't make sense. systemd-logind already does not pass message to another logger, it uses the journal exclusively. 5) Most importantly:
Re: [systemd-devel] What I think is really wrong with systemd
Michał Zegan [2015-09-16 14:41 +0200]: > I actually believe that debian does some splitting, for example pam-systemd > module is in a separate package. Actually I feel that particular case is > wrong, but it happens there. I mean debian jessie, of course. FYI, this is required for supporting Multi-Arch, it's not wrong. Debian does split the package quite a bit, yes. All libraries, their -dev packages, and libnss*/libpam* need to be separate binaries, and udev and systemd-sysv need to be separate for supporting other init systems still. We also recently split out "systemd-container" for nspawn/machinectl/importd etc. so that we can enable all features without introducing big new dependencies into minimal systems. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to turn off some network interface?
Hello, no, the IP is fixed. I want to bring the interface down to reduce power usage. This machine has some special job where the LAN interface is only needed for about one minute a day. The idea is to enable the interface, start the software which does some network interaction and after that disable the interface again. Regards, Manuel On 09/13/2015 02:20 PM, Rosen, Rami wrote: Manuel, Just a short question: Is the interface you are talking about it configured to be a DHCP client ? (if it is so, it can be related to networkd DHCP implementation, which may be configured/changed) Regards, Rami Rosen Intel Corporation -Original Message- From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On Behalf Of Reindl Harald Sent: Sunday, September 13, 2015 2:41 PM To: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] How to turn off some network interface? Am 13.09.2015 um 13:28 schrieb Rosen, Rami: What do you mean by stopping networkd, can you elaborate a bit about what you want to achieve? If you want to stop the service, simply run "systemctl stop systemd-networkd". The after that ifconfig command, it won't start. If you want to disable one network interface (let's say eth0), then go to the proper configuration file under /etc/systemd/networkd and comment/disable it, and restart the networkd service by: systemctl restart systemd-networkd well, that's a little unfortune compared to a setup not using systemd-networkd where you can *temporary* disable interfaces just with "ifdown lan4" without changing a configuration the point is *temporary*, changing the config means it would be disabled at the next boot too, on a machine acting as router/switch temporary disable interfaces makes a lot of sense to disconnect a client from the network -Original Message- From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On Behalf Of Manuel Reimer Sent: Sunday, September 13, 2015 11:55 AM To: systemd-devel@lists.freedesktop.org Subject: [systemd-devel] How to turn off some network interface? Hello, it seems to be impossible to just stop networkd (keeps starting itself again). If I use "ifconfig" to turn off one NIC, then networkd immediately restarts it. What do I have to do to gain back control over my network interfaces? I want to be able to turn off one interface. Thanks in advance ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What I think is really wrong with systemd
Hi, On Wed, Sep 16, 2015 at 01:20:58PM +0200, Martin Pitt wrote: > Thanks Colin for your reply! > > Colin Guthrie [2015-09-16 11:30 +0100]: > > > Normally, you have a major version and a minor version. If the major > > > version changes, it is an alarm to do throught testing to see if > > > everything works wellon the new one. Minor changes are minor, so they > > > require less testing. > > > > Minor, major etc., this doesn't matter. Even minor changes can introduce > > major bugs. The fact that someone arbitrarily decided "this is a minor > > change" doesn't make the change safe in any way. Testing of such key > > components should be the same regardless. Adopting such a scheme in a > > project like systemd serves no purpose but to create a fake illusion of > > "safeness". > > I just want to emphasize this. We've seen the smallest bug fixes cause > trouble in totally unexpected corners. Major new features are actually > less risky, as nobody is relying on them yet. :-) > > Especially on desktops/phones/customer devices etc. the software world > has pretty much moved from these "major new release every year" > towards a continous delivery of features and fixes, together with > continuous integration testing of those. The latter ensures that we > don't break stuff no matter how big the change is (in theory at least, > we all know practice..), and it tremendously helps to take pressure > off developers to cram their feature into next week's deadline for > feature freezes. > Not to mention that the same rolling-release model was adopted by the kernel long time ago for similar reasons and much more ;-) @@@ To dottomi, the original poster: systemd is a core port of Linux ecosystems these days, just like the kernel. It's a foundation layer that finally brings some much needed order, coherency, and vertical integration to the mess that is Linux userspace. This vision is _way different_ from how Linux was built in the past, and people will need to re-learn things and ease out their own attachments to the old way of doing things. For more details, check Greg KH article on the futhre of Linux as a _tightly-coupled_ "core distro": https://plus.google.com/+gregkroahhartman/posts/V2t57Efkf1s This tight-coupling is the vision of things going forward; a tight core containing the kernel, kdbus IPC, systemd, polkit, logind, and other core userspace daemons. Initiatives like GNOME xdg-app [1], and new KDE versions [2] are also tightly-coupled with such core. Check the link at [2] to understand the valid reasons upstream developers are voting with their own development time for such coupling. Yes, this will leave people who enjoy configuring their systems to the smallest minutiae (Gentoo users, etc.) a little bit on the dust. But before putting all of the blame on systemd, please remember that: - This is the path most of the relevant upstream developers are embracing (Gnome, xdg-app, KDE) - This is also the path most of the industry has taken since the 2007 in the form of iOS, Android, OLPC [3], and Apple TV. - Surprise, surprise, this is also the same vision currently embraced in the serverland in form of CoreOS, etcd and fleet. Regards, [1] https://wiki.gnome.org/Projects/SandboxedApps [2] http://blog.davidedmundson.co.uk/blog/systemd-and-plasma [3] https://lwn.net/Articles/494095/ -- Ahmed Darwish http://darwish.chasingpointers.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What I think is really wrong with systemd
W dniu 16.09.2015 o 15:08, Martin Pitt pisze: Michał Zegan [2015-09-16 14:41 +0200]: I actually believe that debian does some splitting, for example pam-systemd module is in a separate package. Actually I feel that particular case is wrong, but it happens there. I mean debian jessie, of course. FYI, this is required for supporting Multi-Arch, it's not wrong. Actually I was not quite right, I think that what annoyed me was that the pam_systemd module was not installed by default. Debian does split the package quite a bit, yes. All libraries, their -dev packages, and libnss*/libpam* need to be separate binaries, and udev and systemd-sysv need to be separate for supporting other init systems still. We also recently split out "systemd-container" for nspawn/machinectl/importd etc. so that we can enable all features without introducing big new dependencies into minimal systems. Martin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What I think is really wrong with systemd
Am 16.09.2015 um 17:13 schrieb Ahmed S. Darwish: Not to mention that the same rolling-release model was adopted by the kernel long time ago for similar reasons and much more ;-) that is *not* true and won't become true by repeat it https://www.kernel.org/ mainline: 4.2 2015-08-30 stable: 4.1.7 2015-09-13 longterm: 3.18.21 2015-08-31 only systemd upstream has from the core component a "that is the new version with no major/minor" attitude and the kernel is the very last project to compare given "longterm: 2.6.32.67 2015-06-03" signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What I think is really wrong with systemd
On Wed, Sep 16, 2015 at 8:38 AM, Reindl Harald wrote: > Am 16.09.2015 um 17:13 schrieb Ahmed S. Darwish: >> >> Not to mention that the same rolling-release model was adopted by >> the kernel long time ago for similar reasons and much more ;-) > > that is *not* true and won't become true by repeat it > > https://www.kernel.org/ > > mainline: 4.2 2015-08-30 > stable: 4.1.7 2015-09-13 > longterm: 3.18.21 2015-08-31 > > only systemd upstream has from the core component a "that is the new version > with no major/minor" attitude and the kernel is the very last project to > compare given "longterm: 2.6.32.67 2015-06-03" nonsense. Only one of those three mentioned is actually "the linux kernel". The other two are independently running forks that "the linux kernel" maintainer does not maintain. So, he's actually entirely correct to paraphrase that the linux kernel community is using a rolling release model. The fact that individuals make "respins" that follow a non-rolling release model does not diminish the truth of that in any way possible. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What I think is really wrong with systemd
On Wed, Sep 16, 2015 at 05:38:55PM +0200, Reindl Harald wrote: > > > Am 16.09.2015 um 17:13 schrieb Ahmed S. Darwish: > >Not to mention that the same rolling-release model was adopted by > >the kernel long time ago for similar reasons and much more ;-) > > that is *not* true and won't become true by repeat it > > https://www.kernel.org/ > > mainline: 4.2 2015-08-30 > stable: 4.1.7 2015-09-13 > longterm: 3.18.21 2015-08-31 > > only systemd upstream has from the core component a "that is the new version > with no major/minor" attitude and the kernel is the very last project to > compare given "longterm: 2.6.32.67 2015-06-03" I love it when people make their own argument for themselves, without even realizing it :) Those "longterm/stable" kernels contain bugfixes _only_, just like the "stable" systemd release tree works. No new features happen on those kernel branches, and I _STRONGLY_ recommend using the latest kernel release always, as sometimes I don't always catch all bugfixes that might be relevant for the stable kernel releases, I'm only one person. So, I'm glad you like the systemd method of releases, they copied what we do in the kernel exactly the same way. greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What I think is really wrong with systemd
dott...@gmail.com: If systemd keeps going the way it does, it will eventually get forked, [...] Psst! This already happened, a year ago. Read http://uselessd.darknedgy.net/ to learn what happened. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What I think is really wrong with systemd
On 16 September 2015 at 16:52, Kok, Auke-jan H wrote: > On Wed, Sep 16, 2015 at 8:38 AM, Reindl Harald wrote: >> Am 16.09.2015 um 17:13 schrieb Ahmed S. Darwish: >>> >>> Not to mention that the same rolling-release model was adopted by >>> the kernel long time ago for similar reasons and much more ;-) >> >> that is *not* true and won't become true by repeat it >> >> https://www.kernel.org/ >> >> mainline: 4.2 2015-08-30 >> stable: 4.1.7 2015-09-13 >> longterm: 3.18.21 2015-08-31 >> >> only systemd upstream has from the core component a "that is the new version >> with no major/minor" attitude and the kernel is the very last project to >> compare given "longterm: 2.6.32.67 2015-06-03" > > nonsense. Only one of those three mentioned is actually "the linux > kernel". The other two are independently running forks that "the linux > kernel" maintainer does not maintain. > > So, he's actually entirely correct to paraphrase that the linux kernel > community is using a rolling release model. The fact that individuals > make "respins" that follow a non-rolling release model does not > diminish the truth of that in any way possible. > To further resonate that. Just like with kernel, every vendor make their own longterm maintenance thing of systemd. Look at Centos vs Debian kernel, they are widely different, even if released from same series or at the same time. Ditto systemd, integration done in Debian, Ubuntu, openSUSE, Fedora are all different as well. To me this all looks like comparing kettle and pots. With calling systemd black in comparison to the kernel. -- Regards, Dimitri. 100 sleeps till Christmas https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [ANNOUNCE] Preliminary systemd.conf 2015 Schedule is now up!
Heya! Please see: http://0pointer.net/blog/preliminary-systemdconf-2015-schedule.html We'd like to thank everybody who submitted a presentation proposal! The response to the CfP was overwhelming, and our scheduled is now packed with exciting talks! See you in Berlin, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What I think is really wrong with systemd
On Wed, 16.09.15 09:47, dott...@gmail.com (dott...@gmail.com) wrote: > Now, as was written in that post, the project consists of over 69 > binaries, where most of them are entirely optional. It's 119 executables now, btw. > The problem with this project is not how it is written. > It is how it is *packaged and distributed* to end-users. systemd is not a product for "end-users". It's a set of basic building blocks distributions can build an OS from. It's not an app you install. Also, even if it was an "end user" product, we don't actually provide packages, not even dist tarballs. We provide people with sources, with a git tree, and it's up to them how they decide to package that. > Now, what is the PACKAGE "systemd" doing? Init? Is it a HTTP server? > A system logger? Something that uses QR codes? Can I replace it with > another package? > > The answer is: no one but the developers know. I am pretty sure the packagers know pretty well how they decide to package systemd. > The package doesn't even have an understandable version numbering. It > is one increasing number. How is a package maintainer supposed to know > if version change from 340 to 341 introduces major changes? I don't > even know *what* changed unless I read a ChangeLog. Well, it's supposed to be a steady stream of smaller additions instead of major feature additions in long intervals. Also, as we are not an end-user product, we don't market things to anyone. Major/minor version numbers are a marketing tool, that's all, and as that's not a priority for us, hence we don't do it. If you so will, the only folks who should care about our updates are those who are technically versed enough to not need version numbers, but who can read our NEWS files. > What this project needs is division of this one big have-it-all > package into individual packages, each containing components for a > specific purpose. Like the linux kernel we keep all components of our system together in one repo, under a single release schedule and without stable, internal APIs. Splitting things up into multiple projects means more code duplication (since you cannot share code as freely), means commiting to stable, internal APIs, encourages bitrotting, and increases complexity, at no gain. Also, it's pretty irrelevant how we distribute things, downstream packagers should decide how they package things, and if they do that in one, or split out. By having everything in one tree, we simplify everything drastically, while still giving downstreams the chance to split things up, if they wish. > There is nothing wrong with them depending on each > other, but they should be in different packages, each having a > separate build system and version, for the following reasons: Nope, no way. We need to keep things maintainable. And you don't make things maintainable by exploding the number of packages, by forcing us to stabilize internal APIs and by creating a network of versioned dependencies (dependency hell!) between these packages. > 1) You as developers are more aware of what changes in the project, >beause commits are associated with individual componenets. I am pretty sure watching one repo is much easier than watching many. > 2) If a component was a failure, you can just drop >the package and work on another - nothing else needs work. >Most importantly, the main component is not touched. We can drop things from our git tree from time to time, that requires no splitting up of repos. > 3) The people that are not involved with the developement are more aware >what the suite of packages called systemd is actually composed of. >Package maintainers can now block one component if there is >something wrong with it, but not all the others. Talk to your distro maintainer. > 4) The user can then install the init system from systemd, and keep >their system logger. Example: systemd-logind should not pass the >messages to another logger. The other projects should be encouraged >to use systemd APIs/ABIs on Linux to get them. >This makes systemd-logind more lightweight. Hmm? by not using systemd's APIs directly, but by abstracting things away and not being able to rely on the availability of a single backend you certainly make things way heavier -- certainly the absolute opposite of "lightweight". Not having to care about stability of internal interfaces, sharing code, and being able to rely on the same set of backends in the right version makes things lightweight and robust, since you don't have to deal with multiple codepaths, with abstracting, with versioning, and dependency hell. > 5) Most importantly: by such a split you future-proof the project >as a whole. Someone might come up with a better solution for >a component than you in the future. That someone should not fight >with your system in order to use other components. It should be made >easy and simple to replace any binary systemd uses now >with another
Re: [systemd-devel] What I think is really wrong with systemd
Am 16.09.2015 um 17:52 schrieb Kok, Auke-jan H: On Wed, Sep 16, 2015 at 8:38 AM, Reindl Harald wrote: Am 16.09.2015 um 17:13 schrieb Ahmed S. Darwish: Not to mention that the same rolling-release model was adopted by the kernel long time ago for similar reasons and much more ;-) that is *not* true and won't become true by repeat it https://www.kernel.org/ mainline: 4.2 2015-08-30 stable: 4.1.7 2015-09-13 longterm: 3.18.21 2015-08-31 only systemd upstream has from the core component a "that is the new version with no major/minor" attitude and the kernel is the very last project to compare given "longterm: 2.6.32.67 2015-06-03" nonsense. Only one of those three mentioned is actually "the linux kernel". The other two are independently running forks that "the linux kernel" maintainer does not maintain. So, he's actually entirely correct to paraphrase that the linux kernel community is using a rolling release model. The fact that individuals make "respins" that follow a non-rolling release model does not diminish the truth of that in any way possible nonsense 4.1.x will get a lot more updates while 4.2.x get them too systemd never ever had any minor release signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What I think is really wrong with systemd
Am 17.09.2015 um 03:08 schrieb Jon Stanley: On Wed, Sep 16, 2015 at 8:45 PM, Reindl Harald wrote: nonsense 4.1.x will get a lot more updates while 4.2.x get them too systemd never ever had any minor release That is the nonsense. 4.1.x is not maintained by the kernel maintainer, but rather someone interested in maintaining old releases of the kernel. Linus has zero to do with what goes into 4.1.x (other than Greg's rule that all changes in linux-stable must be in the mainline kernel) Linus is not the Kernel alone frankly, i don't matter which person is repsonsible for what exactly - kernel.org provides minor releases while systemd just a idiotoic number and any downstream needs to cherry pick in case of the kernel any downstream just takes the tarball from kernel.org and is done - hence 4.1.7-200.fc22.x86_64 #1 SMP Mon Sep 14 20:19:24 UTC 2015 directly from the Fedora buildservers that's a large difference signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
