various options
various options
Posted Jan 1, 2014 9:34 UTC (Wed) by Pawlerson (guest, #74136)In reply to: various options by Cyberax
Parent article: Positions forming in the Debian init system discussion
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
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