Red Hat Flag
Or, What Is Red Hat Doing To Linux?
I’ve seen what to me are disturbing patterns in what’s happening with Red Hat’s influence on core components used by Linux distributions. The latest came just after I discovered that some Flash-based DRM schemes are now using HAL for enforcement. As consolekit has always behaved like a broken DRM scheme, denying the user permission to use their own system, I wondered what was next now that HAL is deprecated – consolekit?
Then I read that udev is now being added to the systemd code, and Red Hat is sounding like they won’t support it unless you integrate it with systemd. Next, I read that systemd is now being expanded to replace consolekit/policykit!
It makes me wonder, now that a few Red Hat employees seem to be in control of the core components used by most distributions, what is their game?
I can’t answer that at present – it’s a question. I keep thinking I need to look into all this and write about it, but I’m loaded with projects right now. I dropped a few links to the above issues in this reply to a poor unsuspecting reader who unknowingly opened the subject with me. ;) So for now, I just wanted to point out that discussion and some of the links there – at least make yourself aware of these changes so you can give your distro feedback, and also make careful choices.
Me, I’m already looking to take whatever road systemd is not on.
Update: A well deserved rant on this from a (now former) Arch Linux user who describes how these changes are affecting that distro, with links to some mailing list discussions and related material.
Followup: Gentoo On systemd, Torvalds On Bullshit, udev Forked
34 Comments
Sorry, the comment form is closed at this time.
IgnorantGuru's Blog 
I occasionally visit your blog, and it has been a few weeks since my last visit. Today I was wondering what are your thoughts about systemd, and voilà the first post on the homepage refers to it!!
###
at least make yourself aware of these changes so you can give your distro feedback, and also make careful choices.
###
Unfortunately this seems to be of no effect in my case. I am a long time arch user, and the developers have already decided to take the systemd road. There were a lot of flame wars on the arch-general mailing list, but the developers have made their intentions clear. They unanimously support systemd. I’ll probably eventually leave the distro once they stop supporting initscripts.
But then the question comes, which distro? Does the siduction team intend to switch over to systemd? In any case let us know which distro you’ll be using in the future.
Keep up the good work.
It serves as a warning – never become dependent on a company, be it Google, MS or Red Hat.
Linus should however give his opinion. If he encourages this route then we can officially call the kernel the “Red Hat Linux Kernel”.
Dunno, as very little of this impact the kernel. Udev acts as the interface between the kernel an all this, in that Udev grabs the list of devices the kernel have detected, arranges the /dev tree and sits down to listen for hardware changes. So if you had a BSD kernel that could interface with Udev in the right way, you could swap one for the other and never notice the difference on the user space side where CK and the rest lives.
Best i can tell, RH is doing this because it fits into their corporate computing viewpoint.
What they want to create is a fine grained rights control system that can rival what MS provides via Windows and Active Directory. So rather than having one account, root, that can do anything and everything, you will have multiple accounts and groups that can do various things but not everything.
The issue is that this do not mesh well with experienced home users that want minimal complexity, as they have to build house of cards just so they can disable most of the access controls to get the features they want.
I think that most users of Arch, Slack and similar are old school, people that know computing from the DOS era were a few files was all one needed to keep track off to have a working, streamlined system.
But most people now do not know DOS from a games console…
Looks like systemd also wants to control the system logs. Probably cron will be next. As a Fedora user, I’ve been using systemd for a while. It works well, boots really fast, but I would really prefer a script based init that I can hack on. Looks like I’ll have to learn a lot and roll my own init.
Personally speaking, I have never had any issues with ConsoleKit on Ubuntu. From what I understand, ConsoleKit is meant to be a daemon that tracks which user is currently physically using the system, and is being for, among other things, figuring out which pulseaudio instance should output sound, and which gnome-power-manager instance should manage the system’s power settings. This is great stuff if you have multiple user accounts logged on the same computer (e.g. if you use LightDM’s guest account feature), and it conveniently stays out of your way if you’re not attempting to do any voodoo magic on your system.
As for SystemD replacing ConsoleKit, it does look like things are progressing in that direction, but at least for the foreseeable future, Ubuntu, Debian, and any other distros that don’t use SystemD will probably keep ConsoleKit around, at least until they switch to SystemD (if ever), or a separate solution is developed.
I am using systemd on Arch but only because that is the way Arch is going, it seems they are going to drop sysvinit support eventually so no point in waiting until the inevitable happens. I would rather have the choice of staying with sysvinit or using systemd and given that choice I would stay with sysvinit. There is no guarantee that jumping distros would ensure continued use of sysvinit either.
To be honest I am not sure if systemd is a good or bad thing but it doesn’t feel good right now. I don’t run any of the major Desktop Environments, I just use openbox and the old Xfe FM and devmon and I can’t help but feel systemd is a bit overkill for my simple setup of zero features and lots of speed.
In LFS I have just had to extract udev from systemd to use udev without systemd but for how long will that be possible? (rhetorical).
I guess it is a case of waiting and seeing what happens but I am not a happy bunny.
I could well be taking the same road as the ‘ignorantguru’, so please keep us informed.
HI!
Why spacefm – is not default file manager in LXDE, if spacefm better then the pcmanfm?
maybe cos spacefm requires gtk 2.24.X and glib 2.32.X, udev 176 and gvfs 1.7, wheantime pcmanfm only requires gtk 2.20 and glib 2.26, no udev, and gvfs 1.7
Editor’s Note: Actually spacefm doesn’t require or use gvfs at all, and some of the above version numbers are inaccurate as well.
@Iguru
Your posts are very informative. More people like you must come together.
Haven’t visited your site in a while. Last time I commented was on an Aptosid related post, if I recall correctly. Hope you’re well, Ignorant Guru.
I’ve been a bit perplexed by these developments for a while now, to be honest. My reasons are manyfold and would take too long to explain. I suppose Red Hat’s doing what they feel serves them best, from a corporate/business perspective (what that is, I can only guess).
I’ve switched over to OpenBSD on all but one of my systems. Hardware support is definitely behind and it’s definitely not the most performance oriented operating system out there, but I find it serves me well, both in terms of the overall simplicity and uhm, “clenliness” (can’t think of a better word right now, but I think you get what I mean).
One has to wonder how much influence Red Hat is having on the other distros. I realize they (most probably) contribute the majority to Linux core projects/components, but I just find way too much abstraction in the most abstract places of the system. Even Arch seems to have abandoned the “keep it simple” policy they’re so proud of (truth be told, this was before systemd even came about). Seems that all the “choices” we once got when we started using Linux are slowly vanishing.
I don’t really have an answer to your question, I’m afraid.
Yeah the real power is found in a simple design. I don’t think these people are trying to create a powerful/flexible system, but a limiting and controlled one which better fits corporate desires.
Thanks for the OpenBSD info – I may try that again. Might even be worth a hardware change.
redhat its like mocosoft.. updates, updates, and wnat to control from system, and let alone and away the user/admin..
linux its like a ermitant, wanst simplicity and controls that owed, this dont like to redhat mocosoft windo-like purposes..
real linuxers zealot are like ermitant.. know what to do, wnat to tweakt what think will do, and need touch any piece of the system.. for tweakt or adapt…
i dont like win-hat! we like it? like-mocosoft… udisk and udev developers must think and merge with distribution developers should join to shake off the yoke of redhat windosers
I share your concerns, IGuru. I was a staunch supporter of Arch due to the degree of control and configurability I had over my system. When I learned that systemd was taking over their init scheme and no other option would be supported, I jumped ship. It wouldn’t have been so insulting if the developers were honest about their intentions. Instead, they mindlessly insist that it’s not being forced on users, while making cupsd, xorg-server, and more depend on it. I’m inclined to believe actions more than words, and this whole systemd debacle phraktured the trust I once had in Arch.
As a result, I’ve moved to Gentoo. Anyway.. I’m glad to see that I’m not alone in my opposition of systemd. If I ever get good enough in C, maybe I can join you in developing. :)
I read this post and the comment you referenced, but I can’t say I completely agree with you on this issue. I do agree with things like PolicyKit and ConsoleKit being broken, causing more trouble than they’re worth, and being a waste of cpu cycles to keep things running in the background (essentially anything PolicyKit-based will have an associated daemon running as root). Your posts have been very informative and I’ve managed to to rid my system of udisks, polkit, consolekit, gvfs, and more – the catch is though that the only file manager that isn’t completely crippled in this scenario is your own, spacefm. Its a good thing I actually like spacefm or I’d have to revert. It bothers me that it’s one of the few gtk2 programs on my system, though I’ve managed to mostly port it to gtk3 – but that’s for another time.
I have been keeping up with systemd, however I had never heard of any talk about it replacing policykit, and after searching I still haven’t. It successfully replaces consolekit for me, to which I say “good riddance”. It does not even have a strong dependence on policykit either, it builds without it and one of the only place it is used is for shutdown/reboot commanded over dbus, just like how consolekit does it. Despite that, you can still shutdown regularly as root or with an poweroff binary set with suid root, which is also provided. The deal about combining udev and systemd into one repository came out of systemd using a lot of udev code due to its ability to respond to device events and thus have services easily depend on them. Their merge came as a result of wanting to keep udev shared code in sync with systemd. The situation is far more systemd depending on udev than udev depending on systemd – and it has been said many times that udev will continue to run without systemd.
Using Linux for me has always been replacing something with something else that is broken in less annoying ways, and right now at least, I have to say that systemd “works for me”.
> …the catch is though that the only file manager that isn’t completely crippled in this scenario is your own, spacefm. Its a good thing I actually like spacefm or I’d have to revert. It bothers me that it’s one of the few gtk2 programs on my system, though I’ve managed to mostly port it to gtk3 – but that’s for another time.
I’m interested in feedback on the gtk3 issue. ie What are the dis/advantages of moving to gtk3, what are the dis/advantages of staying with gtk2 longer? Why does it bother you to have a gtk2 app? I haven’t looked into gtk3 in detail yet. I’ve heard some negatvie gossip on it, and was rather disappointed to see the mess they made of theme structure – not a good sign in my view. Overall I’d like to hear from users on gtk2 vs gtk3. Also, wrt to porting it, I hope you make your work available – could start a gtk3 branch on github. I won’t have time to get into this for awhile, but eventually it may happen, so any work you do will be helpful. Ideally it would be nice if it could be built with either via a configure option, but I don’t know how feasible that is.
> I have been keeping up with systemd, however I had never heard of any talk about it replacing policykit, and after searching I still haven’t.
You and most of the replies here are way ahead of me on this – I haven’t examined the details on what they’re doing. I did see this comment: “PK integration to verify console access to certain functionality”. I don’t know what their plans are wrt PK.
> It successfully replaces consolekit for me, to which I say “good riddance”. It does not even have a strong dependence on policykit either, it builds without it and one of the only place it is used is for shutdown/reboot commanded over dbus, just like how consolekit does it.
Thanks for the clarification. I don’t necessarily view this as a good thing as you do, though. I would rather be rid of consolekit (and the concept), rather than replace it. Nor do I like the dbus approach they’re using. Again, it reminds me more of a Microsoft approach which takes the ‘accessible’ out of Linux. Yes, you can dig into the dbus interface to make it work, but that’s a far cry from a powerful command line in my view.
> Their merge came as a result of wanting to keep udev shared code in sync with systemd. The situation is far more systemd depending on udev than udev depending on systemd – and it has been said many times that udev will continue to run without systemd.
Yes it has been said many times (I wonder why). Here you seem to be absorbing only the happy BS on the subject and not reading between the lines. While udev may run without systemd, it will not be well supported in this configuratiuon. You’re ignoring this:
Pretty clear. IOW I view the assurances that udev will remain indepedent as hollow spin – I don’t think that’s their intention at all. And given Red Hat’s (and these developers’) history for breaking everything they possibly can with unnecessary and unending changes, I think it’s a given that break it they will.
> Using Linux for me has always been replacing something with something else that is broken in less annoying ways, and right now at least, I have to say that systemd “works for me”.
Fair enough, but it’s also wise to ask not just is it working, but what direction is it taking? You yourself pointed out that almost every file manager requires you to use their solutions exclusively. Is that in the spirit of Linux? While short-term changes may be (and are often engineered to be) apparently desirable, where are they putting their chess pieces and to what end? Personally, I view most of these changes as going against some of the fundamental design concepts of Linux. These people have neither the vision nor the skill to take it anywhere ‘good’, and I think it’s a mistake to indiscriminately swallow eveything they offer (which is what most distros seem to be doing – read Comment 11 by sporkbox just above your comment).
On gtk3:
The only real disadvantage to migrating to gtk3 is the work involved, where the biggest pain comes from the migration from gdk drawing to cairo – which I still need to fix a bit. The advantages are mostly those inherent to gtk3 itself. The deprecations such as that of gdk drawing inspire much more powerful and flexible ways of achieving the same kind of result, giving you the ability to make better looking custom widgets, etc. Cairo is already the preferred method in gtk2, but it has no future and exposes comparatively little. The coding style changes (particularly the GSEAL stuff) is in my opinion especially because of the proper OO design allowing for values to be checked properly before succeeding at being assigned, cleaner code though in practice it is just more tedious work to do to port from gtk2 to gtk3. The theming api is much improved allowing for much more precise theming though the incompatibility with gtk2 themes is a sore point and the inconsistencies between gtk2 and gtk3 applications is always visible. It bothers me to have a gtk2 app mostly for boring reasons like consistency, and I generally love to be on the bleeding edge of everything even if I have to do the work myself to get there – I’ve ported a few gtk2 applications to gtk3 for my own benefit. The advantage of doing it now rather than later is that it is far easier to maintain gtk3 compatibility than continuing to work only with gtk2 then port to gtk3 later. This work would also allow for a lot of old gtk version checks to be removed (some of which are no longer relevant because of the minimum gtk version in configure). Having done almost all the work to get a gtk3 spacefm, a configure switch would be easy. I can toss up a few patches that are trivial changes that are completely gtk2 compatible and you should have no problem merging immediately (gtk deprecations, gseal) that are a nice hunk of the work. As previously mentioned, gdk-drawing to cairo is still gtk2 compatible, though in gtk3 some functions take a cairo_t instead of a gdkdrawable – but that’s mostly trivial, just requiring some ifdefs where any problems are found at compile-time rather than runtime. In general, gtk3 is only #3 because of the api break – things are mostly compatible. I’ll try to start a branch soon.
> You and most of the replies here are way ahead of me on this – I haven’t examined the details on what they’re doing. I did see this comment: “PK integration to verify console access to certain functionality”. I don’t know what their plans are wrt PK.
PolicyKit has a ConsoleKit backend, and now a systemd backend. This is mostly irrelevant if you don’t use PolicyKit. Since systemd has functionality to replace ConsoleKit, it is only natural to be able to do this. On to the usefulness of the concepts that ConsoleKit (and thus systemd) presents, these deal a lot more with multi-seat and/or multi-user environments. I’d assume more that you use your own computer and don’t share it with others – that makes just about all the functionality useless. The integration with PolicyKit to shutdown comes from the notion that if multiple users are logged in, you don’t want one user (who isn’t the admin) to be able to close everyone else’s sessions, short of physically turning off the power. On a single user system, this is silly and can only bring harm. On the multi-seat side, systemd (with its udev integration) is able to keep track of who is doing what where, associating resources with a particular desktop session. While this is possible otherwise, this is a better solution because it is able to be dynamic, while other solutions as of right now, are static configuration files. Again, this isn’t useful for a single-user machine. I’d like to hear more about what you specifically dislike about the concepts behind ConsoleKit.
The DBus aspects, as I’ve said before, are more for dealing with PolicyKit than anything else. Permissions and generally being allergic to running graphical applications as root gave the push to PolicyKit. I would be drinking the PolicyKit kool-aid if it was actually useful to me. If I was able to open a text editor, open a file owned by root and then save it while only having to enter my password (or the root password) rather than re-open the file as root, I’d like that. The closest thing I’ve seen is your spacefm, where I can actually copy a file to a root-owned folder and by typing a password, magic happens.
>Yes it has been said many times (I wonder why). Here you seem to be absorbing only the happy BS on the subject and not reading between the lines. While udev may run without systemd, it will not be well supported in this configuratiuon. You’re ignoring this:
>Lennart Poettering on udev-systemd:
>“Well, we intend to continue to make it possible to run udevd outside of systemd. But that’s about it. We will not polish that, or add new features to that or anything.
>OTOH we do polish behaviour of udev when used *within* systemd however, and that’s our primary focus.
>And what we will certainly not do is compromise the uniform integration into systemd for some cosmetic improvements for non-systemd systems.
>(Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven’t noticed it yet. I am looking forward to the day when we can drop that support entirely.)”
>Pretty clear. IOW I view the assurances that udev will remain indepedent as hollow spin – I don’t think that’s their intention at all. And given Red Hat’s (and these developers’) history for breaking everything they possibly can with unnecessary and unending changes, I think it’s a given that break it they will.
To this I have to say yes and no. Yes, it will be better supported in systemd, but that’s the nature of the beast – systemd is the only init system able to leverage udev within itself. Those extras won’t be ported everywhere else because they can’t be. Udev won’t work any worse than it does now. The biggest thing I see against systemd is that people view it as a monolithic beast. Instead they try to remove as much functionality as they can from PID 1 and put it into other processes. The ConsoleKit replacement is logind, and it is a service that can be disabled. Systemd remains lightweight, but features are added to the things associated with it. From this, I can honestly say that udev will never be a part of systemd, always a separate program. Saying no, a lot of what Lennart is saying is faith in his own project and sheer ambition. He wants it to catch on, just like anyone who believes they are right should, and everyone who contributes something should believe they’re sharing a right way to do things, if not what they believe to be the current best way. I even use systemd as my session manager, doing nothing more than starting programs that need to be autostarted and managing their state once they’re running. It manages to be more flexible and simpler than anything else I’ve encountered. Dependencies are much nicer than adding some sleeps to scripts.
> Fair enough, but it’s also wise to ask not just is it working, but what direction is it taking? You yourself pointed out that almost every file manager requires you to use their solutions exclusively. Is that in the spirit of Linux? While short-term changes may be (and are often engineered to be) apparently desirable, where are they putting their chess pieces and to what end? Personally, I view most of these changes as going against some of the fundamental design concepts of Linux. These people have neither the vision nor the skill to take it anywhere ‘good’, and I think it’s a mistake to indiscriminately swallow eveything they offer (which is what most distros seem to be doing – read Comment 11 by sporkbox just above your comment).
It is more that every file manager is based on gvfs, which is more of working with things that are already established than making your own. Gvfs depends on udisks. Udisks depends on PolicyKit to be able to mount drives as a user. It is more that there is a monolithic stack and no good alternatives that don’t require redoing everything – which first requires you to decide you can do it better or at least in a different also competent way. Going back to systemd, all the components are replaceable/removable and you still have a working system. People have decided that most of the backends are good and try to make new pretty frontends, which is sad. This is why I have a lot of respect for your projects – because you do more than just a new shiny UI. Systemd is a project like that. PulseAudio was a project like that. It has bugs (some were recently annoying for me for months until workarounds were found recently) but what makes it special is that it is made for dynamic environments, unlike everything else. You can get a great static config for ALSA, but if nothing else, the idea of PulseAudio is one that was really needed.
Wow, thanks for all the info and insights – much to ponder there, and I’ll keep it in mind. I haven’t so much as tried systemd yet. We do view things from a different perspective in some areas (for example PulseAudio gave me a rash from the moment I saw it), but in other ways I do relate to your values. I’m glad you’ve found systemd as functional as you have, but I also know that being bleeding-edge inclined as you are, and as knowledgeable as you are, your experience may differ from the less experienced user significantly. I have also heard from others who are not nearly so happy with systemd, and are running not walking from it due to the way to prevents convenient system maintenance and other issues.
The multi- vs single-user (or reasonably friendly multi-user) environment is a key issue. The problem I have with the CK and other designs is the way they over-complicate things for simpler systems, rather than being designed to scale down to a simpler model as needed. This is analogous to Ubuntu installing and running a whole set of daemons and software on my system that I don’t want or need, and making it nearly impossible to remove them – a bloated and laggy system (which is why I don’t use Ubuntu anymore). The designers have no or little respect for KISS. In practical terms, this translates into breakage. Many users have partially crippled systems, or systems that deny them access to their own devices, etc., because the combination of CK+PK is a bear to configure, and even then often doesn’t work as advertised. I’ve been seeing this pattern for years, but the devs seem to be unaware of it. They speak from theoretical perspectives and don’t seem to have a grasp on how their designs and apis are working for real – they ignore the developers using them. That and they just don’t care about the user experience – you’ll notice a lot of the comments to their posts include anger and frustration at their lack of responsiveness to practical concerns.
My other main concern is the movement toward dbus and other apis and away from command line, UNIX style interfaces. What’s great about the latter, and the reason it has lasted for SO long, is that it’s like a set of legos. You can pipe and redirect to easily connect tools in a script, parse output, etc. Even GUI apps can make use of this (see the new SpaceFM Dialog‘s interface). This allows users to customize and create their own subsystems with ease. Plus things don’t change and break every day, because thought is given to continuity. What these Red Hat and similar developers seem more interested in is designing a limited user environment that locks the user out of much of the power. You may not notice this because you’re not hesitant to dig deeper into the code, etc., but it changes things for others, including admins who want to write reasonably maintainable scripts.
I think when udisks2 arbitrarily and unnecessarily broke all of the command line to udisks, this was a very good example. There was simply no cause – they just didn’t care what they broke, or broke it deliberately. Then they explicitly said the command line tool should not be run from scripts! You can say what you want, but that kind of design philosophy is complete garbage and should have nothing to do with Linux. And this is the same family of developers who now want to take control of system startup! *shudder*
It’s important to keep in mind that just because something is open source, doesn’t mean it’s reasonable to make use of it. It’s possible to write code and docs that are so esoteric, bloated and convoluted that pretty much only the original designers can make any practical use of it. Thus they effectively close their work to others (probably deliberately, given the corporate connections). They further lock it down by using a (continuously changing/breaking) api rather than a simple, consistent interface. This is very different than UNIX interoperability. I’m not saying apis are never appropriate, but they can also be used to effectively deny practical access, even just in terms of the time it requires to deal with the complex api and changes. gvfs is a good example – it has turned many otherwise good file managers unstable (I hear about it regularly from users, and from developers who use it but absolutely hate it).
There seems to be a growing divide between those who design these systems/distros and the people who use them or the people who develop higher level independent apps, much like there is in Windows. Many immigrants from Windows don’t notice this because they are accustomed to it. I much prefer the blurred line between user/admin/developer which encourages diversity and flexibility. Just like in environmental evolutionary processes, a larger DNA pool is more adaptable and likely to survive, whereas a small one becomes retarded and dysfunctional, and eventually goes extinct.
> The DBus aspects, as I’ve said before, are more for dealing with PolicyKit than anything else.
That’s definitely not the impression I got from my reading – it sounded like they are using dbus heavily, even for starting all processes at boot.
On gtk3
> Having done almost all the work to get a gtk3 spacefm, a configure switch would be easy. I can toss up a few patches that are trivial changes that are completely gtk2 compatible and you should have no problem merging immediately (gtk deprecations, gseal) that are a nice hunk of the work.
Wow, that’s great to hear. I would appreciate the branch or any source you’ve worked on. Here are a few thoughts I have on gtk2/3 wrt spacefm:
1) I’m hearing from people who are upset that spacefm uses gtk 2.24 and they are requesting 2.20 or 2.18 so they can compile for older systems running Debian lenny or squeeze, etc. Being in the light-n-fast category, spacefm is used in varying and older environments, so I feel it’s important not to be exclusively bleeding-edge. So a configure option, if as practical as you say, would make lots of people happy – those who want to stick with 2 and those anxious for 3 (and I hear from both sides).
2) I want spacefm to be as rock stable as possible, so I was generally planning to let gtk3 mature a bit. Even the best code needs time to mature – I like gtk2 for this. It’s hard to build on shifting sands. I’m also not sure where they’re going from 3 – I originally heard talk that 3 would rapidly be replaced, and I don’t want to get into a pattern of spending all my time just trying to ‘keep up’. Many of my favorite rock-solid apps are still gtk2, eg geany, claws-mail, etc. I don’t know what their porting plans are, but I think gtk2 will be around for awhile in general.
3) If you’ve been into the source, I’m sure you realize that spacefm is a frankensteinian prototype in many ways, and some parts of the code are due for a rewrite. Even before I released it, it already had outgrown my original design. Further, the code is still prone to frequent changes as I play with it. This is intended as a (usuable) prototype so that, in addition to having a good fm, I also can get a good idea of what works, what doesn’t etc. I’ve already learned a lot from my own use and from feedback. I’m not sure at this point where I will take it, or how much time I will have to devote to it. I have some further UI ideas for it that could involve fundamental changes if I decide to tackle them, but even keeping up with bugs and simple requests takes most of my available time. So I just want to caution you about investing too much time in porting the existing code, as its prone to frequent changes in some areas, and even rewrites, unless you’re willing to go with the flow. Depending on how patient you are, it may frustrate you trying to maintain a gtk3 branch on what is a permanently experimental app. But at the same time, once I see your gtk2+gtk3 combo configure approach, I may start working more with gtk2+gtk3 compatibility in mind, so I’d definitely like to see what you’ve worked on at some point. As you say, continuing to write gtk2 code is wasteful, but at the same time I have my eye on these types of issues, so going gtk2+3 from here may be a very promising approach.
> My other main concern is the movement toward dbus and other apis and away from command line, UNIX style interfaces. What’s great about the latter, and the reason it has lasted for SO long, is that it’s like a set of legos.
I can see where you’re coming from there, but my main problem with dbus isn’t having to use it over using the command line, but rather a general lack of standards. The easiest example would be handling multimedia keys (play, pause, next, previous, etc), where gnome-settings-daemon handles that over dbus. It works well and allows applications to interface with it in a sane manner. The problem is that its a part of gnome-settings-daemon in the first place. The dbus api is fine and straightforward, but even the fact that the dbus api is desktop-environment specific or at least falls under gnome-settings-daemon in dbus shows that it isn’t desktop-agnostic and in a different environment, you’d have to do everything differently – or advertise yourself as gnome-settings-daemon when you aren’t.
On the other hand, the mpris2 dbus api is beautiful, for all the opposite reasons. The fact that just about every media player that people care about implements it lets something like the Ubuntu Sound Menu exist, and made it easy for me to program to that interface as well, doing the exact same thing for every media player. Dbus is more meant for communication between running programs, and though it can be used on the command line, I agree that the UNIX-style interfaces are much easier to use there. That said, I’d say that dbus is much less prone to parsing errors than an stdin -> stdout scenario, which makes it a cleaner approach and something that people would rather rely on.
The udisks2 situation is still something I’d regard as a mess. It was at least nice that they made sure you knew it was an api break by changing the major version. Most projects that I’ve seen keep an unbreaking dbus api if they have one and only add things to it rather than remove things – unless there is an incompatible rewrite. That makes keeping your software working with a wide variety of systems much harder than it should be.
>> The DBus aspects, as I’ve said before, are more for dealing with PolicyKit than anything else.
> That’s definitely not the impression I got from my reading – it sounded like they are using dbus heavily, even for starting all processes at boot.
Sorry about that, I forgot to mention the detail you’re thinking of, which is interesting but nothing I’d call alarming. Socket activation of services in systemd is a cool feature that applications can support, but doesn’t interfere with the non-socket activated use. It allows the communication with another program to start before that program is fully running, allowing for more parallelized startup. A socket is made first for program A before it starts and listens for events, and then program B can start at the same time even though it requires program A to be up and running and able to be communicated with. Then program A finishes loading, the socket is handed off to it, and now it can respond to program B. This just eliminates the need to delay starting program B at system startup. In this case, it is less that the init system (systemd) needs dbus, but rather that the services it starts need dbus, and this is a fun trick though not many system daemons implement it.
> Gtk3
I think the best method of attack would be to port spacefm to the newest gtk2, removing all deprecated symbols and direct access to members of structs. Then choose the lowest version of gtk2 you want to support and compile against that and add everything missing to a gtk2-compat.h that would be included in various files that need it. This would make the codebase cleaner and easier to maintain while still keeping support for old gtk versions. For example, use gtk_widget_get_window (widget) instead of widget->window, and in gtk2-compat.h implement gtk_widget_get_window as “return widget->window”. This particular case wouldn’t apply because gtk_widget_get_window has been in gtk since 2.14, but that’s the general idea. This is the kind of thing that Mozilla is doing for their gtk2/3 support in Firefox. At that point, that work could just be merged and make some people happy, and then the remaining gtk2 -> gtk3 api breaks would be far less and done by some ifdefs and a configure switch.
Most of the extra work you’d have after that would be compile tests before releases.
I’ve noticed the frankensteinian nature of the code, and that makes it kind of weird to contribute code because I’d try to stay within the coding standards of each file. That’s just a daunting task to choose a coding style and make everything consistent.
I apologize to you and everyone else who has to read these walls of text. This is why I usually don’t comment on blogs…
I really like the compat.h approach. No apologies necessary for the wall of text – this blog is (has become) largely for getting shit done, at all levels (support, dev, feedback, updates, news, etc.). Like you said about spacefm, it’s not just a shiny gui, but a tool. Thanks for your input!
To add more context to the situation, my blog has a rant on the subject: http://sporkbox.us/blog/?r=page/95
I hope you don’t mind this plug; the blog entry has links to the official mailing lists to illustrate the attitude among the systemd guys and may be helpful to know.
Not only do I not mind, I added your link to my original post above!
I’m also a former Arch user. I butted heads with them early last year over their lack of package signing and repo security (which they’ve since improved, and which you can search this blog for if you want the gory details). After speaking to the devs, I dropped Arch because of their horrible attitudes towards users and security. And like your one commenter there, I and others were banned from their forums repeatedly merely for discussing Arch’s huge security problems. I also spoke with the head of Arch (I forget his name), and I was definitely left with the impression that the fish stinks from the head down. Many of the Arch users are great, but they deserve a better distro overall. It’s too bad because some of the design of Arch has potential, or did. Sounds like it’s getting worse – can’t say it surprises me.
It’s amazing that they require systemd for dbus! Like you, I think this whole issue does have security implications as well, and could very well be an engineered attack or takeover of key aspects of Linux (at this point I find it hard to believe otherwise). Linux does have powerful enemies, it’s good to remember (and be wary), and its diversity has always saved it. As for systemd, sockets may be a good idea for startup if done well, but that can be done without dbus. While I can’t point to anything specific, the combination of dbus and socket use, along with the root processes involved with boot, makes me uncomfortable.
I ended up switching to Aptosid (formerly Sidux), which is basically Debian sid. They do a decent job as a rolling release distro. Siduction is a newer one that looks promising as well. I also tried Gentoo but had problems with some drivers. I may try again. FreeBSD also looks promising, and I tried it but again had driver issues. So I seem to be on the same road as you in some respects. I can’t say I’m thrilled with any distro at this point, but I agree Gentoo has a lot going for it. I haven’t changed much lately just because I’ve been busy with other things, and thus far debian sid hasn’t change to systemd, but that will probably happen.
As free software users, we don’t vote much with our dollars. But I agree we vote with our use of something – giving it attention. That which you use, you support. It’s important to choose wisely, especially at this particular fork in the road.
Even if systemd was great, just the way it’s being forced on people and is trying to become an exclusive solution is such a problem I believe it should be avoided. At this point I’m willing to buy new hardware so I can use Gentoo or another distro which lets me be free of this. This low-level takeover of Linux is disturbing.
Thanks for the input! I haven’t yet read all the discussion you linked to there so I may return with further comments.
Wow, that was a bit unexpected! Thanks for linking to it. If more people like us spread the word, we may be able to get a broader community to scrutinize what’s going on and wake others up to what’s happening. What really sucks about this situation is that systemd isn’t terrible. I don’t agree wtih its approach, but it does what it sets out to do. It’s the political and “do ALL the things” attitude of the project that I believe will ultimately shoot it in the foot. If it was “just another init system” that didn’t bind itself to udev and dbus (pretty much necessary for modern DEs) and respected user choice, none of this drama would be present. It’d be a few users saying “Damn, the default was switched to systemd. Oh well, I’ll just switch, get rid of it, and be on my way.”
But because things turned political and the project became too ambitious, any technical merit that the project has is overshadowed. I feel bad for the devs who’ve helped its development but don’t particularly carry the political zealotry of Red Hat employees (namely Lennart himself).
Forgive me for being the lonely guy here who actually likes systemd, but I think you’re being a little unfair. The way Arch Linux has done things allows user to choose. Doing it the way you’re suggesting (or at least how you’ve explained on your blog) would force them to use sysvinit and have to go through the kind of trouble you’re complaining about to get a working systemd system. On the other hand, your system boots normally with sysvinit and initscripts in the current configuration that Arch Linux has. I’d compare your scenario to complaining that mplayer and ffmpeg are compiled with libvdpau and you have Intel graphics so you will never use that. Its a couple megabytes (about 10 actually in the systemd scenario).
The incorporation of portions of systemd (the one that they include before was the tmpfiles implementation) is more of a testament to the modulararity rather than the monolithic nature of systemd. The tmpfiles program allowed for temporary files and directories to be cleaned in a sane, configurable, and extensible way and ensures that their state is exactly how it should be. The combining of packages that they’ve done (systemd-tools and libsystemd -> systemd) is something that is a little disappointing at first glance, but libsystemd being required by dbus-core (which is for communicating its startup with systemd or something, and initscripts has race conditions related to the startup of dbus http://www.mail-archive.com/arch-general@archlinux.org/msg30661.html) and udev basically being the entirety of systemd-tools, these things are needed for _any_ general desktop system. DBus linking against libsystemd does nothing to performance because it doesn’t do anything if systemd isn’t there – and systemd being an init system means that it will never been anything to wait for. Also, the total size of all the libsystemd libraries is 156K, half of which are attributed specifically to the journal. That won’t even faze startup of DBus, where libdbus.so is around 350K by itself and then having dependencies. I can sympathize with reducing dependencies – I run a LFS system and for example, my gnome-control-center has more than half of it patched out so I don’t rely on udisks, upower, or polkit at all.
I’m also allergic to all this political Lennart hate. There is no alternative to PulseAudio. Period. Everything else is just a bunch of less complete solutions for simpler systems and if you don’t want what PulseAudio offers then it is your perogative to use those other audio solutions. The other audio solutions work, and perhaps more reliably than PulseAudio, but they miss PulseAudio’s completeness as a dynamic desktop solution. Systemd is a proper dependency-based init that babysits running daemons so you don’t have to, sysvinit will never be that and it’s only claim to fame is its simplicity and it will have occasional race conditions of daemons because it wasn’t made to handle those – at best you can work around them. Upstart would be the real competitor to systemd, but to configure it past being a sysvinit implementation is a horrific endeavor. To be fair, most of the things that systemd aims to replace are dead projects. Adoption comes from switching from one broken implementation to one that is broken in (some subjectively and some objectively) fewer ways.
On a less controversial note… :P
I’ve started the gtk3 port here:
https://github.com/BwackNinja/spacefm/commits/gtk3
I’d call it about 1/3 done, but the third third is the hardest third. :P
Please tell me if you have any problem with the way I’m committing things. Thanks for your support on this endeavor!
I’ll let sporkbox speak to your Arch comments.
> these things are needed for _any_ general desktop system
That statement gives me concerns. You seem very quick to apologize for and spin much of the problems to systemd’s approach. I’ve received several requests to remove spacefm’s hard dependency on dbus, because some people don’t want it on their desktop systems, contrary to your comment. Also, if udev goes sour, I’m already seriously thinking of skipping it and going direct to the kernel and/or sysfs for what spacefm and udevil need for device management, thus removing any potential connection between spacefm and udev/systemd/etc. So that negates your statement about udev as well, as spacefm can run the whole desktop. You don’t seem to have much appreciation or respect for the diversity of and possibilities in Linux, and I think that’s where we primarily differ, technical issues aside. To me it seems you want your bleeding edge features without any concern for the consequences to Linux, so you defend the changes with strong bias. But no one’s telling you not to use systemd. I at least am mostly concerned with their forcing people to use it by connecting, as you said, a stack of increasingly monolithic solutions. Feels like a chess setup, and it smells like something Microsoft would do.
You’re right that systemd represents a solution to some init problems (for some). So it may be valuable for some. It should be forced on no one, and should get along – that’s the Linux way, but clearly not the Red Hat way. Also, the fact that it can be the solution to what Linux ‘needs’ also means it may act as bait. A commercially or otherwise motivated team offers us the perfect solution – we just have to give them control of every distro. Not so perfect. Maybe it’s more innocent than that, but they sure seem very motivated (by something) to have their stuff on everyone’s computer, and for their solutions to be THE solution, not just for their purposes, but for everyone – Pottering was very clear on that. Why? (rhetorical) (No hate for Pottering btw, but when you put your name on something, you answer for it, and I call it like I see it.)
You also don’t seem to have much appreciation for why people don’t want these components and libraries on their system, regardless of the their size or even if they’re loaded or not. Many Linux users don’t like being dictated to about what’s on and in their system. If we did, we’d use Microsoft products (or Ubuntu as well).
But you’re swimming against the current in this thread, and I appreciate the issues you’re raising – it helps to expand the discussion. I’m not necessarily agreeing with most of your assertions though – you seem a little too desperate to avoid seeing what is fairly obvious. But one can argue details forever and achieve nothing.
I’ve said elsewhere that honestly (and somewhat sadly) I think Linux is in decline, ctd (circling the drain), so none of these developments are a true shock to me. It will likely morph into something so unusable that serious users will abandon it for something else. That’s already happening as well, and I’ve been thinking of it with increasing frequency. There is a time to jump ship and move on. Not quite yet, but it’s good to start looking around imo. But I realize you’re more comfortable than I with where Linux is going (at least you think so, I’m not sure you’ll be as enthusiastic with some of the longer term results of these changes you’re defending).
Porting work looks like it’s off to a great start. I’ll drop you an email on it – thanks!
If I seem quick to spin the problems of systemd’s approach, it would be because everyone else is quick to ignore the deficiencies of other systems. To be clear, I don’t suggest that systemd or PulseAudio should be _the_ solution, but rather that it makes more sense as the default and everything else should remain an installable alternative.
The key word in “these things are needed for _any_ general desktop system” would be actually “general” instead of “any”. For your specific system and your specific needs other solutions work fine – or better. My reference there was more to udev (because no distro would honestly expect its users to set up static device nodes) and dbus (because most desktops rely on it so they don’t have to write their own IPC mechanisms). The general case is what these projects aim for. Even though I wasn’t referencing systemd with that comment, I’m not trying to say that anyone using sysvinit or even upstart is wrong; having a working system means that you have _a_ correct solution and there should never be something we call _the_ correct solution. Up until upstart, sysvinit was really the only game in town, and even after upstart came into existence it wasn’t really adopted and where it was adopted was still almost entirely sysvinit-style anyway so there was no great surge of complaints that things have changed. A problem with systemd or at least its reputation is the fault of Lennart himself. He’ll soften the blow with code (ALSA compatability in PulseAudio, sysvinit compatibility in systemd), but he doesn’t soften the blow in discussions. He vehemently believes that everything he’s replacing is terribly broken – which is good for having an ambitious project but not so much for making friends.
> Also, if udev goes sour, I’m already seriously thinking of skipping it and going direct to the kernel and/or sysfs for what spacefm and udevil need for device management, thus removing any potential connection between spacefm and udev/systemd/etc.
That’s something I can’t really stand behind, because then you’d be making your own monolithic stack. I can understand where that’s coming from with problems in different parts of the stack and that would enable spacefm to run fully in more configurations, but that doesn’t really sit right with me. It would be fine if you create a library for you and others to use that would replace the need for udev in udevil, but you wouldn’t want to go “my way or choose another complete system”. All that sound suspiciously like exactly what you’re fighting against. Reusable components are always needed so that we can lower the entry into various realms of application writing. Several file managers are pretty gvfs frontends, but yours is different. Gvfs can be a slow, bloated beast, but including it instantly makes a file manager useful. That said, I’d be using one of those others if I couldn’t mount drives from within spacefm.
I’m actually less trying to convince and more trying to understand. Talk about an init system and specific dependencies isn’t regular user talk. Anyone who so much as has an opinion about it knows enough and has experienced enough for that opinion to mean something and be relevant. Talk about systemd is just a specific expression of a larger problem of alienating trends in open source software development. There are the recurring discussions of “we have too many X, everyone should instead work together to make the best X”. Those tend to be from newbies who don’t see this choice as a good thing, but as something foolish, missing the fact that they’ve just made the move from another operating system because there wasn’t just one that everyone is working on. While I won’t be angry and bitter if sysvinit stops being a choice (because I won’t be using it), I’ll be disappointed because that’s still a choice individuals should have. For now at least, I can rest easy because systemd doesn’t work on *BSD, so sysvinit will still have individuals supporting it and making sure it works.
While I don’t agree that Linux is in decline (although things like Gnome3 losing features from Gnome2 makes me wonder sometimes), it is surely stagnating. One of the most ambitious projects of today is Wayland. When you think about it though, its success would be that everything still works the same (though on a more managable codebase with several technical merits and abandoning old cruft). Though it’ll be nice when that happens, it won’t be exciting. My favorite days would be back when Compiz was gaining notoriety, the Beryl fork was being obsoleted, and open source graphics drivers were getting to the point where they could handle it all. That’s when things looked interesting and I was excited to watch it all happen. Now it looks like I’m one of the few still running an updated Compiz that isn’t also running Unity. The Linux scene and Linux users have gotten more boring or perhaps its just me.
What perhaps makes me a bit harder to relate to is that I don’t run Linux because I think it’s useful. That’s nice, but I primarily run it because it’s fun. I’m curious and, unlike Windows or OS X, it lets me watch what’s going on in the changing landscape and form my opinions on what’s happening. My system was far more frankensteinian than anyone’s worst nightmares until I redid it to be rid of all the crap that accumulated and the hacks upon hacks that I put in place just to keep things working. Now it’s just sewn together better.
> That’s something I can’t really stand behind, because then you’d be making your own monolithic stack.
I’m not talking about replacing udev, just avoiding that layer of the stack. Talking to the kernel isn’t monolithic – spacefm is cp with a gui on top. If someone didn’t install udev, they would probably need some other solution available at that time to replace some of what it does. But spacefm doesn’t need much of what udev does. Also, spacefm can still be built with hal and no udev – I left the hal support intact, just not the default. The point is that there are many possible solutions.
Also remember that when I wrote udevil I didn’t build it into spacefm and make it all one chunk. udevil is a standalone program that is useful in itself and very flexible. spacefm works with any available mounting solution – even one you script yourself, not just udevil. These programs are all about giving you (easily implementable) choices. (Because a choice that is prohibitively expensive in reality isn’t much of a choice – a point that is very relevant here.)
> That’s when things looked interesting and I was excited to watch it all happen. Now it looks like I’m one of the few still running an updated Compiz that isn’t also running Unity. The Linux scene and Linux users have gotten more boring…
What you describe is exactly the issue. When Linux is a bunch of pieces that can be snapped together, users and distro makers can create a variety of functional combinations without reinventing the pieces. When those pieces start to stick together, with one person controlling a huge chunk, the system becomes inflexible and uncreative. Now you have centralized control, where a few people are making the decisions, and there are fewer practical choices at the user/distro-maker level. Thus everything starts to look and act the same – it becomes boring. No fun. :) And I agree – we should have fun with computers. Be creative. And a diverse and somewhat ‘messy’ environment is conducive to creativity – gives it that fun feel. The system has some ‘play’ in it.
Perhaps that’s why you like systemd – it’s new and fun in that regard. I on the other hand don’t like it not because it’s new (I like new choices), but because thus far the way its being integrated limits my flexibility and options (fun).
I started following it because it was new and _ambitious_. I’d honestly recommend you try it, even just from a livecd. From an outside perspective, being more than an init system is something concerning, while on the inside it is something powerful. Just being able to type “systemctl” and seeing all the running daemons it started, then “systemctl status NetworkManager.service” and see that it is running and tells me when it started. It also says that it started dhclient and what arguments it started it with as well as showing me the standard output of NetworkManager. That kind of thing is why it is more than a passing fascination and why I tend to be more forgiving about it. That’s why it is more than just an option for me to boot my system, but actually what I use to boot my system. All that is especially nice when you’re running a system where you can’t expect that others already tested the combination of packages you’re running.
For me it comes to this: Some of Pottering’s comments were horrific. It’s one thing to offer something, it’s another to dictate. Who is he to force this on people, which even he said he wants to do. That is so against the spirit of Linux that I don’t believe he should be involved with its core aspects at all.
If I don’t respect a developer’s values, their software won’t work for me. They’ll keep making decisions I don’t like and take it where I don’t want to go. Better to get off the train now, or not get on it.
I mean no offense or rudeness by this, but it needs to be made clear before I continue: My interest in fairness regarding systemd and Arch Linux went out the window as soon as my choice was being stepped on. I’ll return to Arch when its developers remember the value of user choice (and by extension, developer choice. They’re users, too). Unfortunately, I don’t see that happening any time soon.
Unlike your mplayer and ffmpeg example (which can be compiled out relatively painlessly with editing one or both PKGBUILDs), extracting systemd from an Arch box requires recompiling numerous packages due to the slow creep brought on by Arch Linux devs. systemd _can_ stand (mostly) alone, if packaging is done in a smart and/or user-respectful way. The PKGBUILD system does allow for some flexibility here (optdepends). Gentoo’s devs (and by extension, I suppose the LFS guys) have proven that udev and dbus can both exist separate from systemd. You may have a few unit files laying around in /etc/systemd/, but it’s nothing that’ll break if you `rm -r` it.
As an LFS guy, you understand the benefit of having less things on your system to worry about. It’s true that systemd doesn’t occupy much real-world space on a hard drive if it’s not being used as the primary init system. It’s not doing anything (that we know of) either. But it’s still another dependency and another package to manage in your chosen package manager. There’s a line I see myself repeating to people in many aspects of life, “Every big problem starts out as a small one.” systemd may be “only 150 KB” now, but it’s already absorbed one project, influenced another, and is looking to be adopted as widely as possible. This is not the behavior matching that of an init system. It’s behavior matching that of a company or a desktop environment. And hey, if Lennart wants to create his own desktop environment, he’s more than welcome to. As long as he doesn’t take the common subsystems out from under our feet and claim them as his.
I mentioned in my prior comment that systemd does its job and does it well. If you focus on nothing but numbers and performance, it’s great. There’s more to FOSS than numbers, though. Software projects (especially in the FOSS world) need to be respectful of the projects that came before them and work their way into the ecosystem in a way that doesn’t try to take over. This is where the politics came in and marred things. Lennart was not comfortable to release systemd and let it speak for itself. He had talk after talk on it, interrupted the talks of others ( http://www.youtube.com/watch?v=ZTdUmlGxVo0 ), and actively pushed for its adoption in other distributions. If software projects were children, systemd peddled pieces of candy in return for everyone’s toys. His attitude of his software “changing the Linux world” and everyone who dislikes it or has concerns with it being “stuck in 1970s UNIX” is over-confident at best and downright disrespectful and arrogant at worst. As we’ve seen before, the personality of the developers behind projects can make or break them. Linus Torvalds, Eric Raymond, Richard Stallman, and other veritable celebrities in the FOSS world each have distinct personalities that set the pace and stage for their projects or ideologies. As a result, they’ve each had to account for the way they conduct themselves. In this arena, all I have to say is Lennart’s racking up some interesting karma. His software may “make it to the top” one day, but considering all the toes he’s stepped on, it will bite him in the rear later on. But I digress…
So while systemd doesn’t leave behind “much” stuff when not in use, the fact remains that 150KB > 0 KB. If it’s not in use now and/or won’t be in the near future, it doesn’t belong on a system. In addition, why only focus on systemd and sysvinit? There are other init systems out there (pardon if the formatting doesn’t work):
* Ubuntu’s upstart (which I have no real experience with);
* runit (which shares some functionality with systemd but doesn’t attach itself to things like a worm), and;
* ignite, which is rather young and probably experimental.
That’s a total of 5 init choices if we include the aforementioned sysvinit and systemd. Why discourage user choice and insist that systemd is the only way, the best way, and one should switch right away? If we are to judge systemd on its technical merit alone, then the marketing doesn’t belong. Let the users decide what’s best for their system and switch to what they like. If it’s systemd, great. If it’s _not_ systemd, great. The problem that the majority of us have with systemd is its insistence to spread as far as possible and absorbing a few projects so it can achieve that goal more easily. udev and systemd should never have merged, and dbus should never have tied even parts of itself to systemd. IMHO, no software should care which init system started it. That should be left to the init system and the unit/service files that start the daemons. You cite systemd’s modularity, and it may very well have started out with it, but as it absorbed other projects, it became more and more stand-alone and monolithic. On distributions that ship with systemd, you cannot remove it from your system without crippling your OS. An init system should not try to bring the whole OS with it when you go to replace it. This is exactly how it’s become monolithic.
Please note that my questions are mostly rhetorical and I’m not targeting you per se, @BwackNinja. I look forward to your GTK3 port of spacefm. I don’t think I’ve used GTK3 yet, but I may try it for spacefm.
My apologies for the wall of text. tldr version: If you don’t use it, it doesn’t belong on your system. init should be separate and seamlessly interchangeable; other applications should not care which init system is being used. systemd would be considered “just another init” (which is a fair judgment) in my eyes if its author was not trying to spread it like a parasite.
Even I admitted the abrasiveness of Lennart in my comment above.
I think I can see where you’re coming from now. It is less that there is any particular problem with systemd, but rather that it has been given special privileges and treatment. The udev -> systemd git merge makes sense from a technical perspective, but what you’d want would be to be able to build them individually or at least have them packaged that way, with udev as the package udev (which I think is feasible because udev doesn’t at all depend on systemd nor link to any of its libraries). I can’t really argue against that. I just read the mailing list discussion about merging systemd-tools into the systemd package and their rationale for it being okay is largely what I said, with it not being forced on you to use it, but being forced on you to have it installed. The issue with dbus is a little trickier and goes more of the “systemd works ideally like that and it doesn’t harm other uses, so it’s okay”. Dynamically loading libsystemd would work here, but it is questionable whether there would be enough of a discernable difference to change it instead of just leaving it how it is, beyond letting you sleep a little better at night.
While I can now agree that things should be different, I will continue though to assert that this isn’t a matter of you being robbed of choices, but rather that you can’t have a system as clean as you’d like. That’s a fair complaint, but doesn’t have the weight of being forced into actually using systemd. In this case Lennart isn’t your villain, it’s the Arch Linux packagers. But it’s also a problem that few will know enough to notice. My eyes will at least be open to see if this shows itself as part of a bigger trend, but I’m not expecting as much as you are.
Sounds good. I would only add that it’s not just a matter of what’s happening in this one step, but where that step leads. You’re forgetting the comment about not supporting udev outside of a systemd environment. That’s key. Just because I can build udev without systemd, without proper support it lags and becomes a non-viable choice. So by tying them together and then saying “I’ll only support A for you if you use B” is control. sporkbox said solve a problem when its small – that’s exactly where we are with this.
You’re right. It’s not being forced right now, but the people behind Arch and other distros forcing a switch on their users combined with the respect that these distros carry can result in one area of the FOSS ecosystem losing user choice (without LFSing, Gentoo, etc). History also has a way of repeating itself… I’m aware I’m using the slippery slope argument, but it honestly seems that it could end up that way unless steps are taken to keep user choice (and system cleanliness) important to developers.
I hope that in time, after this systemd debacle has blown over, that udev and systemd will be separate again, and systemd can depend on dbus and udev instead of the other way around. Given the merge, however, I don’t really see that happening. As I’ve mentioned before, I have no axe to grind with systemd as an init system choice. I just don’t like choices being forced on me (which is what’s happening on Arch and likely Fedora/RHEL). Maybe other distros can see what’s going on and choose a better way to handle systemd. I think we can agree that systemd deserves a place alongside sysvinit, runit, etc, but shouldn’t be treated like the only game in town.
Thanks for being mature during this discussion, BwackNinja. I’ve not met anyone else who’s a systemd fan and non-contentious. :)
what a disaster.. this threath i think about gtk portability, but this its a comment setion about red-windowlike-hat “mano peluda” into udev issues..
disscutions about spacefm must was started in another instance.. but what ever.. i’m very tyred to filter gtk related comments