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
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] Case studies of high-traffic web sites running Devuan?
On 10/18/18 2:46 PM, Daniel Klein wrote: > On 10/17/18 05:09, Lars Noodén wrote: >> Are there any case studies about large, high-traffic web sites running >> Devuan? [snip] > classictic.com runs with devuan, as most of the supporting systems. Some are > still debian. > I can't say that it is more stable than debian was, but at least as stable > as it. 2 1/2 years and counting. All problems so far were database issues > and such. Thanks. /Lars ___ 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] automatic init script generation
On 2018-10-17 11:29, Hendrik Boom wrote: > On Tue, Oct 16, 2018 at 06:05:21PM +0200, Enrico Weigelt, metux IT consult > wrote: > > > > I personally, got tired of inventing yet another init system - did that > > over 20 years ago (actually, some things not so different from *early* > > systemd - before they became totally nuts). > > > > The problem, IMHO, isn't so much creating an init system, but > > maintaining the corresponding config/scripts for all the packages. > > > > One thing we perhaps could do is inventing a small declarative meta- > > config language for certain common service types / usecases, so we > > could automatically generate a large portion of the scripts/config > > automatically for many init systems. > > As long as it doesn't metastatize into yet another thing like > systemd unit files, incompatible with everything else. > I realise that avoiding that is what you're proposing, but it's worth > emphasizing. > Systemd's unit files may well contain the information we need, but it's > mot clear to me that their specification is stable enough for our > purpose. > > I wonder if the right place to start is to write some kind of text > processor that looks through existing init scripts lookinfg for > similarity and difference, and then sorting out which differences are > important and which similarities are copied bugs. > > -- hendrik > I'm looking at unitfile -> sysvinit conversion for a remaster project of mine. The scope is narrow in my case, but I'm curious if it could scale enough to be useful. Like... convert the bulk of standard service management and automatically detect weird edge cases for manual review... (e.g. dumping them to file as "interesting, weird, please check me..."). It would likely be a net gain over trying to get raw manpower to handle every single package always. Maybe take this an inch at a time so it doesn't metastatize. Enough to be useful but no more (especially not enough to become its own stand-alone PITA). - ZE ___ 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
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] automatic init script generation
On Fri, Oct 19, 2018 at 05:05:07PM +, zeitgeisteater wrote: > On 2018-10-17 11:29, Hendrik Boom wrote: > > On Tue, Oct 16, 2018 at 06:05:21PM +0200, Enrico Weigelt, metux IT consult > > wrote: > > > > > > I personally, got tired of inventing yet another init system - did that > > > over 20 years ago (actually, some things not so different from *early* > > > systemd - before they became totally nuts). > > > > > > The problem, IMHO, isn't so much creating an init system, but > > > maintaining the corresponding config/scripts for all the packages. > > > > > > One thing we perhaps could do is inventing a small declarative meta- > > > config language for certain common service types / usecases, so we > > > could automatically generate a large portion of the scripts/config > > > automatically for many init systems. > > > > As long as it doesn't metastatize into yet another thing like > > systemd unit files, incompatible with everything else. > > I realise that avoiding that is what you're proposing, but it's worth > > emphasizing. > > Systemd's unit files may well contain the information we need, but it's > > mot clear to me that their specification is stable enough for our > > purpose. > > > > I wonder if the right place to start is to write some kind of text > > processor that looks through existing init scripts lookinfg for > > similarity and difference, and then sorting out which differences are > > important and which similarities are copied bugs. > > > > -- hendrik > > > I'm looking at unitfile -> sysvinit conversion for a remaster project of mine. > The scope is narrow in my case, but I'm curious if it could scale enough to be > useful. Like... convert the bulk of standard service management and > automatically detect weird edge cases for manual review... (e.g. dumping them > to > file as "interesting, weird, please check me..."). It would likely be a net > gain > over trying to get raw manpower to handle every single package always. > > Maybe take this an inch at a time so it doesn't metastatize. Enough to be > useful > but no more (especially not enough to become its own stand-alone PITA). > > - ZE Looks like a practical way to go about it. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Stop the madness!
Some folks are asking for automatic sysvinit init script generation, or else unit file to sysvinit init script converters. Some are asking Devuan's developers to prioritize their scarce programmer resources to modifying sysvinit, which is over 30 years old. Yet others think we should reimplement all the systemd functions in the Unix paradigm. Stop the madness! Systemd units are config files, like Win98 had, with one level of groups designated by square brackets, and a lower level of key value pairs with equal signs between key and value. In other words, a collection of pushbuttons and dials that you can choose from, and a rather large collection because, with the config file, you can no longer go offroad and do something special with a shellscript. Think config files are simple? Well, look at the large collection of potentially conflicting and/or ambiguous systemd pushbuttons and dials: https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files And, of course, pushbuttons and dials by their very nature are limiting, so there will be more and more in the future to cover corner cases. Or the redhat funded project will eventually add a few places where you can put very restricted scripts to go where the dials and buttons can't. Some Devuaners will say "but wait, bad as that is, it's still better than modern init scripts." Those who say that have drunk Lennart's flavored drink and embraced the sysvinit/systemd false choice. Runit uses shellscripts, embraces them heartily, and yet hardly a runit run script exceeds ten lines. Take a good look at this collection of runit run scripts, straight from runit's developer: http://smarden.org/runit/runscripts.htm Runit run scripts can do anything unit files can do, and more. Usually in under 10 lines. A couple months ago a snotty systemd fanboy chided me that runit couldn't start several processes at once. Oh yeah? http://smarden.org/runit/faq.html#depends And if you want the stopping of one service to stop others, that can be done too, via the finish script, which has knowledge of its supervised daemon's exit code. I recently upgraded my unbound run script to start a shellscript to pre-load common domains into its cache: === #!/bin/sh if ping -4 -c1 8.8.8.8 > /dev/null; then (/etc/unbound/primecache.sh &) exec unbound -dp else sleep 1 fi === Let's review the preceding. A functioning network is required, hence the ping command. If the network is functioning, the primecache.sh program is run in the background, and then immediately this shellscript's process becomes the unbound executable. The primecache.sh program starts with a 2 second sleep, so there's no reasonable possiblity of a race condition where cache starts priming before unbound is run, unless there's something unusually wrong with unbound. If no network, it sleeps a second and tries again. It would take only a few more lines of code to count to 10 tries and then sending a message and preventing further tries, but I personally think this would be overkill. Lennart pats himself on the back for his parallel instantiation. Notice how I allowed primecache.sh to run, in the background, while other boot activities were done. But wait, there's more. Runit goes around in a circle, creating 1 daemon supervisors, without stopping to wait if those 1 daemon supervisors succeed. In parallel, those 1 daemon supervisors each start their daemon, whether it takes 0.1 seconds or 30 seconds. IN OTHER WORDS... If you're happy with sysvinit, that's fine. But if sysvinit no longer suits your use case, or you're afraid it will no longer work with systemd apps and daemons, then don't try to massively bring up to date the 30 year old jalopy from the days of Devo and Pat Banatar and distributors and carburetors, instead switch to something that already accommodates your needs: Runit (or s6). And don't forget, until Devuan Devs get around to making the runit package a genuine PID1, you can, right now, today, run runit on top of sysvinit, and one by one switch services from /etc/rc.d/init.d scripts to runit run scripts, by shutting off the service on the sysvinit end, and downloading or making a runit run script and then making one symlink. A lot of run scripts are available at http://smarden.org/runit/runscripts.htm . I will be curating a collection of more runit run scripts in the near future. In other words, unless you view sysvinit as an antique to be kept around for sentimental value, don't put any work into it. Drive it while it fits your needs, then call the tow truck to tow it away and get your brand new runit supervisor. 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://mailing
Re: [DNG] Stop the madness!
> On 20 Oct 2018, at 12:55, Steve Litt wrote: > > Some folks are asking for automatic sysvinit init script generation, or > else unit file to sysvinit init script converters. Some are asking > Devuan's developers to prioritize their scarce programmer resources to > modifying sysvinit, which is over 30 years old. Yet others think we > should reimplement all the systemd functions in the Unix paradigm. > > Stop the madness! > > Systemd units are config files, like Win98 had, with one level of > groups designated by square brackets, and a lower level of key value > pairs with equal signs between key and value. In other words, a > collection of pushbuttons and dials that you can choose from, and a > rather large collection because, with the config file, you can no > longer go offroad and do something special with a shellscript. > > Think config files are simple? Well, look at the large collection of > potentially conflicting and/or ambiguous systemd pushbuttons and dials: > > https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files > > And, of course, pushbuttons and dials by their very nature are > limiting, so there will be more and more in the future to cover corner > cases. Or the redhat funded project will eventually add a few places > where you can put very restricted scripts to go where the dials and > buttons can't. > > Some Devuaners will say "but wait, bad as that is, it's still better > than modern init scripts." Those who say that have drunk Lennart's > flavored drink and embraced the sysvinit/systemd false choice. > > Runit uses shellscripts, embraces them heartily, and yet > hardly a runit run script exceeds ten lines. Take a good look at this > collection of runit run scripts, straight from runit's developer: > > http://smarden.org/runit/runscripts.htm > > Runit run scripts can do anything unit files can do, and more. Usually > in under 10 lines. A couple months ago a snotty systemd fanboy chided > me that runit couldn't start several processes at once. Oh yeah? > > http://smarden.org/runit/faq.html#depends > > And if you want the stopping of one service to stop others, that > can be done too, via the finish script, which has knowledge of its > supervised daemon's exit code. > > I recently upgraded my unbound run script to start a shellscript to > pre-load common domains into its cache: > > === > #!/bin/sh > if ping -4 -c1 8.8.8.8 > /dev/null; then >(/etc/unbound/primecache.sh &) >exec unbound -dp > else >sleep 1 > fi > === > > Let's review the preceding. A functioning network is required, hence > the ping command. If the network is functioning, the primecache.sh > program is run in the background, and then immediately this > shellscript's process becomes the unbound executable. The primecache.sh > program starts with a 2 second sleep, so there's no reasonable > possiblity of a race condition where cache starts priming before > unbound is run, unless there's something unusually wrong with unbound. > > If no network, it sleeps a second and tries again. It would take only a > few more lines of code to count to 10 tries and then sending a message > and preventing further tries, but I personally think this would be > overkill. > > Lennart pats himself on the back for his parallel instantiation. Notice > how I allowed primecache.sh to run, in the background, while other boot > activities were done. But wait, there's more. Runit goes around in a > circle, creating 1 daemon supervisors, without stopping to wait if > those 1 daemon supervisors succeed. In parallel, those 1 daemon > supervisors each start their daemon, whether it takes 0.1 seconds or 30 > seconds. > > IN OTHER WORDS... > > If you're happy with sysvinit, that's fine. But if sysvinit no longer > suits your use case, or you're afraid it will no longer work with > systemd apps and daemons, then don't try to massively bring up to date > the 30 year old jalopy from the days of Devo and Pat Banatar and > distributors and carburetors, instead switch to something that already > accommodates your needs: Runit (or s6). > > And don't forget, until Devuan Devs get around to making the runit > package a genuine PID1, you can, right now, today, run runit on top of > sysvinit, and one by one switch services from /etc/rc.d/init.d scripts > to runit run scripts, by shutting off the service on the sysvinit end, > and downloading or making a runit run script and then making one > symlink. > > A lot of run scripts are available at > http://smarden.org/runit/runscripts.htm . I will be curating a > collection of more runit run scripts in the near future. > > In other words, unless you view sysvinit as an antique to be kept > around for sentimental value, don't put any work into it. Drive it > while it fits your needs, then call the tow truck to tow it away and > get your bra
Re: [DNG] Stop the madness!
On Fri, Oct 19, 2018 at 09:55:31PM -0400, Steve Litt wrote: > Some folks are asking for automatic sysvinit init script generation, or > else unit file to sysvinit init script converters. Some are asking > Devuan's developers to prioritize their scarce programmer resources to > modifying sysvinit, which is over 30 years old. Yet others think we > should reimplement all the systemd functions in the Unix paradigm. > > Stop the madness! Dear Steve, I understand your frustration, and I share most of it, but I can't see anything wrong with discussing the possibility of generating initscripts from existing unit files (which is something that, at least in part, already exists [0]). I personally like the ideas behind process managers like runit (I have also had a look at shepherd, for instance), but if you want it to happen in Devuan somebody should work on it and make it real. And now is a good time to do that, since Beowulf is in the making. Unfortunately, pointing to a bunch of scripts is not enough: you need somebody who has experience of using runit who is willing to package the whole stuff in a coherent way, IMHO. My2Cents KatolaZ [0] https://github.com/akhilvij/systemd-to-sysvinit-converter -- [ ~.,_ 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
