The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
Posted Nov 20, 2014 21:17 UTC (Thu) by njs (subscriber, #40338)In reply to: The Grumpy Editor's guide to surviving the systemd debate by dlang
Parent article: The Grumpy Editor's guide to surviving the systemd debate
Posted Nov 20, 2014 22:19 UTC (Thu)
by dlang (guest, #313)
[Link] (49 responses)
Posted Nov 20, 2014 23:27 UTC (Thu)
by kmacleod (guest, #88058)
[Link] (45 responses)
Can you be more specific what's preventing the apps from supporting run-time or compile-time access to other APIs?
Posted Nov 21, 2014 1:46 UTC (Fri)
by raven667 (subscriber, #5198)
[Link] (44 responses)
Posted Nov 21, 2014 2:37 UTC (Fri)
by dlang (guest, #313)
[Link] (43 responses)
In practice, systemd is the new hotness and everyone who doesn't love systemd is being branded as a hater or a senile oldster.
We've seen the hate that's trotted out when a proposal is made to require people to not depend on systemd, and how some people are casting the Debian GR vote as a ringing endorsement of systemd and how it's perfectly find to be systemd only.
I have seen people here on LWN talk about using the systemd specific logging calls and not having fallback to the traditional logging capabilities.
This is the same type of thing that made people sound very opposed to Wayland a year or two ago, when it was the new hotness and 'everyone' was talking about how writing for Wayland was so much easier, people should just do that and not support that obsolete interface called X11.
It is possible for sanity to prevail here (for the most part, actually moving from the early proof of concept to a usable system has dampened the hype around Wayland significantly, it's no longer being viewed as a "must move to it within the next few months" thing)
But creating new APIs for basic plumbing functionality like name lookups and logging is not a good thing to be doing for portability.
Systemd explicitly doesn't care about portability, but users will. They may not initially as they move to systemd, but they will eventually if the software they use isn't critical enough to force everyone to switch to systemd. After all, don't the systemd advocates keep insisting that nobody is forcing anyone to use systemd?
Posted Nov 21, 2014 3:31 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
So an update is definitely in order. Systemd does this a bit too revolutionary, but in the end most of the proposed APIs are not very Linux-specific. They are just not implemented yet elsewhere.
But that is being fixed already. And what's more, it's definitely possible and not even _hard_ to implement API-compatible fallbacks for other systems for most of systemd functionality.
Posted Nov 21, 2014 3:45 UTC (Fri)
by dlang (guest, #313)
[Link] (6 responses)
What is the exact failure with the existing APIs that cannot be solved without involving DBUS?
Posted Nov 21, 2014 3:49 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
Posted Nov 21, 2014 8:33 UTC (Fri)
by rleigh (guest, #14622)
[Link] (4 responses)
Posted Nov 21, 2014 9:09 UTC (Fri)
by peter-b (subscriber, #66996)
[Link] (2 responses)
Trivially? Oh excellent! Since it's so straightforward, why don't you quickly knock something out over the weekend, so we can then put this whole discussion to rest? I"m sure Lennart would be really happy for other developers to get involved in tackling this problem.
Posted Nov 21, 2014 11:14 UTC (Fri)
by rleigh (guest, #14622)
[Link] (1 responses)
Posted Nov 21, 2014 11:17 UTC (Fri)
by mchapman (subscriber, #66589)
[Link]
Um. D-Bus *is* a standard library interface in practically every mainstream programming language.
Posted Nov 25, 2014 22:16 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Nov 22, 2014 2:50 UTC (Sat)
by thedevil (guest, #32913)
[Link] (34 responses)
I should _really_ leave this topic alone but I cannot, sigh.
You're veering into the philosophical. What is "force"?
And many of those saying nobody forces me to use systemd seem to
Maybe we should agree that the word "force", like "socialism",
Posted Nov 22, 2014 5:18 UTC (Sat)
by nybble41 (subscriber, #55106)
[Link] (33 responses)
It seems pretty obvious to me with respect to any reasonable philosophy, not just among libertarians. The person was in a bad situation to start with, but the one making the offer isn't the cause. The offer can be accepted or rejected at will; if it's rejected, the person is no worse off than they would have been had the offer never been made. Accepting the offer implies that the person expects it to improve their situation. Giving someone additional options which they can choose to ignore doesn't seem at all like "force".
How would you define "force" such that making an offer like this is "force" but simply passing by and doing nothing is not "force"? Or would you consider that "force" as well? The concept that non-action could be "force" seems absurd to me, but I'm sure there's someone who thinks that way...
In any case, you hit the nail on the head: you are free to continue using the software as it exists today, and to improve on it as you see fit, by yourself or in collaboration with others who share your vision. You are not, however, entitled to improvements (including security fixes) to be developed by others to your preferred specifications. If you want to take advantage of others' work then you must be prepared to give up a measure of control—including control over details like a dependency on systemd.
Posted Nov 22, 2014 17:37 UTC (Sat)
by thedevil (guest, #32913)
[Link] (26 responses)
"you are free to continue using the software as it exists today"
This just shifts the question from "force" to "free choice". The
You are right, though, that my example was a bad one as I posed
"If you want to take advantage of others' work then you must be
I am not a totally passive recipient, I am an occassional Debian
systemd is no detail. Adoption of systemd in its full scope would make
Posted Nov 22, 2014 20:10 UTC (Sat)
by nybble41 (subscriber, #55106)
[Link] (25 responses)
Yes. As they take advantage of your work. That wasn't meant to be pejorative; we all gain an advantage from the work of others. But it does imply letting others make some of the choices.
> The crux of my position is: if one option is bad enough, it is not free choice. You could say that users of proprietary software are also "free" to just stop using it, yet that is not usually how we apply the term.
I'm not saying that anyone has to stop using Debian. Unlike proprietary software, the pre-systemd versions will remain available for them to use or improve on as they see fit. _Upgrading_ to a hypothetical new version of Debian with a hard systemd dependency would be a free choice.
> systemd is no detail. Adoption of systemd in its full scope would make a completely different OS...
Perhaps it would, but then you have two options: the software as it exists right now, pre-systemd, or the improved version with systemd. That's one of the nice things about free software, the older versions remain available for use and further development if anyone should happen to disagree with the direction taken by the project's current developers. (Just look at what happened with Gnome 3 and MATE, for example.)
There are any number of Debian derivatives available. If 30% of Debian contributors really want a Debian-style OS without systemd—or even just the 24% who listed Option 1 as their first choice—they would clearly have the resources necessary to create such a derivative without impeding the 70+% who want to use systemd. Or they could just submit patches to ensure that the packages they're interested in continue to work with other init systems in Debian proper, without imposing such support as a requirement on other maintainers.
Personally, I don't see why anyone would bother. Systemd seems strictly superior to the existing sysvinit as well as the other proposals. I'm already using it on my Debian systems and am glad for the change.
Posted Nov 22, 2014 20:39 UTC (Sat)
by thedevil (guest, #32913)
[Link] (23 responses)
Sorry, no. Running today's software, bit by bit, in 2 years (even
"they could just submit patches to ensure that the packages they're
This is what I pin my hopes on, but the tone adopted by many DDs in the
Posted Nov 22, 2014 21:02 UTC (Sat)
by vonbrand (subscriber, #4458)
[Link] (22 responses)
Please try on said DD's shoes for size. Firstly, their principal responsibility is to say "no" to ill-conceived patches, and even just to patches that don't fit into the programming standards of the package(s). They have to triage bug reports into "requires immediate attention", "can wait" and "just not worth it". Remember they have limited resources (probably best described as "resource starved"). That means they can't responsibly take on continuing maintenance of all crazy ideas proposed. Much less when upstream won't take them over, leaving them in the bind of caring for changes forever. Pretty much the same way the systemd developers state their position; They want to build the very best possible process managing infrastructure for Linux. Diverting resources to cater for other kernels (or even not-so-new Linux versions), or compromising the use of Linux-only features for the sake of portability, just isn't in their books. Your might not like either position, but you should at least try to understand where they come from. Both Debian and systemd owe their success to following through with their visions.
Posted Nov 23, 2014 1:42 UTC (Sun)
by thedevil (guest, #32913)
[Link] (21 responses)
I actually agree with you about the vision, but the problem for me is
Bowing out of this debate for good; since the effort to switch to
Posted Nov 23, 2014 1:53 UTC (Sun)
by Zack (guest, #37335)
[Link] (19 responses)
Posted Nov 24, 2014 12:27 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (18 responses)
People who hope that FreeBSD will let them stay in the 1990s forever should be really scared of this.
(Of course, once FreeBSD has systemd there will be little point in Debian/kFreeBSD staying with sysvinit.)
Posted Nov 24, 2014 14:14 UTC (Mon)
by johannbg (guest, #65743)
[Link] (17 responses)
Now let's see if that crowd will complain as much to the BSD crowd, demanding of them to make it available and work on linux too...
Posted Nov 29, 2014 9:01 UTC (Sat)
by blujay (guest, #39961)
[Link] (16 responses)
On top of that, you misrepresent the portability argument: no one is demanding that Poettering, et al make systemd work on BSDs. The problem is that he explicitly refuses to even accept patches from others to that end.
Then there's the double-speak and the "wakeup call" to Gentoo, which gives the lie to the "no one is forcing anyone" line.
And that's the biggest problem with systemd. And when people focus exclusively on the technical issues, they miss the bigger issues, the people problems. And those are harder to fix and far more damaging, because there's no "community reset --hard" command.
Posted Nov 30, 2014 15:23 UTC (Sun)
by foom (subscriber, #14868)
[Link] (15 responses)
No. That would only be a problem if:
Please note the OpenSSH/Portable OpenSSH split seems to work out just fine.
Anyone in the world can get together and work on a branch to make the bits and pieces they'd like to use portable.
Whether or not systemd upstream git tree supports other OSes is almost completely irrelevant -- unless you're asking the systemd upstream to do the portability work.
Posted Nov 30, 2014 20:34 UTC (Sun)
by dlang (guest, #313)
[Link] (14 responses)
Posted Nov 30, 2014 20:45 UTC (Sun)
by vonbrand (subscriber, #4458)
[Link] (3 responses)
Remember the days when much stuff for Linux was developed in/through non-vanilla kernel trees, and Alan Cox' tree was the one most bleeding edge hackers followed? Could set up a git tree and merge said patches in there, that is just a few keystrokes away. Merging in upstream changes is ridiculously easy with git, no need to handle random text patches flying by on mailing lists. Not doing so is a dead giveaway to me that they aren't serious.
Posted Nov 30, 2014 21:02 UTC (Sun)
by dlang (guest, #313)
[Link] (2 responses)
For many people, systemd just isn't that compelling.
It's like the attention paid to fast boot times and suspend/resume, if you are dealing with systemd that stay up and running for months at a time, shaving a few seconds off of the boot time doesn't matter. If you are putting all your attention to servers providing 24/7 service, suspend/resume doesn't matter.
That's not to say that those features aren't interesting to other people, but the people who are interested in them (and correspondingly the people who are interested in features that systemd provides) need to accept the fact that it's not interesting to everyone.
And when there is a regression or performance hit to something that you are interested in because of some feature that you aren't interested in, that's annoying and people crowing about the feature you don't care about don't solve your problem.
Posted Nov 30, 2014 23:21 UTC (Sun)
by vonbrand (subscriber, #4458)
[Link]
I for one have never claimed systemd's advantage being fast boot, it is that it gives sane process management. That is even much more relevant on servers that should run continuously for months, having to reboot because some idiotic script got irretrievably wedged (yes, has happened to me) isn't acceptable.
Posted Dec 1, 2014 0:46 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
Many people don't seem to find systemd compelling but they're still outraged that portability isn't an important goal of the project so it won't run everywhere right off the bat. This is a bit incongruous to say the least.
From what we hear, systemd does have lots of features that are interesting to many people – from embedded-system developers to server admins. Fast boot times are nice to have and systemd seems to work well in that area, but systemd is not just about fast boot times; they are a fringe benefit of the approach systemd takes for service activation. (Incidentally, even on servers, people who deal with on-demand virtual machines seem to appreciate a faster boot process, so it is incorrect to claim that boot times are irrelevant to servers.)
Of course anybody may feel free not to be interested in systemd's features, which is why systemd is not mandatory to run Linux, and is unlikely to ever be that way as long as those not interested in systemd are willing to put in the work to maintain a systemd-free Linux distribution (if nobody else does). Whether other people – such as upstream developers who would like to avail themselves of systemd's features – will bend over backwards to make it easy for them is of course up to those people. Then you get people like the Debian developers, who on the whole seem to be happy with the concept of supporting several init systems (in particular, sysvinit and systemd) at the same time as long as this is dealt with in the usual way (i.e., by means of wishlist bugs, preferably with patches attached) rather than mandated by GR. This means that if you do notice a regression or performance hit to something you are interested in, the first step towards getting that fixed is to submit a bug report. Crowing about it on an unrelated web site doesn't solve your problem, either.
Posted Nov 30, 2014 22:33 UTC (Sun)
by anselm (subscriber, #2796)
[Link] (9 responses)
The BSD OpenSSH people don't accept portability patches, either – the portable version is maintained by a different team in a separate repository. Nobody seems to mind much. There is no particular reason why a similar approach wouldn't work with systemd if somebody actually came up with patches for a portable version.
Posted Dec 2, 2014 2:58 UTC (Tue)
by blujay (guest, #39961)
[Link] (8 responses)
And you know this. "If you actually made the patches, it would be fine." This is equivalent to, "Do as I say, not as I do." "Portability patches will not be accepted....Why aren't you porting it?" You say one thing, but expect others to do the opposite, and then criticize them when they take you at your word. It's as if you expect people to think you're lying--in which case, why would they trust you?
You make no sense, but I think you know that. The question is then, why?
Posted Dec 2, 2014 5:04 UTC (Tue)
by pizza (subscriber, #46)
[Link] (4 responses)
Yeah, because one is a network-facing daemon that must conform to well-established protocol specifications in order to be of any use, and the other is operating system plumbing that tries to take advantage of the features of its targeted kernel (modern Linux). They have quite different scopes, so it's no wonder they're developed differently.
But since you brought it up, let's actually talk about some of the ways systemd and OpenSSH/OpenBSD are similarly developed:
* Principal developers have a strong vision and often abrasive personality
> You make no sense, but I think you know that. The question is then, why?
Your argument is based on factually incorrect premises, false equivalences, and downright faulty logic; this makes no sense, but I think you know that as well. The question is then, why?
Posted Dec 3, 2014 0:26 UTC (Wed)
by blujay (guest, #39961)
[Link] (3 responses)
All of which makes it more ridiculous to expect other people to maintain portability patches against the will of the developers.
> Principal developers have a strong vision and often abrasive personality
But that is supposed to be irrelevant, isn't it? After all, no one accepts that as a valid argument against systemd. And while de Raadt knows OpenSSH is vital to software around the world, Poettering explicitly disregards portability. The difference is night and day.
> All related code is developed in a single repository and built together
This favors in-tree development of portability, not out-of-tree.
> Modular, yet tightly coupled design via well-defined internal interfaces
Just like the kernel, which also maintains its many platforms in-tree.
> Extremely strong emphasis placed on "predictability and correctness"
Predictability? Like Poettering's "wake-up call" to Gentoo?
> to the point of not compromising either for the sake of expedience (or even portability)
Again, this favors in-tree portability, not out-of-tree.
> Expectation for third parties to develop and maintain portability to other systems
False! This is a lie! No one is expected to port systemd to other platforms, because it's not expected at all! You know this! That's the whole point!
> Little regard for backwards compatibilty (although systemd fares *far* better than OpenSSH here; seriously, try to compile a modern OpenSSH release on an old OpenBSD system sometime)
See previous comments about OpenSSH's knowing that their software is vital on platforms around the world. Their method of porting is just that: a method of doing it. Systemd, on the other hand, refuses to even consider it. You know this.
> Your argument is based on factually incorrect premises, false equivalences, and downright faulty logic; this makes no sense, but I think you know that as well. The question is then, why?
Nope, nice try though.
Your argument boils down to, "It's technically possible, so shut up and port it." You conveniently ignore the gross impracticalities, knowing that no such effort would be feasible with the way systemd is developed. We're talking past each other because you're moving the goalposts. And I've yet to see anyone actually respond to Poettering's "wake-up call" to Gentoo--too inconvenient for the narrative, I suppose, so better to ignore it and redirect the argument.
I think there's no point in continuing this discussion with you. Changing the subject, ignoring facts, moving the goalposts, focusing on strawmen...but what of the truth?
Posted Dec 3, 2014 2:24 UTC (Wed)
by pizza (subscriber, #46)
[Link] (1 responses)
You're one to talk, given that you've done every one of those things in your reply, including taking contradictory positions depending on the particular point you're trying to argue.
What of the truth, indeed.
Posted Dec 3, 2014 6:36 UTC (Wed)
by blujay (guest, #39961)
[Link]
Then, "No one is forcing you to use systemd.... This is your wake-up call, Gentoo! Good luck reimplementing our rapidly changing internal APIs!"
Yeah, I'm the one being self-contradictory...
Posted Dec 3, 2014 10:13 UTC (Wed)
by anselm (subscriber, #2796)
[Link]
It would be more appropriate to say that (a) the systemd developers don't see the point of portability patches to systemd because systemd relies heavily on kernel features that are currently only available on Linux in the first place, and (b) the systemd developers don't want their own code base cluttered up with portability #ifdefs. None of this prevents other people from actually trying to port systemd if they have nothing better to do with their time.
To port systemd to another Unix-like operating system kernel, somebody would have to remove all the Linux-specific bits from systemd and/or enhance the other kernel to provide compatible versions of those Linux-specific bits that one would consider worth supporting (considering that some of systemd's Linux-specific bits are really quite essential for its functionality). This would very likely involve a major effort, and – since most other Unix systems by now have their own take on an improved init – it is unclear whether such an effort would really be worthwhile. Having said that, it is fair to assume that if one is prepared to go to the trouble at all then having to maintain a separate OpenSSH-style “portable systemd” repository is probably the least of one's worries.
In this context it is worth mentioning that leading FreeBSD developers have recently gone on record to say that something like systemd would not be a bad idea at all for FreeBSD as far as they're concerned. Whether this means that FreeBSD will move towards evolving enough Linux compatibility to support a (partial?) systemd port, or whether the FreeBSD people will come up with something similar but unrelated by themselves is as yet unclear – but the fact that there is active interest does validate the principle of systemd's approach to basic plumbing (if not portability).
Posted Dec 2, 2014 8:34 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (2 responses)
Systemd is changing quickly because it is a new project (compared to OpenSSH, anyway). It will eventually settle down and evolve at a much slower rate, at which point a “portable” version may become more interesting to consider.
It is also worth pointing out that the systemd developers have not said that they will not ever consider any “portability patches” whatsoever, just that the idea doesn't make a lot of sense because systemd relies extensively on Linux-only kernel features and that as long as such patches don't exist the point is moot, anyway. Again, from the systemd developers' POV it makes good technical sense to focus on Linux first, and to deliver a clean and correct code base that runs on Linux. Once systemd does what it is supposed to do on Linux, there may come a time to think about what parts of systemd's functionality can usefully be adapted for other systems, and what extensions to those systems (e.g., additional kernel features or Linux compatibility layers) would be required for systemd support. This might eventually lead to a “portable” systemd maintained in a separate repository à la OpenSSH, and while the systemd developers may not be interested in “portability patches” per se, if there are reasonable “cleanup patches” that facilitate this without unduly complicating systemd's Linux-oriented code base then I think those might well be accepted.
Posted Dec 2, 2014 17:41 UTC (Tue)
by dlang (guest, #313)
[Link] (1 responses)
Part of what people aren't liking is the dependence on linux-only features without any fallback to operate without them.
If cgroups are required to be in the kernel, but you can operate without using any controllers (as was stated in some thread on lwn in the last few days), then refusing to boot when cgroups aren't in the kernel is the wrong thing to do. That would be one linux-only feature that would change from a hard dependency to a feature to be used when available.
Posted Dec 2, 2014 20:51 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
However, you don't need any cgroups-based resource management to be turned on (or even compiled in). In this case cgroups will be used only for process tracking and nothing else.
Posted Nov 24, 2014 10:31 UTC (Mon)
by jezuch (subscriber, #52988)
[Link]
I don't see how. For me it was just an apt-get away. [Besides, I don't think current packaging of systemd in Debian uses much more than the core init component.]
Posted Nov 22, 2014 20:41 UTC (Sat)
by vonbrand (subscriber, #4458)
[Link]
Please don't. You just come barging in and foul up a perfectly nice flamewar with a reasoned comment taking away their favorite arguments for fanning the flames. Sheesh...
Posted Nov 23, 2014 20:07 UTC (Sun)
by cas (guest, #52554)
[Link] (5 responses)
The fact that US Libertarians can't see this goes a long way to highlighting what's wrong with them.
Posted Nov 23, 2014 22:43 UTC (Sun)
by nybble41 (subscriber, #55106)
[Link]
I never said that it wasn't exploitation. I said that it wasn't _force_. The most obvious difference being that if someone uses force against you then a response in kind is justified (self-defense), whereas if someone merely "exploits" you, there is no justification for responding with force.
You're mixing personal/subjective morals with objective ethics. The libertarian position doesn't address the former at all; it's only concern is when the use of force is justified (in short: only when responding to the use of force by others). Your opposition to the libertarian position appears to be based on the misconception that it has something to do with "right" and "wrong", rather than the justified or unjustified use of force.
Personally, if I were in the situation you described, I believe that the right choice would be for me to offer the children whatever assistance I could provide with no strings attached. The solution to exploitation is to offer a better choice, not to remove the few they have. However, if someone else were to impose conditions, even "exploitative" ones, I would consider it wrong for me to employ force to _make_ them help without conditions, or to prevent them from making their offer, or to punish them for the "exploitation". If I did employ force in that way then, as a libertarian, I would consider a proportional defensive response against me to be justified.
Posted Nov 23, 2014 22:45 UTC (Sun)
by viro (subscriber, #7872)
[Link]
Posted Nov 29, 2014 9:22 UTC (Sat)
by blujay (guest, #39961)
[Link] (2 responses)
Well, no, that won't do, because then the poor man is still homeless and hungry and out of work.
So what should he do? Offer him a job at a certain wage (set by the government, of course)?
Well, now you're forcing him to do something against his will.
But that's okay, because it's for the greater good. The ends justify the means.
That's all well and good until you are the one being forced to do something against your will. But that's okay, because it's for the greater good. What, you're not a hater, are you? How could you object to helping people? Don't you have any compassion?
We recognize that forced love is not love at all. The same principle applies here.
The real greater good, for all of us, is best served by individual liberty, personal responsibility, and giving, not reluctantly or under compulsion, but cheerfully, from the heart.
Posted Nov 30, 2014 20:16 UTC (Sun)
by cas (guest, #52554)
[Link] (1 responses)
what's that you say? you want him to respect and the government to protect and enforce YOUR property rights? WTF should he respect your property rights when you don't respect his human right not to be exploited? why is your property more important, more worthy of government intervention than his life?
libertarian arseholes believe that property is more important than people.
the fact that you've put property up on a pedestal above everything else doesn't actually mean that it's worthy of the worship you want to force everyone else to give it.
ps: private charity is a copout. whether someone gets to eat or have shelter shouldn't be dependant on their cuteness or their ability to evoke pity. neither should it be dependant on the whims of the rich. welfare is a responsibility of society - i.e. paid for by taxes.
Posted Nov 30, 2014 20:54 UTC (Sun)
by corbet (editor, #1)
[Link]
Posted Nov 21, 2014 1:18 UTC (Fri)
by njs (subscriber, #40338)
[Link] (2 responses)
OTOH I don't see how you can claim logging as an example; systemd 100% supports the standard syslog API. They also provide some additional APIs that let you provide extra structured metadata that syslog just can't handle (so it's not really "replacing [an] existing API", it's new features entirely), but even here it would be trivial for users to include a stub implementation of this API that falls back on throwing away the metadata and calling syslog() if the journal isn't available. Heck, it'd be like a 10-line patch to teach sd_journal_sendv to just do this by default. (Also there's zero dbus involved, just good old fashioned AF_UNIX sockets like Allman intended.)
Posted Nov 21, 2014 2:40 UTC (Fri)
by dlang (guest, #313)
[Link] (1 responses)
I don't know any details about the resolvd DBUS api other than that it exists. What it replaces is the gethostbyname() and similar functions of the existing libc options.
Posted Nov 21, 2014 2:48 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link]
Well no. It doesn't replace anything. It is an additional option.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
I think it's a good thing. The old API has become ossified and is not really suited for the modern needs.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
enough to force everyone to switch to systemd. After all, don't
the systemd advocates keep insisting that nobody is forcing
anyone to use systemd?"
Libertarians of the US flavor insist that they're against
any "initial use of force". But, they don't seem to have a
problem with, say, finding someone desperately hungry and
offering to hire him for half of what the work is worth. That is
not "force" to them.
mean basically than I can move to Windows / Mac, or keep using my
computer with exactly the same software os today, and forgo
security fixes etc. Not right now - but in 2-3 years, when
current stable goes out of support.
has too many meanings and it is better to always spell out what
you actually mean by it.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
doesn't seem at all like force."
crux of my position is: if one option is bad enough, it is not
free choice. You could say that users of proprietary software are also
"free" to just stop using it, yet that is not usually how we apply the term.
it.
prepared to give up a measure of control—including control over
details like a dependency on systemd."
contributor. And, apparently roughly 30% of DDs agree with me.
Are they also "taking advantage of others' work"?
a completely different OS on the level I usually interact with it
(ie. command line, editing configuration files, reading logs, setting up
cronjobs).
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
software, the pre-systemd versions will remain available for them to use
or improve on as they see fit. _Upgrading_ to a hypothetical new version
of Debian with a hard systemd dependency would be a free choice."
assuming my hardware lasts that long) would be a worse option than not
using computing at all. And you know that.
interested in continue to work with other init systems in Debian proper"
last few years when presented with patches and bugreports detracts from
those hopes. If I was conspiracy theory minded (I am not) I would describe
the tone as remarkably similar to that of systemd maintainer ;-)
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
phenomenon to me. I have been using, and trying to improve, Debian for
a long time as I wrote in my other posts here. Refusals used to be
gracious and understanding, now they're often silent or even snide.
that in the Debian case the vision seems to have changed. Very slightly
but perceptibly if you look close. Nothing I can do about that as an
individual (and not because of my lacking technical merit), and that's
really the most frustrating thing about the situation.
systemd with all its family is comparable to switching to a new distro,
I may as well start exploring the latter :-(
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
[…] and is endorsed by systemd's lead developer as positively remaining systemd free.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
a) Such patches to make systemd work on other OSes actually existed.
b) It turned out, from actual experience, that maintaining them in a separate "portable" git tree had frequent problematic merge conflicts or something like that, that made it very desirable for the tree be merged back with the Linux-only tree for developer sanity.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
* All related code is developed in a single repository and built together
* Modular, yet tightly coupled design via well-defined internal interfaces
* Extremely strong emphasis placed on "predictability and correctness" to the point of not compromising either for the sake of expedience (or even portability)
* Expectation for third parties to develop and maintain portability to other systems
* Little regard for backwards compatibilty (although systemd fares *far* better than OpenSSH here; seriously, try to compile a modern OpenSSH release on an old OpenBSD system sometime)
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
No one is expected to port systemd to other platforms, because it's not expected at all!
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
Uhm, you still NEED cgroups to use systemd. It can't really work without them.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
OK, I think it's fair to say we've gone pretty far off topic at this point; maybe it's time to close this discussion down or find a more suitable forum for it?
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate