Jes give me a choice!
|
| Author | Content |
|---|---|
| notbob Sep 04, 2014 12:19 PM EDT |
"maintains mount and automount points and implements an elaborate transactional dependency-based service control logic" I'll focus on the first part of the above sentence, as the 2nd part is jes nonsense. The first part of the above statement is something I can relate to. Why I gotta cede control of my mount points to a daemon!? I WANT my mount processes to be totally manual and somewhat arcane. I consider that to be good security. In fact, that's what bugs me about systemd. It's the automation of a very manual process. That manual control is what makes Linux easily secured. No one really knows how my box is configured. Heck, I barely know!! Seems to me systemd would allow interlopers to gain access and mount whatever they like, cuz systemd is "standardized" and "automated". Screw that! I don't even have mount points in my fstab file. Someone wants to mount a flash drive on my computer, they better know what the heck they're doing, cuz I've made it difficult for the avg newb to putter around. I feel I would lose that ability if systemd became the law of the land. If they make systemd an option, fine. Knock yerselves out. As long as I still have a choice. ;) |
| seatex Sep 04, 2014 12:45 PM EDT |
SystemD. Linux for Dummies. |
| telanoc Sep 04, 2014 12:58 PM EDT |
Indeed! And to the folks going around saying "How do you know you don't like it if you haven't run it" I say "I don't need to taste a poop sandwich to know I don't want one." |
| seatex Sep 04, 2014 1:11 PM EDT |
I agree that SystemD should be optional. It does break traditional Linux design and it does remove user/administrator control. But, perhaps most importantly... SystemD is a Binary Blob. And... The NSA loves Binary Blobs. |
| flufferbeer Sep 04, 2014 2:38 PM EDT |
+1 seatex! Soon another statement coming from Star Wars emperor "Lennart Poettering" Palatine? How about from his newfound ally on the Dark Side, eMBlxer? 2c |
| 750 Sep 04, 2014 3:09 PM EDT |
"If they make systemd an option, fine. Knock yerselves out. As long as I still have a choice. ;)" Bingo. *nix have from day one been about modularity and choice. I could probably today switch coreutils for busybox and the rest of my setup would not blink. This because while busybox is a singular binary, and coreutils is a pile of them, the busybox devs have made sure that the busybox behavior is as close to coreutils as they can get. Similarly, the one thing Linus Torvalds is adamant about is that changes to the kernel shall not break user space. Even when he declared Posix time broken, you can still find the appropriate interface in the kernel. But it lives side by side with another interface. This allows code written for Posix time to work (at least until the 32 bit rollover). |
| Bob_Robertson Sep 04, 2014 3:51 PM EDT |
Maintaining two trees of init scripts sucks. I completely understand why the distribution maintainers have chosen to pick one and carry on. |
| gus3 Sep 04, 2014 6:23 PM EDT |
"Init" is a recursive acronym for "Init's Not Integrated Tightly". Systemd: "Systemd, Your 'Sure Thing' Exists Most Degradedly". Okay, my work is done for today... |
| mrider Sep 04, 2014 8:00 PM EDT |
The thing is, if the objections to SystemD were purely technical, then I think I would object far less. Designs can be massaged, code can be rewritten, bugs can be squashed. It's inevitable that there are going to be problems with code as new as SystemD. It's also inevitable that there are going to be objections to any change regardless of whether they are trivial changes or not (which in this case they are not). My objections are not technical: 1) Why is it that every time anyone says anything negative about SystemD, the first words are "you just don't like change". I don't mind change. I came to Gnu and Linux from elsewhere. If I didn't like change, would I not have avoided it? I'll tell you straight up that I immediately discount the opinions of anyone that uses that line. 2) Nobody is going out of their way to make sure you can't have SystemD. If you want it - FINE - but don't ram it down my throat! 3) I am always leery of software designed by those that show the staggering degree of arrogance shown by the SystemD folks. One need look no further than the hijacking of the kernel debug switch, and then the various folks had the audacity to argue with Linus that they should own that debug switch. Yes that's been changed, but not without Linus having to pull a bunch more expletives out of the drawer. 4) I don't know how many times I've heard folks mention that the current start up system is "old". That's such an asinine statement that I have a hard time even knowing where to begin. But suffice to say that a battle-tested old code base is going to be more secure and stable than new code. This despite me being a programmer (which means that I produce "new" code). I'm experienced enough to know that my code isn't truly good until the proverbial infinite monkeys have tried to use it to produce the works of Shakespeare. Here's a hint - "bug" is a metaphor. We don't have actual moths coming and laying eggs on the code if it lays around too long without being touched. 5) Another refrain we hear all the time is that the current startup system is too complex. Yes, it can be complex. I've written startup scripts (used internally only), and it can be a bit of a PITA to get it all correct for one distro. Here's a clue for you - if your daemon is such that it will have a wide audience, then you most likely won't have much trouble getting volunteers to maintain the startup script for a given distro. If you can't get that, then most likely your daemon isn't such a big deal after all. If it's intended for internal use (like the stuff I maintain), then yes you have to do it yourself. But developing one startup script, for one distro, that's used on only a few systems isn't really all that difficult. 6) One of the selling points of SystemD is that when a daemon stops (due to a fault or etcetera), then SystemD can restart it. WTF - are we running Windows? I'm reasonably sure that the stuff I deploy is robust enough to survive anything the user can throw at it (at least that's what I strive for), but should the user figure out a way to crash my daemon, then the last darn thing I want is for it to come back automatically. That's where vulnerabilities start! 7) Many of the more recent changes to the boot process bear far too striking a resemblance to EEE as practiced by Microsoft. If (for example) there were problems with the network startup stack, then perhaps it was time for some maintenance coding? Instead the SystemD folks rewrote the stack from the ground up, and to add insult to injury, wrote it in such a fashion that it is (mostly) incompatible with the current stack. Okay, I lied, I do have two technical objections... 1) SystemD starts as PID1 and then continues as a daemon. SystemD is relatively new code, so it's reasonable to assume that there's going to be code churn for a while. There's not much chance of being able to update PID1 without a reboot. I still have a Windows 95 disk laying around somewhere. I could use that if that's what I wanted. 2) GNU/Linux is Not Unix (hence the acronym). Anyone that uses it and understands what they are doing knows that. Having said that, GNU/Linux resembles Unix in a great many ways, and it's not particularly difficult to write code from an (e.g.) Debian workstation, and have it compile and work in (e.g.) OpenBSD. The problem with SystemD is that it throws out compatibility in such a fashion that code written to be compatible will not work at all in true Unix without a substantial redesign. Obviously this isn't a concern for user-space programs, but it is a concern for most software that either starts as, runs as, or is owned by root. The integration of Gnome is a perfect example. I suppose that the Gnome folks don't mind that soon Gnome will not run on a non-GNU system without substantial code porting, but I can't see (e.g.) the OpenBSD folks doing that porting to work around something that they think is a bad idea in the first place. My fear is that "we" are trying to marginalize "them" by throwing them under the bus, and in reality we will wind up being ones marginalized. |
| mbaehrlxer Sep 04, 2014 10:15 PM EDT |
it's nice to see some more reasonable criticism that hasn't come up yet in other threads. here are some points i like:Quoting:if the objections to SystemD were purely technical, then I think I would object far less. Quoting:a battle-tested old code base is going to be more secure and stable than new code. Quoting:Another refrain we hear all the time is that the current startup system is too complex. Yes, it can be complex.i think you miss an interesting point here: i don't believe that systemd code is any less complex that he current system Quoting:The problem with SystemD is that it throws out compatibility i don't quite agree with this one though: Quoting:should the user figure out a way to crash my daemon, then the last darn thing I want is for it to come back automatically.you are not running any mission critical servers, are you? the users of my customers don't care why the site went down. they want it up! so when a daemon crashes, the first priority is to get it up and running, and only then we look at why it crashed. uptime, uptime, uptime! also, i am pretty sure that this automatic restart is configurable per daemon. if not, that would be bad indeed. Quoting:GNU/Linux is Not Unixas an aside: have you noticed that "LINUX" is an acronym too? Linux Is Not UniX Quoting:My fear is that "we" are trying to marginalize "them" by throwing them under the bus, and in reality we will wind up being ones marginalized. my hope is that openbsd is successful in implementing systemd apis so that we avoid monoculture. i am not afraid of linux being marginalized. things come and go. as it is however i highly doubt that systemd will make any dent in linux popularity. at the worst, a bunch of disgruntled linux users will switch to bsd. which would strengthen bsd and create more balance in our ecosystem. greetings, eMBee. |
| Bob_Robertson Sep 05, 2014 9:29 AM EDT |
I will whole heartedly agree with Opinion 4 above: Well thrashed code. (with the caveat that OpenSSL was well thrashed, too, or so we thought) I would feel much more comfortable if, for example, one cycle of Debian Stable had had sysvinit and systemd in parallel, or something like that. Yeah, I know, if that's what I want I'm welcome to do it myself. One thing is certain, the sooner rational application of the UNIX principles is brought to systemd, the better for everyone. The present systemd programmers need the same "Come to Stallman" moment to realize that the code is no longer theirs, it's everyone's. Where I work is going through a transition like that. The business is growing, and one by one the departments are outgrowing the ability for one person to be the go-to expert. The start-up culture is gone, it's time for well defined responsibilities and documentation so good that anyone who steps into a role can perform the needed tasks without having to have "since the beginning" historic technical knowledge of how everything has always been done. Growing pains. It hurts to give up control, yes. It is NECESSARY to do so. The UNIX philosophy enables that loss of central control, by allowing "small tasks done well" to work together seamlessly. That is the next step for systemd, and doing so will disarm most of the objections to it. |
| devnet Sep 05, 2014 9:44 AM EDT |
Quoting:In fact, that's what bugs me about systemd. It's the automation of a very manual process. That manual control is what makes Linux easily secured. So remove those units from your hierarchy. You don't have to use the automount function of systemd if you don't want to...so, there goes your entire argument. |
| jdixon Sep 05, 2014 10:31 AM EDT |
> So remove those units from your hierarchy. You don't have to use the automount function of systemd if you don't want to...so, there goes your entire argument. So, if I'm going to remove all the units I don't like: Why exactly am I using systemd again? |
| Bob_Robertson Sep 05, 2014 11:19 AM EDT |
> So, if I'm going to remove all the units I don't like: Why exactly am I using systemd again? {slow clap} |
| mrider Sep 05, 2014 11:55 AM EDT |
Quoting:you are not running any mission critical servers, are you? the users of my customers don't care why the site went down. they want it up! Right back at you sir/madam! Yes I run mission critical servers and services. Uptime is job 1. The services are distributed such that users don't even know when one or a few servers go offline. And I stand by what I said, the last thing I would want would be for that/those servers to restart daemons automatically. If something is wrong, we roll the corrections into our production environment in a controlled fashion. The users don't even know when changes are made unless they are in the user interface. [EDIT] Minor edits for clarity. [EDIT2] I am not saying that I'm afraid I can't stop the service from restarting automatically. What I am saying is that the auto-restart is being sold as a feature, and in my mind it's something to be thwarted at best. |
| mbaehrlxer Sep 06, 2014 4:18 AM EDT |
Quoting:Yes I run mission critical servers and services. Uptime is job 1. The services are distributed such that users don't even know when one or a few servers go offline.ah, good, point. there is more than one way to solve the uptime problem. i stand corrected. greetings, eMBee. |
| gus3 Sep 06, 2014 11:32 AM EDT |
Mission-critical, high-availability clustering systems do not auto-restart services. When a service dies, the node leaves the cluster, and it's up to the admin to figure out why the service died. It's true of Sun Cluster, and it's true of HP-UX ServiceGuard. |
| devnet Sep 08, 2014 9:15 AM EDT |
Quoting:So, if I'm going to remove all the units I don't like: Why exactly am I using systemd again? So when you remove an entry from fstab, did you pitch a fit too and talk about what a crappy thing it was to have or not have automounting with entries there? It's pretty much the same thing except it removes some of the things that SHOULD happen on bootup and places them there. I want samba mounting to occur on my system before I login because I use Linux in a corporate environment. If I don't want that to happen, I remove that unit and I manually mount them later. Problem solved. I don't get how people are upset that you can automate something on boot OR choose not to automate it and it's something that is a dealbreaker. I'd think people were more concerned about the lack of support for other CPU architectures or the horrible debugging support it has currently... even the size which is the largest of any bootup processes we're discussing. But the automount capability? Wow. |
| JaseP Sep 08, 2014 10:16 AM EDT |
Quoting: So when you remove an entry from fstab, did you pitch a fit too and talk about what a crappy thing it was to have or not have automounting with entries there? I don't know about him,... but I crabbed when fstab started using UUIDs and started making entries more complicated by a whole order of magnitude (and yes, I understand the technical reasons and motivations for doing so,... but even the order of fstab entries started becoming an issue). I also crabbed when Xorg did away with config files... What the devs saw as "standard" monitor screen sizes never really is standard,... I mean, when virtually every LCD TV under 42" has a native resolution of 1366x768 (and most inexpensive laptops do, too), why isn't that a standard screen size for their pre-defined modelines (in every connection type; hdmi, vga, dvi)?!?! And then getting Xorg to use a config file becomes a big pain... It comes down to developer hubris. They have an idea about how a thing should be done, and everyone else be d@mned. It's just like the KDE 4.0, Gnome 3.0 (or for those who still use Windows, the Win8.0/8.1) things. I have a great idea,... Before deciding to change things,... how about ASKING first?!?! How about developing with the users' wants & needs in mind?!?! |
| devnet Sep 08, 2014 10:37 AM EDT |
JaseP...I think you're absolutely right. It's more of crabby toward the changes...even if they will make things more productive and ease the pressure on individual distributions. As for asking...when you create a new piece of software, you don't have to poll people to make sure you're not stepping on toes...you just create it. If you want to get angry about not asking, put that one on the distros that adopted systemd...they're the ones that decided you shouldn't be asked by not sticking with Sysv |
| CFWhitman Sep 08, 2014 12:26 PM EDT |
devnet wrote:I'd think people were more concerned about the lack of support for other CPU architectures or the horrible debugging support it has currently... even the size which is the largest of any bootup processes we're discussing. Well, those first two in particular nailed some of my chief concerns about systemd. I'd add lack of support for any other Unix or Unix-like operating systems, and feature creep (more like feature gallop; the devs don't seem to have any idea where they plan to stop). I also have a big problem with the attitude of the developers that they couldn't possibly be wrong about anything or even that there's nothing subjective about the advantages of systemd, but that it's objectively better in every way than any of the alternatives (and incidentally, the alternatives seem to consist only of sysvinit and occasionally upstart in their minds). |
| devnet Sep 08, 2014 2:38 PM EDT |
CFWhitman, So you have something other than x86,x86_64 or ARM eh? Architecture aside...attitude of developers isn't something I base my choices on. I don't go out and look at a program that I install on my desktop and say "hrm...what is the attitude of the developers who made this program?". Honestly, I don't care and don't have time to care. They're making something and if the distro developers didn't see merit in it, they wouldn't use it. Obviously, a lot of them do. |
| gus3 Sep 08, 2014 2:49 PM EDT |
@devnet, you might care if/when you file a bug report. |
| jdixon Sep 08, 2014 3:39 PM EDT |
> Architecture aside...attitude of developers isn't something I base my choices on. Strange. I do, and always have. It was one of my primary reasons for moving to Linux years ago. |
| BernardSwiss Sep 08, 2014 7:36 PM EDT |
>> Architecture aside...attitude of developers isn't something I base my choices on. > Strange. I do, and always have. It was one of my primary reasons for moving to Linux years ago. Zing! |
| JaseP Sep 08, 2014 9:20 PM EDT |
Quoting:JaseP...I think you're absolutely right. It's more of crabby toward the changes...even if they will make things more productive and ease the pressure on individual distributions. I think you missed the point. The changes didn't make things more productive. They just broke things, and users needed to develop work-arounds to fix them. As for easing the pressure on individual distributions, it certainly does ease the pressure when a significant percentage of your users abandons you for the competition. That's another thing that happened ... |
| CFWhitman Sep 09, 2014 8:52 AM EDT |
devnet wrote:So you have something other than x86,x86_64 or ARM eh?Have used: PowerPC Probably will use at some point: MIPS Always a possibility: Power, Itanium, who knows what else? Regardless of what I may use in the future, one of the strengths of Linux has always been its ability to go right on to any new architecture that becomes available. I'd hate to see that change because some Red Hat developer decided that portability wasn't important, and, 'Who cares about anything that's not mainstream?' The 'Who cares about anything that's not mainstream?' attitude is rather ironic for a Linux developer, considering the origins of the kernel/operating system. Quoting:Architecture aside...attitude of developers isn't something I base my choices on. I don't go out and look at a program that I install on my desktop and say "hrm...what is the attitude of the developers who made this program?". Honestly, I don't care and don't have time to care.Well, it's certainly affected me many times in the past (like many others I have used Microsoft software). However, the dismissive nature of your comment readily illustrates the dismissive attitude of the developers. |
| mbaehrlxer Sep 09, 2014 10:33 PM EDT |
the portability problem of systemd is not about architectures. systemd will run on any architecture that linux runs on. the problem is rather that systemd is not portable to other kernels like *bsd, because it depends on linux specific kernel-apis. this is for example a problem for debian which also supports the freebsd kernel. and because of this debian will have to support sysvinit for the forseeable future. greetings, eMBee. |
| devnet Sep 09, 2014 11:08 PM EDT |
Everyone here needs to go and read about what systemd actually does, what it does for small distro developers such as myself, and mythbust a few things because it is obvious that you think you know and you don't just by the comments here. What I mean is...you're moaning about architectures that won't adopt systemd anyway because they're primarily for embedded distributions. You're ignoring any production gains, performance gains, etc. and just saying "oh, it removed the choice from me" when it CLEARLY doesn't...because it will support all of your init scripts should you choose to use them. You also state that users are abondoning it by the truckload when I know of 4 major distributions that have switched or are switching INCLUDING debian. I remember when people were all up in arms about pulseaudio as well....now people look back on it like it was a pure genius move. I think people will do the same with systemd. |
| jdixon Sep 10, 2014 6:17 AM EDT |
> You're ignoring any production gains, performance gains, etc.... No, I'm not. I'm saying they're not worth the cost to me. > ... because it will support all of your init scripts should you choose to use them. And, again, if I'm going to keep my current init scripts, why exactly am I running systemd? > I remember when people were all up in arms about pulseaudio as well....now people look back on it like it was a pure genius move. I think people will do the same with systemd. Strange, my system primary system still doesn't use pulse audio. My laptop does. I haven't noticed any significant difference in audio quality between them. |
| jazz Sep 10, 2014 9:41 AM EDT |
> I remember when people were all up in arms about pulseaudio as well....now people look back on it like it was a pure genius move. I think people will do the same with systemd. This is totally inaccurate. Only last month I run into a computer with pulseaudio running as a pure white noise generator. I've replaced it with ALSA and it worked fine. If you do a search on the web you'll find plenty of people complaining about pulseaudio problems. These problems are casually dismissed by the developer, unless you have a RedHat support contract. This is why quite a number of distros are quietly dropping pulseaudio - Lubuntu for example. Systemd is a new technology brought to you by the same people who built pulseaudio. At some point it will start getting dropped by some of the distros that implemented it. My plan is to wait 2 or 3 more years until RedHat customers report all the problems. We'll see how it goes. |
| Fettoosh Sep 10, 2014 10:00 AM EDT |
Some people just can't handle change and refuse to adapt to it. If history taught us something it is the fact that Change is inevitable. we complain, yell and scream all we want, but for some reason or another, for good or for worse, change is going to happen and people eventually will learn to live with it. Today's FOSS is no longer what RMS wanted it to be and it might not be what Torvald wanted it in the future. Many FOSS developers are moving on and new ones are coming in. Nothing is going to stay the same. |
| Bob_Robertson Sep 10, 2014 10:14 AM EDT |
> I remember when people were all up in arms about pulseaudio as well....now people look back on it like it was a pure genius move. I think people will do the same with systemd. PulseAudio has made my USB headset useless. It is no longer recognized when it's plugged in, so I have no way of using any telephony applications on my system. Please don't tell me how "happy" I should be about Pulse Audio, when stuff is broken that had been working for a DECADE prior to it. |
| jdixon Sep 10, 2014 10:15 AM EDT |
> Some people just can't handle change and refuse to adapt to it. Yeah, that's obviously why I had so much trouble switching from Windows to Linux on my home machine back in the 90's: I just can't handle change and refuse to adapt. |
| theBeez Sep 10, 2014 10:46 AM EDT |
@Fettoosh That's what I like about systemd proponents: they always come up with so many meaningful arguments like "you can't handle change" and "getting s**t" done. It so much enriches the whole discussion. Furthermore, simply ignoring idiotic slogans like "it's a bad architecture", "too many dependencies", "what does it solve" and "why are there so many CVE's and other bugs that are just closed - because it is not a problem" exactly the way you should handle these fossils. It really enhances the trust in the development team and the final product. |
| mrider Sep 10, 2014 11:20 AM EDT |
I'm sorry Fettoosh - what was my first objection again? Perhaps you'd care to re-read my post... R.E. Pulse Audio, I run Alsa on my home desktop computer. I never could get Pulse to work and I finally surrendered. Unquestionably, Pulse is intended to solve many problems in Alsa, and it probably does that for many people, but it doesn't work at all for me. |
| Fettoosh Sep 10, 2014 1:21 PM EDT |
Quoting:Pulse is intended to solve many problems in Alsa, and it probably does that for many people, but it doesn't work at all for me. emphasis is mine that is the problem that some have, they don't see the good that change brings to many others. I can understand that, but we should look at the over benefits and not only the problems it brings to specific individuals. If systemd is being adopted by major distributions and eventually by their branches & re-spins, there must be beneficial things in it that either not being recognized or being ignored. And if systemd doesn't bring the benefits or fails at accomplishing its objectives, software evolution will take care of replacing it. |
| jdixon Sep 10, 2014 1:53 PM EDT |
> ...they don't see the good that change brings to many others... If my standard in OS'es were "good ... to ... others" or "overall benefits", I'd be using Windows. |
| CFWhitman Sep 10, 2014 2:26 PM EDT |
You know, some might have gotten the impression that I am absolutely against systemd. This is not the case. The jury is still out for me. As long as portability to different architectures is feasible (and it really seems like it ought to be, at least once the growing pains are over) I might find that its advantages outweigh its disadvantages. However, though it may be fine, even good, for systemd to take advantage of Linux specific features as an init system, the bigger it gets, and the more beyond init it goes, the more concerned I become about portability of all its different parts to other Unix and Unix-like operating systems. The more other software that becomes dependent on it, the more portability becomes a concern. If the developers of systemd and other projects that deal with systemd can find a way to make sure that as few pieces of software are dependent on the whole system as possible (or practical), then that software can be more widely used among all Unix like systems. I just want the strength of Linux and Unix in general, interchangeable pieces, to continue to be respected. I would also like to see a less dismissive attitude by the developers. At least the "Myths" page tries more to address concerns rather than just dismissing them. It's funny, but I actually think PulseAudio may have more problems than systemd in some ways. However, I can always rip out PulseAudio and replace it with Jack (or something else) when I need something different than it provides. My major concern is that this remains true with systemd as well. I don't think the sky is falling. The reason I don't think that is because I think that if an impasse would be reached, we'd just see an alternate init, either new or existing, start to be implemented more widely. I'd rather it didn't reach an impasse, though. I'd rather not see any more of things like a certain desktop can't be run on a certain system because it doesn't have systemd. That seems too far for dependencies on an init system to reach. There are enough concerns of that sort about Wayland, which is more directly connected to the user interface, and thus can't help but have a more direct effect on the user. |
| Fettoosh Sep 10, 2014 2:33 PM EDT |
You are generalizing way too much beyond the scope of this subject. |
| 750 Sep 10, 2014 3:21 PM EDT |
@devnet, systemd has by now gone far beyond init. Here is the thing tho. With any other init alternative, the things running on top don't care what init is being used (sysv, openrc, upstart, a long shell script running things in sequence, etc etc etc). But with Systemd it suddenly becomes A Very Big Deal. |
| mrider Sep 10, 2014 3:52 PM EDT |
Quoting:Here is the thing tho. With any other init alternative, the things running on top don't care what init is being used (sysv, openrc, upstart, a long shell script running things in sequence, etc etc etc). But with Systemd it suddenly becomes A Very Big Deal. Which leads back to the title of this thread and notbob's original point - not to mention one of the points I made - simply, just give a choice. And no "you can disable much of SystemD, but you are stuck with it like it or lump it" is not a choice. And that's precisely where we are heading considering that user space programs are starting to depend on SystemD. |
| BernardSwiss Sep 10, 2014 3:53 PM EDT |
Quoting:@devnet, systemd has by now gone far beyond init. Aye, there's the rub... It's apparently become such a chore to avoid using systemd, that many distros have switched, not because they prefer it (indeed, sometimes to the contrary) but simply because the extra effort that avoiding it entails is becoming/has become rather onerous, so that the devs can't afford to leave it aside. |
| gus3 Sep 10, 2014 6:02 PM EDT |
There is a GSoC project to port systemd to OpenBSD, even though systemd devs have no intention to support it. Just sayin'. |
| mbaehrlxer Sep 10, 2014 8:35 PM EDT |
it's not a port of systemd but a reimplementation of the APIs. skip the discussion that links to the code repository, there is nothing useful in there except for the last few comments, for example http://www.phoronix.com/forums/showthread.php?105988-OpenBSD... which points to ubuntus systemd-shim: http://blogs.gnome.org/ovitters/2014/09/07/systemd-in-gnome-... another interesting comment below shows partial success in porting the bsd rewrites back to linux. that whole post at http://blogs.gnome.org/ovitters/2014/09/07/systemd-in-gnome-... is actually quite interesting. although the author is a bit dismissive about the systemd-shim effort, he does point out a lot of what's wrong with the discussion around systemd. greetings, eMBee. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!