On 11/11/2011 10:52 AM, jdd wrote:
Le 11/11/2011 16:39, James Knott a écrit :
The idea is to start the computer without a desktop. Previously, editing inittab did that. It no longer does. What's the new method to start a computer without a desktop?
right now I see only adding 3 to the kernel grub line, but I fiond this odd
I thought this was covered already? Don't you change a symlink to a service file? One service file does the same as init 5, another service fie does the same as init 3. I think the names are different for opensuse but it's like this: http://fedoraproject.org/wiki/Systemd#How_do_I_change_the_default_runlevel.3... That's not a great process but it's early days. Ultimately I guess the ideal would be for one or more scripts to be written to optionally parse inittab and sysv init scripts if they exists to make systemd read sysv init files as an optional compatibility bridging part of it's processing. And eventually develop a new template for writing init scripts so that a single script can function as either a sysv init script or a systemd service sscript. Probably involving smallish changes to the script itself and the bulk of the compatibility magic in some function libraries that get sourced at the top. systemd appears perfectly configurable and customizable, at least or more than sysv init, so things like after.local and pretty much any desired action look pretty straight forward to replicate, merely the names and places of scripts and the methods to specify dependencies & order of operations are different, but no harder. The difficulties I see are all in breaking so much existing system integration and assumptions by existing software. The differences are not that baffling or hard to adapt to, taken individually, but the fact that it has been sysv init forever, since before even linux existed, let alone the entire run of linux, let alone the entire run of suse linux, so much software is out there that just assumes sysv init. In my case I have to deal with drivers and proprietary daemons for multiport serial cards (digi, equinox) and T1 fax modem cards (eicon) and network serial port server boxes and terminal servers (equinox, digi, cyclades) and hardware raid cards (adaptec, lsi, 3ware), proprietary terminal emulator daemons (FacetWin), commercial application software that includes daemons (Rand McNally MileMaker, PC-Miler, VSI-FAX, Prophesy) ... all these things include either one-time startup actions or one or more daemons each, or both, so their installers do need to know how to install startup and shutdown scripts, are closed source, poorly supported on linux despite being anywhere from fairly to very expensive, include poorly written frankly broken installers and start scripts that I usually have to hand edit but at least they are sysv init scripts, and absolutely necessary, and many no longer going to be updated, will never see systemd support. Unless systemd can seamlessly support sysv init files, it will simply break ALL of those. requiring me, and every other user using products like these, to hand craft their own replacements for the vendor supplied init scripts, and manually fix the supplied installers, where possible, or figure out various ways to fake out the installers so that they think they installed onto a system that's laid out the way they expect, then go rearrange the stuff that got installed after the fact to work on systemd. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org