Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
Steve Litt wrote: > "Multi-seat" makes little sense now that when you add a user you can give him > or her a $400 computer with which he can share the server's data. I would beg to disagree - at least for some workloads. I think "it depends" is often teh answer to the question of "is multi-seat of any use ?" For your typical "office stuff" - WP, Email, etc - then I;d agree, a desktop PC with shared access to the file server is great. But back a couple of jobs ... We ran a Unix system (SCO OpenServer before SCO hit the self destruct button) with a large number of users. The primary tool used by most users was a single application which did all the sales, purchasing, stock control etc, etc. Mostly these were Wyse60 terminals - partly for historical reasons, the previous system was hard-coded for a Wyse 60. Running serial at 9600bps was quite adequate to give a good response time and almost all* the time this worked fine with anything up to 100 users on a Pentium with 16G RAM. In terms of data, it would make zero sense to have remote processing sharing the data off the server - the sales order detail (line items on sales orders) DB file would exceed 1G without any trouble. Since most of the work is database transactions, there is no sane alternative to a central DB server doing all the DB stuff. So even if you go to PCs on every desktop, you are still down to the client being an "intelligent display". As it happens, a later version of the program did have a native Windows client - which was basically a Window-ised version of the text interface. As it was, many users were migrating to Windows PCs using a terminal network over ethernet for the main system, and the usual sort of "office stuff" they got Windows for. But back to the clients we used, there is absolutely nothing as simple to manage on the factory floor tan a "green screen" terminal. It's really hard for the hammer fingered users to mess them up - and if they do, then it's generally nothing more than swapping out the broken one for a good one with zero config needed. Once you go to something more complicated, then the management costs go up - regardless of what system you use, there is more work in either manually configuring systems or setting up an automated system to do it. Oh yes, and did I mention that we ran across multiple sites ? For a while we ran about 10 users across a 19.2k leased line - that got upgraded to 64k when one of the serial muxes died and we upgraded to IP networking and terminal servers. * I said "almost all" the time. Any of you familiar with SCO OpenServer 5 will know that it has a link time configured disk buffer size, with a maximum size of 640,000kbytes - and yes, the system failed to boot if set to 640,001 kbytes. And note what I said about one single db file getting to over 1G, some of you will be ahead of me and know what's coming. The reporting tool that came with the package had an "interesting" feature in that it would suddenly stop using indexes for joins - you'd be developing a report and all would run fine, then a minor change and performance drops faster than a lead balloon. Non-indexed joins with files well over 1G and only 640M of disk cache - yup the system slows to a crawl with 99 to 100% wio and a long disk queue. We;d know if someone ran this particular report during the working day when the phones rang to say the system was frozen - everyone got stuck waiting for disk i/o. That was with fast (for their day) wide SCSI drives, arrayed across busses for maximum performance. In the end, it got to be run over the weekend and took 40 hours. At some point I re-wrote it in Informix SQL, taking care over use of indexes, and we could run it at any time without upsetting users and get the results in under 2 minutes. I was looking forward to us upgrading as a later version could run on Linux - and thus make use of more memory, would have been lovely to keep the DB in cache. It didn't happen while I was there, there was a bit of a business downturn and I was one of the ones that paid off. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
On 19/10/2018 15.04, Enrico Weigelt, metux IT consult wrote: OTOH, we could (as mentioned in another thread) invent some small declarative config file format for expressing at least the very common cases There already is init-d-script (5). https://www.commandlinux.com/man-page/man5/init-d-script.5.html Before I knew about this, i wrote unitscript: https://github.com/Daniel-Abrecht/unitscript But unitscript still lacks a lot of features and testing, and I don't really have time for this at the moment. It also isn't a debian or devuan packet yet, so using init-d-script is probably preferable. Regards, Daniel Abrecht ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
On 17.10.2018 15:14, Edward Bartolo wrote: > Why doesn't Devuan edit sysvinit to use systemd's unit files instead > of scripts? That would bypass the entire problem. That would be a *very complex* task - basically reimplementing much of systemd logic. Nothing that I could aggree to support. OTOH, we could (as mentioned in another thread) invent some small declarative config file format for expressing at least the very common cases, and use that for generating classic init scripts as well as systemd unit files. Perhaps configs for various supervisors could be generated from that too. This approach could actually benefit the upstreams, as they now can just declare what their services need, w/o ever having to care about all the distro-specific issues. Of course, this can only cope certain classes of services, and it really needs to be specified very precisely. (maybe even have distinct service types "x", "y", "z", etc). By the way: much of the stuff I see in the more complex init scripts could be moved out to external helpers, so the actual init scripts would be pretty trivial. --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
Am Freitag, 19. Oktober 2018 schrieb Steve Litt: > On Fri, 19 Oct 2018 14:50:39 +1100 > Erik Christiansen wrote: > > > On 18.10.18 11:37, Steve Litt wrote: > > > OK. Next question. What is the cost difference between a computer > > > terminal and a low power computer with the muscle to run apps whose > > > data is on the central server? > > > > The price of hardware was entirely different back then, making re-use > > much more compelling cost-wise. But the grunt wasn't there in my > > experience. To go with an HP64000 microprocessor development system, > > back in the 80s, I bought a small server with a (for then) big disk, > > and four green terminals IIRC. The whitepaper extolling its virtues > > claimed it'd be just spiffy for 4 users, with graphs, tables, and > > pages of text to "prove" it. But in practice the 68040 CPU only > > sufficed for editing. Once the team hit it with concurrent compiles, > > it died in the derriere. From then on, I was a convert to distributed > > processing, and sprinkled sparcstations about instead. (OK, LAN was > > over co-ax back then, and an unaware user could bring that down just > > by knocking the 50 ohm termination off the T-connector on the back of > > his machine, if it was the last on the run. Much easier to find if > > you'd run the cable, than if you had to hunt for it.) > > > > > If one uses terminals, how many users can a high power computer > > > handle? 50? 100? On the other hand, if every user contributes > > > enough CPU to run the apps, it could be thousands. > > > > With CPU, RAM, and HD costing only beans now, we can can now give each > > user what was then a supercomputer, for what they paid for a terminal. > > Apart from the increased performance, even with what we had back then, > > the fault tolerance inherent in distributed computing didn't escape my > > notice, given responsibility for meeting project deadlines. > > > > Another team did go for a humungous refrigerator-sized quad-cpu HP > > compute server with 50 hard drives in a second refrigerator-sized > > enclosure, but I stayed distributed. (The quad-cpu mobo was nearly a > > yard square.) > > > > Erik > > Thanks Erik, > > You beautifully said what I was trying to. "Multi-seat" makes little > sense now that when you add a user you can give him or her a $400 > computer with which he can share the server's data. I'm of the opinion > that "multi-seat" isn't a benefit, it isn't a feature, it's just a > marketing gimmick not a whole lot different than a magnesium paddle > shifter in a car. > > And to refresh memories of context earlier in this thread, "multi-seat" > is one of the many systemd features that I opined did not need to be > reproduced by the Debian project, or anyone else. > > SteveT > > Steve Litt > September 2018 featured book: Quit Joblessness: Start Your Own Business > http://www.troubleshooters.com/startbiz > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > Multi-seat was a big thing ~ 20-30 years ago. I once built an internet caffee with that stuff from donated hardware, but it was put to a rest a year later. As were the X11-terminals, as which virtually all old computers from physics department ended. Technology from the past, gone with the wind. Same happened to "Thin clients" - which does not hinder some high$$ companies to still sell that stuff (windows terminal server, anyone?) - a RPi3 has more power for almost everything for a fraction of the cost. And then there is the tale of "Africa and the 3rd world", where all donated computers end some day ... well, dream on "multi-seat". Just my 2¢ Nik -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
On Fri, 19 Oct 2018 14:50:39 +1100 Erik Christiansen wrote: > On 18.10.18 11:37, Steve Litt wrote: > > OK. Next question. What is the cost difference between a computer > > terminal and a low power computer with the muscle to run apps whose > > data is on the central server? > > The price of hardware was entirely different back then, making re-use > much more compelling cost-wise. But the grunt wasn't there in my > experience. To go with an HP64000 microprocessor development system, > back in the 80s, I bought a small server with a (for then) big disk, > and four green terminals IIRC. The whitepaper extolling its virtues > claimed it'd be just spiffy for 4 users, with graphs, tables, and > pages of text to "prove" it. But in practice the 68040 CPU only > sufficed for editing. Once the team hit it with concurrent compiles, > it died in the derriere. From then on, I was a convert to distributed > processing, and sprinkled sparcstations about instead. (OK, LAN was > over co-ax back then, and an unaware user could bring that down just > by knocking the 50 ohm termination off the T-connector on the back of > his machine, if it was the last on the run. Much easier to find if > you'd run the cable, than if you had to hunt for it.) > > > If one uses terminals, how many users can a high power computer > > handle? 50? 100? On the other hand, if every user contributes > > enough CPU to run the apps, it could be thousands. > > With CPU, RAM, and HD costing only beans now, we can can now give each > user what was then a supercomputer, for what they paid for a terminal. > Apart from the increased performance, even with what we had back then, > the fault tolerance inherent in distributed computing didn't escape my > notice, given responsibility for meeting project deadlines. > > Another team did go for a humungous refrigerator-sized quad-cpu HP > compute server with 50 hard drives in a second refrigerator-sized > enclosure, but I stayed distributed. (The quad-cpu mobo was nearly a > yard square.) > > Erik Thanks Erik, You beautifully said what I was trying to. "Multi-seat" makes little sense now that when you add a user you can give him or her a $400 computer with which he can share the server's data. I'm of the opinion that "multi-seat" isn't a benefit, it isn't a feature, it's just a marketing gimmick not a whole lot different than a magnesium paddle shifter in a car. And to refresh memories of context earlier in this thread, "multi-seat" is one of the many systemd features that I opined did not need to be reproduced by the Debian project, or anyone else. SteveT Steve Litt September 2018 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
On 18.10.18 11:37, Steve Litt wrote: > OK. Next question. What is the cost difference between a computer > terminal and a low power computer with the muscle to run apps whose > data is on the central server? The price of hardware was entirely different back then, making re-use much more compelling cost-wise. But the grunt wasn't there in my experience. To go with an HP64000 microprocessor development system, back in the 80s, I bought a small server with a (for then) big disk, and four green terminals IIRC. The whitepaper extolling its virtues claimed it'd be just spiffy for 4 users, with graphs, tables, and pages of text to "prove" it. But in practice the 68040 CPU only sufficed for editing. Once the team hit it with concurrent compiles, it died in the derriere. From then on, I was a convert to distributed processing, and sprinkled sparcstations about instead. (OK, LAN was over co-ax back then, and an unaware user could bring that down just by knocking the 50 ohm termination off the T-connector on the back of his machine, if it was the last on the run. Much easier to find if you'd run the cable, than if you had to hunt for it.) > If one uses terminals, how many users can a high power computer handle? > 50? 100? On the other hand, if every user contributes enough CPU to run > the apps, it could be thousands. With CPU, RAM, and HD costing only beans now, we can can now give each user what was then a supercomputer, for what they paid for a terminal. Apart from the increased performance, even with what we had back then, the fault tolerance inherent in distributed computing didn't escape my notice, given responsibility for meeting project deadlines. Another team did go for a humungous refrigerator-sized quad-cpu HP compute server with 50 hard drives in a second refrigerator-sized enclosure, but I stayed distributed. (The quad-cpu mobo was nearly a yard square.) Erik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
On Thu, Oct 18, 2018 at 11:37:13AM -0400, Steve Litt wrote:
> On Thu, 18 Oct 2018 08:50:51 -0400
> Hendrik Boom wrote:
>
> > On Thu, Oct 18, 2018 at 09:17:13AM -0300, Fernando M. Maresca wrote:
> > > On Wed, Oct 17, 2018 at 04:20:36PM -0400, Steve Litt wrote:
> > > >
> > > > Multiseating? When's the last time you had serial cables to
> > > > monitors? We have much more efficient Gigabit Eternet.
> >
> > Over serial lines? 1979. With text-only terminals. I think it may
> > have been on Unix version 3 or so.
> >
> > The last time I used what I perceived as multiseating it was done
> > over 10-megabit Ethernet. Worked fine.
>
> OK. Next question. What is the cost difference between a computer
> terminal and a low power computer with the muscle to run apps whose
> data is on the central server?
Terminal:
Portable: HP mt21: $449
Stationary: HP t430: $261, needs keyboard+mouse+monitor
Low power computer:
Portable: Pinebook: $89
Stationary: many, $25ish for good enough, needs keyboard+mouse+monitor
("Good enough" turns out to be mostly about memory; 2GB runs a bloated
browser fine if you unlearn your tab habits; anything else like LibreOffice
or such doesn't need as much oomph.)
Obviously, an actual computer can also run ssh or VNC.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary,
⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex,
⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
On Thu, 18 Oct 2018 08:50:51 -0400 Hendrik Boom wrote: > On Thu, Oct 18, 2018 at 09:17:13AM -0300, Fernando M. Maresca wrote: > > On Wed, Oct 17, 2018 at 04:20:36PM -0400, Steve Litt wrote: > > > Cgroups? There are other ways to do Cgroups without systemd, and > > > a lot of systemd's buzz for using cgroups is available in runit, > > > which has the finish script to clean up, and the finish script > > > for process A can stop process b, c and d if that's desired. > > > There's almost nothing *needed* that systemd can do that runit > > > can't do, except lock your OS in a "no replaceable parts shield. > > Aren't cgroups implemented in the kernel anyway? Yes. SteveT Steve Litt September 2018 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
On Thu, 18 Oct 2018 08:50:51 -0400 Hendrik Boom wrote: > On Thu, Oct 18, 2018 at 09:17:13AM -0300, Fernando M. Maresca wrote: > > On Wed, Oct 17, 2018 at 04:20:36PM -0400, Steve Litt wrote: > > > > > > Multiseating? When's the last time you had serial cables to > > > monitors? We have much more efficient Gigabit Eternet. > > Over serial lines? 1979. With text-only terminals. I think it may > have been on Unix version 3 or so. > > The last time I used what I perceived as multiseating it was done > over 10-megabit Ethernet. Worked fine. OK. Next question. What is the cost difference between a computer terminal and a low power computer with the muscle to run apps whose data is on the central server? If one uses terminals, how many users can a high power computer handle? 50? 100? On the other hand, if every user contributes enough CPU to run the apps, it could be thousands. SteveT SteveT Steve Litt September 2018 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
On Thu, Oct 18, 2018 at 09:17:13AM -0300, Fernando M. Maresca wrote: > On Wed, Oct 17, 2018 at 04:20:36PM -0400, Steve Litt wrote: > > > > Multiseating? When's the last time you had serial cables to monitors? > > We have much more efficient Gigabit Eternet. Over serial lines? 1979. With text-only terminals. I think it may have been on Unix version 3 or so. The last time I used what I perceived as multiseating it was done over 10-megabit Ethernet. Worked fine. > > Cgroups? There are other ways to do Cgroups without systemd, and a lot > > of systemd's buzz for using cgroups is available in runit, which has > > the finish script to clean up, and the finish script for process A can > > stop process b, c and d if that's desired. There's almost nothing > > *needed* that systemd can do that runit can't do, except lock your OS > > in a "no replaceable parts shield. Aren't cgroups implemented in the kernel anyway? -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
On Wed, Oct 17, 2018 at 04:58:33PM +0200, KatolaZ wrote: > On Wed, Oct 17, 2018 at 09:30:50AM -0500, Daniel Taylor wrote: > > [cut] > > > > c) where and how would you draw the line indicating what's unacceptable > > > about > > > systemd - in other words, what exactly do you mean by "the Unix paradigm" > > > in > > > your comment above? > > Split out the PID 1 stuff to just the bare minimum of what needs to be > > there, organize everything else into appropriate units. > > > > This is not a trivial project, which is why nobody has taken it on AFAIK, > > but systemd must be doing something that package maintainers and developers > > want. That suggests that the way to beat them is to do that, only better. > > The problem is exactly there: you don't really need systemd if you > just need a reliable PID 1. What appeals systemd's enthusiasts is the > process supervision and management system. Which is probably 90% of > the reason why systemd needed to fagocitate the whole low-level > user-space (please remember that the only way to reliably know that a > process is dead under unix is to be the parent of that process). > > I know the issue looks easy and straightforward on the surface. But > when you start looking into it seriously, you quickly realise that > things are not as straightforward as you thought ;) To summarize (IIUC) the main beneficiaries of systemd are: 1) a few heavyweight desktop frameworks and tightly coupled applications 2) some heavy-duty system administrators who want to use systemd's process management General-purpose applications (and daemons, etc.) that attempt to do one (non-desktoppy) thing well either don't require systemd, or systemd support is a compile-time option that can be opted out of. I, personally, see no single attraction in all of the systemd bandwagon. But then I work in the terminal when I can, and still type the u?mount commands every day. Perhaps someone could implement a reasonable subset of support for systemd unit files, but why bother? As discussed here ad nauseum, you can get sufficient process management abilities elsewhere, with less pain. The others (please speak up if I'm mistaken) are mainly interested in desktop environments, for which a subset of systemd's abilities will likely never be good enough. Devuan already provides DBus, which is magical enough for a lot of GUI cleverness. I will be interested to see if there are users for a process management framework that supports systemd unit files. Right now it looks like an itch that no one is interested in scratching. More power to anyone who wants to take a stab at it. I'm here with my popcorn to see what happens. AFAIK, I have only a few daemons running on my system, and would rather use some lightweight framework to start and supervise them even if I had to write half a dozen scripts myself. Why would I want millions of lines of code developed by someone whose agenda is so radically different from my own goals and aspirations? Why would I want compatibility with something fiendishly complicated and created for what appears to be no more than creating jobs and breaking with the battle tested philosophies of administering systems under unix. Well, there I am ranting again :-) Have fun, guys and gals, keep coding and smiling. Trolls are invited to sit down to lunch, and eat politely :-) > My2Cents I consider my thoughts to be more like rounding errors, based on bruises and hard-won lessons of trying to fit square pegs in round holes :-) Joel > KatolaZ > > -- > [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] > [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] > [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] > [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] > [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Joel Roth ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
On Wed, 17 Oct 2018 16:58:33 +0200 KatolaZ wrote: > On Wed, Oct 17, 2018 at 09:30:50AM -0500, Daniel Taylor wrote: > > [cut] > > > > c) where and how would you draw the line indicating what's > > > unacceptable about systemd - in other words, what exactly do you > > > mean by "the Unix paradigm" in your comment above? > > Split out the PID 1 stuff to just the bare minimum of what needs to > > be there, organize everything else into appropriate units. > > > > This is not a trivial project, which is why nobody has taken it on > > AFAIK, but systemd must be doing something that package maintainers > > and developers want. That suggests that the way to beat them is to > > do that, only better. > > The problem is exactly there: you don't really need systemd if you > just need a reliable PID 1. What appeals systemd's enthusiasts is the > process supervision and management system. In the preceding paragraph, you perfectly described both runit and s6. SteveT Steve Litt September 2018 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
> ..the systemd approach was (and still is?) convert (or "generate")
> sysvinit scripts into systemd unit files.
Still is. But that is only half the issue. As mentioned already, any
attempt to run a sysv script is intercepted by SystemD. The
corresponding unit file ('generated' or 'packaged') is executed
*instead*. This is seriously flawed (take the simple case where the
sysvinit script fixes up the ENV for a daemon service in some custom
way, SystemD fails to pass that on in it's 'generated' unit file).
I recently had an issue where SystemD failed to stop a service (to
reload the configuration on restart) after an upgrade. Investigation
revealed that SystemD could no longer identify the running daemon, and
as it could not find it, claimed it was already stopped.
'killall -TERM' found it fine.
> "All" we need to do, is reverse this approach to support or convert
> "native systemd" software with "no non-systemd support" into something
> we _can_ use.
Reversing \ converting the unit scripts is not enough, Time services
have been hooked by SystemD, Networking has been hooked by SystemD,
Logging is hooked by SystemD, UDEV os hooked by SystemD, etc, etc, all
that needs to be undone too.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
On Wed, Oct 17, 2018 at 05:51:11PM +0200, Antony Stone wrote: > On Wednesday 17 October 2018 at 17:37:14, Bruce Ferrell wrote: > > > "They" REALLY want to force the use of systemd. > > > > I REALLY don't want to use systemd. I've seen too many problems since > > it's introduction. > > > > Now that I've completed my sermon to the choir... Shall I speak on the > > patch to Apache they felt necessary that broke serving wordpress? > > Not unless it's relevant / important to Devuan :) It might be if any of us use Apache to serve wordpress. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
On Wed, 17 Oct 2018 15:14:46 +0200, Edward wrote in message : > Why doesn't Devuan edit sysvinit to use systemd's unit files instead > of scripts? That would bypass the entire problem. Those who want to > stick to scripts can always direct sysvinit to use scripts instead. ..the systemd approach was (and still is?) convert (or "generate") sysvinit scripts into systemd unit files. "All" we need to do, is reverse this approach to support or convert "native systemd" software with "no non-systemd support" into something we _can_ use. ..the 4 other kinds of software: 0. has no need for "init support", 1. "is natively supported by all native Devuan init systems", and 2. buggy ones where we need to yank libsystemd0 etc "support", and 3. "has native support by a native Devuan init system" where we can fetch the source UPSTREAM of Debian.org and build as Devuan .debs, you know, just like Debian.org USED to do in the good old day before pulseaudio etc. > An edit/patch would aim to make sysvinit recognise unit files and run > scripts when instructed to. > > Before I get a barrage of smart-ass replies like 'You do not > understand', yes, I know, it is EASIER SAID than DONE. Everything > technical is like that, unfortunately. ..hear, hear. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
On 10/17/18 8:51 AM, Antony Stone wrote: On Wednesday 17 October 2018 at 17:37:14, Bruce Ferrell wrote: On 10/17/18 8:24 AM, info at smallinnovations dot nl wrote: On 17-10-18 15:14, Edward Bartolo wrote: Why doesn't Devuan edit sysvinit to use systemd's unit files instead of scripts? That would bypass the entire problem. Those who want to stick to scripts can always direct sysvinit to use scripts instead. An edit/patch would aim to make sysvinit recognise unit files and run scripts when instructed to. Before I get a barrage of smart-ass replies like 'You do not understand', yes, I know, it is EASIER SAID than DONE. Everything technical is like that, unfortunately. This has been discussed before on this list. My proposal was to replace libsystemd0 with a devuan specific version (see Re: [DNG] Provides: libsystemd0 (was Re: systemd and ssh-server)) with a modular api system. Which also could be extended to a version that uses the systemd unit file. But it is not simple and i do not have the programmer skills to build it my self. Actually, it's NOT that difficult... On one distro I've seen, the sysv init scripts sources a system shell function file. Care to name that distro? One of those functions would test for the presence of elements of systemd. If found, use systemd and it's unit files. Else use "normal" init mechanisms. I used to patch the init scripts to make systemd "vanish" for certain things... Then the distro devs pulled that ability from that system shell function file. How long ago? "They" REALLY want to force the use of systemd. I REALLY don't want to use systemd. I've seen too many problems since it's introduction. Now that I've completed my sermon to the choir... Shall I speak on the patch to Apache they felt necessary that broke serving wordpress? Not unless it's relevant / important to Devuan :) Antony. Anthony I'm trying REALLY hard to not escalate this so I'll just leave the distro unnamed, if I may. It isn't out of North Carolina though. The sysV patch trick disappeared... I guess about two years ago in a rolling update. It made me unhappy. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
On Wednesday 17 October 2018 at 17:37:14, Bruce Ferrell wrote: > On 10/17/18 8:24 AM, info at smallinnovations dot nl wrote: > > On 17-10-18 15:14, Edward Bartolo wrote: > >> Why doesn't Devuan edit sysvinit to use systemd's unit files instead > >> of scripts? That would bypass the entire problem. Those who want to > >> stick to scripts can always direct sysvinit to use scripts instead. An > >> edit/patch would aim to make sysvinit recognise unit files and run > >> scripts when instructed to. > >> > >> Before I get a barrage of smart-ass replies like 'You do not > >> understand', yes, I know, it is EASIER SAID than DONE. Everything > >> technical is like that, unfortunately. > > > > This has been discussed before on this list. My proposal was to replace > > libsystemd0 with a devuan specific version (see Re: [DNG] Provides: > > libsystemd0 (was Re: systemd and ssh-server)) with a modular api system. > > Which also could be extended to a version that uses the systemd unit > > file. > > > > But it is not simple and i do not have the programmer skills to build it > > my self. > > Actually, it's NOT that difficult... > > On one distro I've seen, the sysv init scripts sources a system shell > function file. Care to name that distro? > One of those functions would test for the presence of elements of > systemd. If found, use systemd and it's unit files. Else use "normal" > init mechanisms. > > I used to patch the init scripts to make systemd "vanish" for certain > things... Then the distro devs pulled that ability from that system > shell function file. How long ago? > "They" REALLY want to force the use of systemd. > > I REALLY don't want to use systemd. I've seen too many problems since > it's introduction. > > Now that I've completed my sermon to the choir... Shall I speak on the > patch to Apache they felt necessary that broke serving wordpress? Not unless it's relevant / important to Devuan :) Antony. -- What do you call a dinosaur with only one eye? A Doyouthinkesaurus. Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
On 10/17/18 8:24 AM, info at smallinnovations dot nl wrote: On 17-10-18 15:14, Edward Bartolo wrote: Why doesn't Devuan edit sysvinit to use systemd's unit files instead of scripts? That would bypass the entire problem. Those who want to stick to scripts can always direct sysvinit to use scripts instead. An edit/patch would aim to make sysvinit recognise unit files and run scripts when instructed to. Before I get a barrage of smart-ass replies like 'You do not understand', yes, I know, it is EASIER SAID than DONE. Everything technical is like that, unfortunately. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng This has been discussed before on this list. My proposal was to replace libsystemd0 with a devuan specific version (see Re: [DNG] Provides: libsystemd0 (was Re: systemd and ssh-server)) with a modular api system. Which also could be extended to a version that uses the systemd unit file. But it is not simple and i do not have the programmer skills to build it my self. Grtz Nick Actually, it's NOT that difficult... On one distro I've seen, the sysv init scripts sources a system shell function file. One of those functions would test for the presence of elements of systemd. If found, use systemd and it's unit files. Else use "normal" init mechanisms. I used to patch the init scripts to make systemd "vanish" for certain things... Then the distro devs pulled that ability from that system shell function file. "They" REALLY want to force the use of systemd. I REALLY don't want to use systemd. I've seen too many problems since it's introduction. Now that I've completed my sermon to the choir... Shall I speak on the patch to Apache they felt necessary that broke serving wordpress? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
On 17-10-18 15:14, Edward Bartolo wrote: > Why doesn't Devuan edit sysvinit to use systemd's unit files instead > of scripts? That would bypass the entire problem. Those who want to > stick to scripts can always direct sysvinit to use scripts instead. An > edit/patch would aim to make sysvinit recognise unit files and run > scripts when instructed to. > > Before I get a barrage of smart-ass replies like 'You do not > understand', yes, I know, it is EASIER SAID than DONE. Everything > technical is like that, unfortunately. > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng This has been discussed before on this list. My proposal was to replace libsystemd0 with a devuan specific version (see Re: [DNG] Provides: libsystemd0 (was Re: systemd and ssh-server)) with a modular api system. Which also could be extended to a version that uses the systemd unit file. But it is not simple and i do not have the programmer skills to build it my self. Grtz Nick signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
KatolaZ - 17.10.18, 16:58: > process supervision and management system. Which is probably 90% of > the reason why systemd needed to fagocitate the whole low-level > user-space (please remember that the only way to reliably know that a > process is dead under unix is to be the parent of that process). AFAIK runit does just that. It stuffes a parent process before each service. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
On 10/17/18 9:58 AM, KatolaZ wrote: On Wed, Oct 17, 2018 at 09:30:50AM -0500, Daniel Taylor wrote: [cut] c) where and how would you draw the line indicating what's unacceptable about systemd - in other words, what exactly do you mean by "the Unix paradigm" in your comment above? Split out the PID 1 stuff to just the bare minimum of what needs to be there, organize everything else into appropriate units. This is not a trivial project, which is why nobody has taken it on AFAIK, but systemd must be doing something that package maintainers and developers want. That suggests that the way to beat them is to do that, only better. The problem is exactly there: you don't really need systemd if you just need a reliable PID 1. What appeals systemd's enthusiasts is the process supervision and management system. Which is probably 90% of the reason why systemd needed to fagocitate the whole low-level user-space (please remember that the only way to reliably know that a process is dead under unix is to be the parent of that process). You can be the parent process of a userspace without being PID 1. That's the beauty of it. I know the issue looks easy and straightforward on the surface. But when you start looking into it seriously, you quickly realise that things are not as straightforward as you thought ;) The problem description is very straightforward. I don't know how hard implementing it will be. I guess as the person who suggested it, it's my responsibility to at least scope it out properly. Me and my big mouth. -- Daniel Taylor ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
On Wed, Oct 17, 2018 at 09:30:50AM -0500, Daniel Taylor wrote: [cut] > > c) where and how would you draw the line indicating what's unacceptable > > about > > systemd - in other words, what exactly do you mean by "the Unix paradigm" in > > your comment above? > Split out the PID 1 stuff to just the bare minimum of what needs to be > there, organize everything else into appropriate units. > > This is not a trivial project, which is why nobody has taken it on AFAIK, > but systemd must be doing something that package maintainers and developers > want. That suggests that the way to beat them is to do that, only better. The problem is exactly there: you don't really need systemd if you just need a reliable PID 1. What appeals systemd's enthusiasts is the process supervision and management system. Which is probably 90% of the reason why systemd needed to fagocitate the whole low-level user-space (please remember that the only way to reliably know that a process is dead under unix is to be the parent of that process). I know the issue looks easy and straightforward on the surface. But when you start looking into it seriously, you quickly realise that things are not as straightforward as you thought ;) My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
On 10/17/18 9:08 AM, Antony Stone wrote: On Wednesday 17 October 2018 at 15:54:11, Daniel Taylor wrote: I am becoming convinced that the proper course of attack is to reimplement all the systemd functions in the Unix paradigm. a) I seriously doubt that that is possible, without effectively just re-writing systemd Well, yes, that's exactly what it would take. b) systemd's goalposts also move sufficiently fast that it would also be a constant game of catch-up Nope. Just have to implement what developers are using that isn't already provided by existing programs. This becomes practical as systemd already has enough penetration for installed base to provide resistance. c) where and how would you draw the line indicating what's unacceptable about systemd - in other words, what exactly do you mean by "the Unix paradigm" in your comment above? Split out the PID 1 stuff to just the bare minimum of what needs to be there, organize everything else into appropriate units. This is not a trivial project, which is why nobody has taken it on AFAIK, but systemd must be doing something that package maintainers and developers want. That suggests that the way to beat them is to do that, only better. Too many developers are embracing systemd and it's getting harder to keep a functional Linux system without it. True, but reimplementing it in some other way sounds to me as though you're going to end up with the functionality we despise, just created with different code? By splitting it up we can make the parts modular, so someone can have sysvinit startup script handling or systemd modules. The systemd stub libraries are a starting point. We can, in theory, rip the whole damn thing apart so that sysadmins have more control of which parts they use. In particular, being able to toss the damn broken logging in the bit bucket while keeping utility functions used by programs we need to use. Sometimes the only way out is through. Yes, but surely not to the same destination as the entire Devuan project is trying to avoid? Very much not to that destination. In particular I'm thinking that having a fully functional set of utility functions so that we can save work modifying packages that depend on systemd. libaltd PROVIDES=systemd -- Daniel Taylor ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
On Wednesday 17 October 2018 at 15:54:11, Daniel Taylor wrote: > I am becoming convinced that the proper course of attack is to reimplement > all the systemd functions in the Unix paradigm. a) I seriously doubt that that is possible, without effectively just re-writing systemd b) systemd's goalposts also move sufficiently fast that it would also be a constant game of catch-up c) where and how would you draw the line indicating what's unacceptable about systemd - in other words, what exactly do you mean by "the Unix paradigm" in your comment above? > Too many developers are embracing systemd and it's getting harder to keep a > functional Linux system without it. True, but reimplementing it in some other way sounds to me as though you're going to end up with the functionality we despise, just created with different code? > Sometimes the only way out is through. Yes, but surely not to the same destination as the entire Devuan project is trying to avoid? Antony. -- Wanted: telepath. You know where to apply. Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
On 10/17/18 8:14 AM, Edward Bartolo wrote: Why doesn't Devuan edit sysvinit to use systemd's unit files instead of scripts? That would bypass the entire problem. Those who want to stick to scripts can always direct sysvinit to use scripts instead. An edit/patch would aim to make sysvinit recognise unit files and run scripts when instructed to. Before I get a barrage of smart-ass replies like 'You do not understand', yes, I know, it is EASIER SAID than DONE. Everything technical is like that, unfortunately. Well, it _is_ a non-trivial project. The way things are going I am becoming convinced that the proper course of attack is to reimplement all the systemd functions in the Unix paradigm. Too many developers are embracing systemd and it's getting harder to keep a functional Linux system without it. Sometimes the only way out is through. -- Daniel Taylor ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
