Alan McKinnon <alan.mckin...@gmail.com> wrote: >On 19/08/2013 14:13, pk wrote: >>> sysvinit, like X11, needs a massive overhaul and a sprint clean. >> Yes, an overhaul is always welcome. But most people criticising these >> systems (and other systems) just say that they are bad without >pointing >> out what is bad. How can you fix something without knowing what's >bad? >> To me the problem with sysvinit (and X11) seems mostly to be a >> philosophical one. Some people say: "this doesn't work the way I want >it >> to - therefore it's crap!". While others (like me) say: "I have no >> problem with this - it works fine!". > > >I find sysvinit to be unwieldy and clunky. Perhaps not so much the code >itself, but surely the interface it presents to me the sysadmin. All >that rc.[0-6] nonsense - what's that all about? In all my days I have >never seen a computer running *nix that wasn't fully satisfied with two >exclusive running states: > >- normal operation (whether console, headless, X) >- maintenance mode (busybox on console). > >So why do I have 6 of them? The runlevels themselves are fixed and >rigid. I want them somewhat more flexible, I actually don't want a >bluetooth daemon *running*all*the*time* - really, it should only start >when I enable bluetooth. This may not be the best analogy but you get >the point, the OS needs to react to changes in the environment and >sometimes those reactions are best dealt with by the service manager. > >OpenRC to my mind made huge strides in dragging this into modern times >by making runlevels declarative. It all make so much sense in Gentoo. >As >for the bulk of the code, I don't have issue with that. PID=1 does what >it needs to do. > >I suppose I can sum up the changed environment in one word: hotplug > >X11, well that's another story and probably way off topic. It was >designed for hardware and architectures that haven't existed for 20+ >years. Almost all factors that made X11 awesome in the 80s and 90s >simply are not there anymore.
X11 was still really awesome in 2002. When we used remote graphical logons to different machines. It also helped with performance of certain desktop applications. Running the application on a different machine (with better CPU) then the machine I was working at always made people wonder why the same application was performing so badly on theirs ;) But these days. Having fast reliable performance locally is better. With a decent RDP that can connect to an existing desktop without having to set it up as shared from the beginning is more useful. Any ideas on that? -- Joost -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
