On 15/10/14 03:33, Miles Fidelman wrote: > Scott Ferguson wrote: >> On 15/10/14 01:54, Miles Fidelman wrote: >>> Scott Ferguson wrote: >>>> On 14/10/14 23:54, Miles Fidelman wrote: >>>>> Andrei POPESCU wrote: >>>>>> On Lu, 13 oct 14, 18:30:41, Miles Fidelman wrote: >>>>>>> Gee.... assuming that you don't run anything that has >>>>>>> systemd dependencies and/or systemd-shim is actually >>>>>>> maintained and kept up-to-date. >>>>>> Have you actually looked into what depends on systemd? >>>>>> ---------------8<------------------->8--------------------------------- >>>> the majority of development. Embracing diversity and >>>> conservatism (aversion to change) can be "a bit of a stretch". >>> How do you come to that conclusion. >> Which conclusion? > > That this is the selection criteria for LFS. (Mind you, building > from scratch is looking better and better - though Gentoo makes it a > lot easier.) > > But, addressing (some of) your other points:
They weren't points (it's not a football match) :) I simply didn't know which "conclusion" you meant (I made several) - so to save time I covered them all. >> >> That Debian is a progressive "Universal" OS? It changes as a result >> of developers seeing a need to improve - I'd call that progressive >> (rather than static or regressive). >> >> > > Stability is an awfully nice virtue, one that Debian used to > subscribe to. Stable is still as stable now as it was 20 years ago - no crashes. Do you have different experiences? > >> >> That your own OS might suit your needs (and some others) better? >> (did you take that as an offence??) > > That Debian is NO LONGER a suitable operating system for my needs, > after more than a decade - yeah, that I kind of take offense to - or > at least I take offense to the inordinate amount of time that I > expect to waste on migration - be it to systemd, another distro, or > another o/s entirely. OK - as long as you didn't take what I wrote as an offence. > >> Based on the large number of posts you've made complaining that >> Debian's plans don't match your needs. ---------------8<------------------->8---------------------------------e). > > Some of us actually have to plan for things like transitions - and > the lack of clarity regarding development plans makes that rather > difficult. In that sense your experience is little different than mine. I expect hardware and user needs to change - and we anticipate it. For the last decade change control has changed little - 6 months testing and documentation, 2 years support. Except that the last stable has (tenuous) LTS - which just makes our work easier. Jessie is something we won't begin seriously testing until it actually becomes stable. The major difference is that I work with server, embedded devices and desktop - if not for the last two categories I probably would work on a derivative. Instead I rely on pre-seed and post-seed. My aim, probably similar to yours, is not to get locked into hardware or software (packages or distro). Legacy support can be a nice niche but it has it's limits (is it worth it to the client?). > > Ok... so multiple init systems are going to be supported in Jessie, > and maybe beyond - ok. What seems to be very much up in the air is > whether that choice will be (well) supported at upgrade or install > time. That makes a rather big difference. I'll wait and see - planning is only possible when the task is not nailing smoke to the wall. I allow a two year gap between testing wholesale changes and deployment with SLA - which is more than sufficient (I have a much easier life than those that support Windoof!) I don't want to learn multiple inits - I'm lazy (pick one). ---------------8<------------------->8--------------------------------- >> >> >>> (I guess, if libreoffice is no. 2 in the popcon stats, desktop >>> use now dominates. Sigh...) > > And understanding what the relative priorities are has major impacts. > With rather large regret, it sure seems like the priority on > server-side support has gone way down in favor of desktop support (as > far as I can infer). That the support list is more noise than signal I agree - that server support is degraded I don't know (and I won't use this list to plug my business - there's another list for that). That server deployments have increased - I have no doubt - enormously (even Gartner are forced to admit that). But the world is not just servers [he says as he pauses typing on his portable Debian running from a USB key on the nearest computer to glance at his Debian -rooted phone while running a profile backup to a Debian file server on a box that is having Windoof replaced as a desktop with Debian. The only thing left to install Debian on is that BTrusted (hi Dougal!) BSD on the firewalls] ;) ---------------8<------------------->8---------------------------------> >> So far I've had no problems not using udev when it's not required >> (static hardware). >> >>> A completely unexpected behavior, hard to track down, poorly >>> documented. >> :) I'd say the same about most packages. As for unexpected - I >> usually read the release notes before I begin testing - no >> complaints so far. I don't understand what you mean by "hard to >> track down". udev gives me much more information about devices than >> hal and it's predecessors. > > well yeah - but one kind of expects core capabilities to simply keep > operating predictably across upgrades -- you know, regression > testing and all that I've only had major upgrade problems with userland apps on webserver. Given the huge number of packages that need to "just work together" I can't think of another OS/Distro that even comes close to that degree of upgrade stability (and I've plenty of experience with Oracle/Solaris/RedHat). >> >>> Given that the players are the same, and the scope is much >>> larger, this gives me lots of reservations about systemd. >> I'm *very* wary of any "gut-instincts" - but I do encourage those >> that swear by them to publicly journal them for future reference. > > well... where systemd is concerned, I point to Linux Torvald's > comments re. PulseAudio; Not really a response to my comment.... :( I have no problem with Linu*s* Torvald's complaints about kernel code contributors. I still don't join the dots to make a conspiracy. PulseAudio is fine for desktops - anyone who installs it on a server needs there head examined by a certified phrenologist. (apologies to any phrenologists I've maligned). > where udev is concerned, I simply make a note to myself > >> >>>> [*1] I suspect enough to support a tightly-focussed server OS >>>> (if you can herd cats?) - maybe a Debian derivative? Strip out >>>> all the DE packages and it might be do-able... >>>> >>>> >>> That used to be Debian. >> Not in the 20+ years I've been deploying it. It was always 'better' >> at server than desktop - now it's not so bad as a 'desktop'. But >> different perspectives and different requirements - I *like* to >> modify systems. Debian enable me to tailor it to suit a given >> purpose - it I wanted someone else to tailor it for me I'd pay them >> (and treat them nice). > > hmmm.... I think we agree on this one --- the thing is, I've already > invested a lot of time and effort in tailoring our current > installation Likewise - and the one before. Rinse and repeat until spud - though between dokuwiki, OTRS, and well-documented scripts that's no longer a real problem (compared to - well, anything. e.g SOE and SLAs for other Distros, Windoof etc). > -- systemd is going to blow that all ways, or at least require: - > time and effort to build a system that doesn't install systemd by > default Be grateful? Otherwise you may be replace with a bread cube and a chicken. Glue bread cube to Enter key, glue chicken to desktop, install :D > (unless the installer folks include init-select as part of > installation), or, - time and effort to test anything and everything > that touches systemd - particularly customized initializations and > such (I'd sure like to see some regression testing on systemd's > support for legacy sysvinit) and - an expectation that somewhere, I'm > going to get bit by some big problem induced by systemd, that's going > to take a long time to figure out (and having looked at the > documentation, that scares me I don't know what you support so I can't comment. I used to support OS/2 (only dropped support last year - the client still has several dozen service stations that only run OS/2 - for everything). I no longer support IBM PS/2s (sob). Your experience will differ (I won't stoop to "all things must end" - but they do). > > Beyond that: - the whole thing with systemd, it's monolithic nature, > and it's intrusiveness is that we lose a lot of that ability to > tailor things (or at least it makes that much harder) - as well as > being a major shift in design and architectural philosophy, away from > modularity toward monolithicness (if that's a word) - lots and lots > of central, unaudited code Sufficient comment has been made on the bulk of that paragraph. As for unaudited.... I'd be breaching the Coc to use the appropriate adjective for how *little* GNU/Linux *has* been audited. > >> >> CentOS would fit the server focussed distro definition better >> (well, limited architectures, on recent hardware...). Some people >> swear by it i.e. "I've never used anything else - the others are >> all rubbish" ;p > > Well if I wanted Red Hat family, I'd go with CentOS or RHEL; though > when it comes to commercial distros, SUSE has always struck me as a > bit "cleaner" from a sysadmin perspective. I've had a bit to do with Novell when I was at Telstra - we can pursue that off-list perhaps. Doesn't seem appropriate here. > > > Miles Fidelman > Kind regards and sincerest wishes that all your fears become faint memories. Until then - plan for the worst, hope for the best. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543d558e.5010...@gmail.com
