On Mon, 11 Jul 2011 17:10, Andreas Jaeger <aj@...> wrote:
On Monday, July 11, 2011 16:56:39 Rob OpenSuSE wrote:
On 11 July 2011 15:09, Andreas Jaeger <aj@suse.com> wrote:
We're not talking about the sysadmin in the proposal (at least not directly)!
The proposal is for distributors how they will configure the system - to define which services are run by default and which not.
The sysadmin will configure the system starting from the preconfiguration with systemctl. No need for the admin to learn about all this magic ;)
Fine but why complicate things, does someone really want to write a file parser? If you just have Disable as default policy, and then have flag set by distro to make "enable" a global default, that's it done.
I assume that openSUSE will have "disable" as default. Debian might have "Enable" as default.
It DOES matter to the sysadmin, because if it's :
service-default-install-policy enabled disabled
Once at a large installation, will going to want to change the policy most likely; for example if the admin have 2 distro's they'll want the SAME defaults! So the simpler you make it the better alround.
From the original post: If an admin wants to manually change "enable-by-default" to "disable-by-default" (or vice versa) he could just drop his own file with "disable *" (or "enable *") into /etc/systemd/system.preset/ and override the vendor/spin settings.
So, this is possible - as easy as what you describe.
The difference is treating all options the same and allow pattern matching - vs. having an explicit file for defaults. It also means that all settings will be in one directory.
What can be more efficient than 0 byte files for a flag in 2 directories?
A runninug system does indeed have systctl etc, but I thought the was Distro policy, package polocy with some over-ride. It may seem different, to the running system, but it'd be likely quite easy to write scripts to do the systemctl to match the site policy, when one desired, if you define it nicely.
I don't understand what you're saying in the above paragraph, could you rephrase it, please?
Filesystem state has advantages, because there's good tools to replicate it.
The original proposal does it as well - doesn't it?
Not that easily. - A file with content has a syntax, charset, parsing. - A 'file' (zero-length) in a directory is just that. No syntax, parsing, charset (fixed to utf8 of the fs). Also do not underestimate trouble shooting of crashed systems. How does a Fedora user held his Debian friend without having a running reference system, or extened knowlege? In the case of zero-length-file-in-directory with added (en|dis)abled/DEFAULT - file the learning curve is nearly flat. Maybe the acceptance for systemd will get a rise with a "Oh, it's simple!" system of en- and disableing services, even without deeper knowledge of the 'new' init-system. For me at least a simple, easy to check config is a convincing argument for the change to systemd as 'my' init-system. Just as a two digit number plus a underscore before the name and you get even a simple and easy method of start order. Well, that's ust me, but I'm sure, for the user that seldom (only in cases of trouble) look under the hood/bonnet of his system a distro-independend, uniform, with just a glance understandable system of configuration is gold, and a argument for a system / distro. Ask yourself: would your grandmother/mother understood this system? Is it intuitive? How does it handle a filesystem-crash? Yes, AJ, you are under the hood daily. But most users not. This isn't meant personally, but it is a case of perspective. User versus Admin. A flat learning curve is a benefit for both, yes, but is esential for the user and thus the distro acceptance. A tip beyond: Would a simple README file in the level of the enable and disable directory to much to ask for, at least during the change-over from System-V to systemd. As content just a few lines about systemctl and it's most basic usage. To spare our self some support questions and give adopters a little extra help on the way. Cheers, Yamaban. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org