various options
various options
Posted Dec 31, 2013 17:49 UTC (Tue) by HelloWorld (guest, #56129)In reply to: various options by Cyberax
Parent article: Positions forming in the Debian init system discussion
Those interfaces, while certainly well-documented and stable, are not portable, there's literally dozens of linux-specific configuration options in systemd.exec(5) alone, therefore lots of those options couldn't possibly be shared between systemd and its hypothetical FreeBSD-based reimplementation. There seem to be some folks working on launchd for FreeBSD. It remains to be seen whether that works out this time(the last attempt in 2008 failed), but to me that seems a more feasible approach than writing an init system from scratch. Of course it's not clear whether Apple will be helpful in that regard.
Posted Dec 31, 2013 18:19 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (14 responses)
Posted Dec 31, 2013 18:55 UTC (Tue)
by raven667 (subscriber, #5198)
[Link] (4 responses)
Posted Jan 1, 2014 2:54 UTC (Wed)
by HenrikH (subscriber, #31152)
[Link]
Posted Jan 2, 2014 21:26 UTC (Thu)
by drag (guest, #31333)
[Link] (2 responses)
They have to be ignored unless you want to support SELinux on FreeBSD also.
If the functionality is missing on another platform and has no equivalent you cannot 'abstract' it away with a library or some other hack and expect it to make any sense.
Posted Jan 2, 2014 21:47 UTC (Thu)
by raven667 (subscriber, #5198)
[Link] (1 responses)
Posted Jan 2, 2014 22:49 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Anyway, right now SysV-based daemons rarely do anything complicated with read-only directories, so on non-Linux systems it'd simply be the continuation of status quo.
Posted Jan 1, 2014 9:34 UTC (Wed)
by Pawlerson (guest, #74136)
[Link] (8 responses)
Posted Jan 2, 2014 0:43 UTC (Thu)
by vivo (subscriber, #48315)
[Link] (3 responses)
Posted Jan 2, 2014 17:19 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (2 responses)
However when people said in the 1990s "We can't worry about Linux, it has less than 1% usage, so let's require ACLs because those work on the systems we do care about" (for example) did Linus respond by having a tantrum and asserting that Linux would never under any circumstances offer ACLs? I think not.
'cos the Linux system I've got here seems to have ACLs. Never really used them, but I suppose if I had a need for them I'd either be glad they're on Linux or I'd be using a different kernel.
Allowing a third party kernel to decide what Debian Linux chooses for init amounts to the tail wagging the dog, and the percentage is just making sure people understand we are talking about a very small tail on a very big dog.
Posted Jan 9, 2014 23:47 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
Doze *adds* user and group ACLs together. I gather you can get round that, but ...
Pr1mos gives you your user ACL *or* your group ACLs (or the default ACL if neither apply).
Thus making it extremely easy to control who has what access. "any old user" will get $DEFAULT. You can give group acls to departments or whatever, and people then get the access they need by default (Pr1mos adds group acls together so you get the sum of all your group rights).
BUT - if you explicitly set a user ACL, then that is *exactly* what they get! If their group acls give them a bunch of rights that their user acl doesn't, then the group acls are ignored (well, they're ignored anyway :-)
In order to take away rights on Windows, you need special contortions. In Pr1mos, you just set a user acl.
Cheers,
Posted Jan 13, 2014 14:24 UTC (Mon)
by nye (subscriber, #51576)
[Link]
Or you could set it to 'deny', rather than leaving it at the default of 'inherit'. If you're already setting a user ACL, this adds no extra work. No contortions required, and it allows a greater flexibility in how permissions are assigned.
Posted Jan 6, 2014 1:43 UTC (Mon)
by Arker (guest, #14205)
[Link] (3 responses)
Sad to see that today, in 2014, people are still proud to spew such nonsense.
Debian does not exist merely to make it easy for you to install and upgrade the software you want, today. Debian has a much broader mission, and keeping the infrastructure kernel-agnostic is an important part of their mission and their long-term strategy.
If you dont like their mission, and you dont like their strategy, fair enough, use another distro. But criticising Debian simply for being Debian as you do here, that's not fair, that's just dumb.
Posted Jan 6, 2014 8:49 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
The Debian Project's »mission« is outlined in its Social Contract. The last time I checked, being »kernel-agnostic« was not actually part of the Social Contract.
The Social Contract does say that »We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities.« More than 99% of Debian's users are on Linux. Who are you to decree that these users should not be able to take advantage of a technically superior and long-overdue infrastructure improvement that, incidentally, seems to be adopted by most other mainstream Linux distributions? Doing that doesn't seem to be in those users' interests.
Supporting Debian on other kernels is a nice thing to do but it is not explicitly part of the project's goals. As such it is upon those who want to support Debian on, say, a FreeBSD kernel to contribute most towards that actually happening. Individual Debian developers, for example, are not required to actively test their packages on Debian/kFreeBSD; they are simply requested to take on board any patches that Debian/kFreeBSD developers have come up with, just like we would like them to look at other patches that fix bugs.
By that reasoning, should the Debian project decide to make systemd the default init system on Linux, we would expect the maintainers of non-Linux Debian ports to contribute most heavily to a solution that would ensure that Debian continues working on those platforms. Whether that would be by forking systemd, writing a rudimentary clone, adding various missing bits of functionality to the other kernels, creating a way of automatically translating systemd units to whatever configuration their init system is using, or a mixture of these approaches remains to be seen. But in no case should these marginal platforms be allowed to hold back the vast majority of Debian's user base, in contravention of Debian's Social Contract, just to save themselves some work.
Posted Jan 6, 2014 9:00 UTC (Mon)
by smurf (subscriber, #17840)
[Link] (1 responses)
Not using systemd means missing out on some interesting features which (almost) every other Linux system out there has, and which people will take for granted in short order, and they will not choose Debian if it's not available.
I for one definitely plan for 2014 to be the year I forcibly eject Debian from my (non-trivial) infrastructure if they decide not to fully support systemd. Which system they switch to on non-Linux kernels, if any, is Somebody Else's Problem – none of these kernels supports a relevant fraction of my hardware.
Posted Jan 6, 2014 17:38 UTC (Mon)
by hummassa (subscriber, #307)
[Link]
Sure you can. Debian has, for the last twenty years or so, QED.
Debian can even keep its cake (keep the infrastructure kernel-agnostic) and eat it (use systemd). The cost of that is keeping a fork/patch either over systemd (so it does not need/use linux-specific syscalls) or kFreeBSD + the Hurd (AFAICT this last one is almost done, so that they implement the used linux-specific syscalls).
> [...] and they will not choose Debian if it's not available.
You are foretelling the doom of ubuntu (that does not use systemd) and I somehow doubt that (at least in the short to medium run).
> [...] none of these kernels supports a relevant fraction of my hardware.
Of course it runs NetBSD! :D
Posted Dec 31, 2013 18:30 UTC (Tue)
by raven667 (subscriber, #5198)
[Link] (6 responses)
Really, the task of re-implementing a systemd like system for BSD isn't impossible, systemd itself has only existed for a few years and any new effort has a reference implementation to speed along development that didn't exist before.
Posted Jan 2, 2014 9:55 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (5 responses)
Why don't we (I?) read this more often?
Look at what we have now: on the one hand poor old SystemV init which is portable but for a heavy price, on the other hand every operating system still alive has re-implemented its own OS-specific tool. That tells something doesn't it?
Maybe Debian/Linux should have systemd while Debian/kFreeBSD has launchd. There could also be - maybe - some higher compatibility layer on top of them to support the dumbest and least demanding daemons with a single config file. Doesn't systemd support some basic shell scripting already?
Posted Jan 2, 2014 12:09 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (1 responses)
The reason System V init is »portable« is that it practically doesn't do anything in the first place. It doesn't depend on the Linux kernel features that systemd depends on simply because System V init has no conceivable use for them.
System V init is portable in the way »hello world« is portable.
Posted Jan 2, 2014 13:42 UTC (Thu)
by marcH (subscriber, #57642)
[Link]
Posted Jan 2, 2014 15:06 UTC (Thu)
by smurf (subscriber, #17840)
[Link]
I have no idea which distribution I'll use if Debian decides to go with Upstart, but it won't be Debian. *shrug*
Posted Jan 2, 2014 21:31 UTC (Thu)
by drag (guest, #31333)
[Link] (1 responses)
Of course it does. It did from the beginning.
But if systemd is available people are going to use it because sysvinit scripts suck massively in comparison.
Nobody is going to want to support both a shitty way of doing things along side of a good way of doing things if they are given a choice.
Posted Jan 2, 2014 23:04 UTC (Thu)
by marcH (subscriber, #57642)
[Link]
various options
various options
various options
various options
various options
various options
various options
various options
various options
various options
Wol
various options
various options
various options
Debian has a much broader mission, and keeping the infrastructure kernel-agnostic is an important part of their mission and their long-term strategy.
various options
various options
various options
delusional portability
delusional portability
delusional portability
delusional portability
So the perfect solution (in my opinion) would be to continue shipping sysv init files (necessary for the transition period in any case) _and_ systemd .service files.
delusional portability
delusional portability