Re: [DNG] Devuan + remote desktop of Ubuntu = how?
On 17-10-18 13:19, Miroslav Skoric wrote: > Hi all, > > I recently installed Devuan Jessie on a computer for presentations via > large TV. And that machine is also directly wired in a small LAN to > another box that runs some old Ubuntu (probably 12.04 or so, it is > also just to tell the audience what Linux is about). Machines can ping > each other now, so besides introducing Devuan, I also want to > introduce Ubuntu via Devuan by some kind of remote GUI access or like. > Suggestions? Please note that there is no Internet access to those > boxes, so anything needed for each comp must be downloaded elsewhere > and brought on USB or CD. > > Misko Hi Misko, The easiest way would be to make a connection with ssh -X or -Y which enables X-forwarding. You then can start a individual X program from the commandline but also the complete WM. Perfectly showing how capable linux is in use. For more extended capabilities you could install x2go server and client which will also make possible to have more then one remote desktop. 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
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: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] Weird network issue - slow to resolve IPs [solved]
On Wed, 17 Oct 2018 11:31:41 -0500, goli...@dyne.org wrote in message : > On 2018-10-15 22:22, mett wrote: > > On 2018年10月16日 11:16:30 JST, goli...@dyne.org wrote: > >>> On Sat, Oct 13, 2018 at 05:30:56PM -0500, goli...@dyne.org wrote > >>> > >> It is incredibly annoying to be connected to a rather fast pipe yet > >> have > >> to travel on what feels like 56k connection to get to where I can > >> benefit from it. > >>> > >>> golinux > >>> > >> > >> With help from my Devuan friends the connection times have improved > >> significantly. After little poking around and a very interesting > >> talk with my ISP, I decided that the ISP's DNS resolver was > >> contributing significantly to the slow connection times. A > >> suggestion from a Devuan ninja, encouraged me install unbound. I > >> was instructed to put the IP in > >> > >> /etc/resolv.conf and to enable the prepend (I can't remember > >> exactly where). Now my connection times are mostly pretty snappy. > >> > >> This has been an interesting, informative thread and I appreciate > >> everyone who shared their thoughts. > >> > >> Till next time, > >> > >> golinux > >> > > > > Hi, > > > > By the way, > > that means that was not some > > No-Net-Neutrality's effect > > if I understand correctly. > > > > Can't say for sure. Wouldn't Comcast/Spectrum/RoadRunner(TWC) be able > to throttle traffic more effectively using their in-house DNS > service? Maybe unbound escapes their reach? ..any difference running with and without Tor? > Just speculating here > because as everyone has gathered, I am pretty clueless about the > finer points of networking. ..is what much too easily happens, when things just work. :o) > I had no idea when I started this thread that it would turn into such > an informative monster. The collective wealth of knowledge on this > list is stunning. While most of it is way over my head, I have > picked up a few things and now have plenty of references if I get > whacked again by a network issue. Again, thanks to all. > > golinux -- ..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 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 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: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] Weird network issue - slow to resolve IPs [solved]
On 2018-10-15 22:22, mett wrote: On 2018年10月16日 11:16:30 JST, goli...@dyne.org wrote: On Sat, Oct 13, 2018 at 05:30:56PM -0500, goli...@dyne.org wrote It is incredibly annoying to be connected to a rather fast pipe yet have to travel on what feels like 56k connection to get to where I can benefit from it. golinux With help from my Devuan friends the connection times have improved significantly. After little poking around and a very interesting talk with my ISP, I decided that the ISP's DNS resolver was contributing significantly to the slow connection times. A suggestion from a Devuan ninja, encouraged me install unbound. I was instructed to put the IP in /etc/resolv.conf and to enable the prepend (I can't remember exactly where). Now my connection times are mostly pretty snappy. This has been an interesting, informative thread and I appreciate everyone who shared their thoughts. Till next time, golinux Hi, By the way, that means that was not some No-Net-Neutrality's effect if I understand correctly. Can't say for sure. Wouldn't Comcast/Spectrum/RoadRunner(TWC) be able to throttle traffic more effectively using their in-house DNS service? Maybe unbound escapes their reach? Just speculating here because as everyone has gathered, I am pretty clueless about the finer points of networking. I had no idea when I started this thread that it would turn into such an informative monster. The collective wealth of knowledge on this list is stunning. While most of it is way over my head, I have picked up a few things and now have plenty of references if I get whacked again by a network issue. Again, thanks to all. golinux ___ 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
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 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] Weird network issue - slow to resolve IPs [solved]
Quoting Steve Litt (sl...@troubleshooters.com): > I just got thru updating my unbound doc at > http://troubleshooters.com/linux/unbound_nsd/unbound.htm , and added a > new glossary. This is very necessary because there are so many > contradictory terms for things over the Internet. I'm not saying my > glossary is the most accurate resource on the Internet, but I think my > glossary probably does the best job of de-contradicting terms people > throw around. I spent three weeks writing this glossary. It was one of > the toughest docs I ever wrote: Tougher than any one chapter in Samba > Unleashed. I sympathise with you needing to do all of that painstaking work, Steve. In the glossary, you take particular pains to declare bogus for purposes of your guide the phrase 'iterative server' and similar. But I cannot recall seeing that phrase, so I'm unclear on why you needed to say that. In my 'Village of LAN' piece, I speak in one of the examples about 'a nameserver offering iterative service only', and in several other places use the subphrase 'iterative service' -- clarified elsewhere in the piece in contrast to recursive service. But it would not have occurred to me to use the odd phrase 'iterative server'. It's not the _server_ that iterates, but rather the query, for lack of ability to send back an answer properly with the RA = Recursion Available bit set when sent a query with the RD = Recursion Desired bit set. My point is, you seem to be walking the long way around a pothole that wasn't actually there to fall into. IMO. Although I don't share your desire to use the word 'resolver' in the way your document does -- because in context it ends up creating too much confusion -- you're of course correct that that usage is observed in DNS discussion. And that reflects, as you say, there being too many decades of sloppy and gradually changing terminology. I don't _think_ that problem's as bad as you suggest, but it's definitely present. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan + remote desktop of Ubuntu = how?
On Wed, Oct 17, 2018 at 05:14:52PM +0200, info at smallinnovations dot nl wrote: > On 17-10-18 13:19, Miroslav Skoric wrote: > > Hi all, > > > > I recently installed Devuan Jessie on a computer for presentations via > > large TV. And that machine is also directly wired in a small LAN to > > another box that runs some old Ubuntu (probably 12.04 or so, it is > > also just to tell the audience what Linux is about). Machines can ping > > each other now, so besides introducing Devuan, I also want to > > introduce Ubuntu via Devuan by some kind of remote GUI access or like. > > Suggestions? Please note that there is no Internet access to those > > boxes, so anything needed for each comp must be downloaded elsewhere > > and brought on USB or CD. > > > > Misko > > > Hi Misko, > > The easiest way would be to make a connection with ssh -X or -Y which > enables X-forwarding. You then can start a individual X program from the > commandline but also the complete WM. Perfectly showing how capable > linux is in use. For more extended capabilities you could install x2go > server and client which will also make possible to have more then one > remote desktop. You may end up with network delays for systems that are designed with the speed of a local video display in mind. -- 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
> ..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 + remote desktop of Ubuntu = how?
Quoting info at smallinnovations dot nl (i...@smallinnovations.nl): > The easiest way would be to make a connection with ssh -X or -Y which > enables X-forwarding. You then can start a individual X program from the > commandline but also the complete WM. Perfectly showing how capable > linux is in use. For more extended capabilities you could install x2go > server and client which will also make possible to have more then one > remote desktop. I _try_ to keep up with the remote-imaging options, here: http://linuxmafia.com/faq/Legacy_Microsoft/vnc-and-similar.html (This area seems to be constantly changing.) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs
On 10/14/18 12:45 AM, goli...@dyne.org wrote: On 2018-10-14 01:52, Rick Moen wrote: Anyhow, it can be vital to know _what_ server is answering (well or otherwise) your system's DNS questions by default. Looking at /etc/resolv.conf should answer that question. I don't have anything in /etc/resolvconf except an avahi-daemon in /update-libc.d/ Maybe I should start by putting 8.8.8.8 in /etc/resolvconf? And OT do I even need avahi installed at all? avahi-daemon is a systemd package, when I see it running I turn it off and suffer no ill effect. If you do not have systemd installed it can not turn avahi-daemon back on, but I'm still testing that in devuan. It's sewn into a lot of packages, can control both audio and video without any help from you., Got a web-cam? Click., Got a mic?, with systemd installed your ass is grass because it can do what ever it wants to do and you can't do anything about it, don't believe me take a look at debian systemd bugs, there are hundreds of them and the bad bugs tell you that systemd does what ever the F*** it wants to do and as far as I can see does the user absolutely no good. But if you do have it installed and disconnect from the internet the kernel will call avahi to bring the internet up and it will. I don't like that and is why I stopped the avahi-daemon. But that's not all, when the kernel sees avahi is not running it binds with the NIC and ask for a HTTP address and that is where my firewall stops it. At least devuan is able to log these things, with system log I can see every system reaction to what I do and systemd packages do not like what I do, a perfect system would never have systemd packages or watered down security. OK. I am a complete idiot and ignored the dot in the filename so didn't even see the resolv.conf file. This is what's in it: domain austin.rr.com search austin.rr.com nameserver 209.18.47.62 nameserver 209.18.47.61 I would really like to change the DNS service. And those RR search pages are really annoying and useless. === I have my own way to set up the internet, so can't help you there, but will tell you recently youtube was down and quite a few experienced computer users thought their compute was broke, that's google if you did not know, here it made the morning news, but I already knew about it. Apologies for the confusion. Bedtime for me . . . I'm up at anytime and asleep at anytime, installing and configuring computers for a user is what I do. Do you think Debian will ever admit to making a BIG F* mistake? Or just let the evidence keep piling up and do nothing about it, the oldest systemd bug goes back 7 years and 214 days ago and it's still not fixed, seriously does that sound like Debian?, When they found the watered down encryption, at that time I don't think most developers realized that it is by design and is why devuan needs it own security including its own kernel. All I can do is test. -- Jimmy Johnson Slackware64 Current - KDE 4.14.38 - AMD A8-7600 - EXT4 at sda9 Registered Linux User #380263 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] who is working for who (was Avahi (was Weird network issue))
On Tue, 16 Oct 2018 22:37:57 -0700 Rick Moen wrote: > (I continually find myself making the point on Dng that the quest > for universal solutions may be noble in its aims but will never > really succeed very well.) The preceding is what I've been trying to say for years, but didn't have the language to say it nearly as succinctly. Thank you! I'd like to add (because I'm not as succinct as you) that by covering every corner case, you add complexification containing its own corner cases, which you must solve with more complexification, ... What I like about runit (and s6) is that its very architecture makes solving problems almost trivial, so little complexification is necessary. 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 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 + remote desktop of Ubuntu = how?
Quoting Bruce Ferrell (bferr...@baywinds.org): > For Linux stuff I've become somewhat fond of X2go Yes, X2Go's really good -- delivering on the promise of FreenX (now unmaintained) to greatly improve on the performance delivery of VNC/RFP and RDP. -- Cheers, Mia kusenveturilo estas plena da angiloj. Rick Moen r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs [solved]
Quoting goli...@dyne.org (goli...@dyne.org): > Can't say for sure. Wouldn't Comcast/Spectrum/RoadRunner(TWC) be > able to throttle traffic more effectively using their in-house DNS > service? Maybe unbound escapes their reach? I don't think this is likely for various reasons including the fact that traffic throttling that can be evaded just by using a non-default DNS nameserver is excessively feeble traffic throttling. On available evidence, although there might have been multiple sources of badness for all I know, you had at least _one_ identifiable problem source in the form of really bad ISP DNS nameservers. (As I think I've already said, this is about the opposite of surprising, to yr. humble servant. ;-> ) We can have fairly high confidence in the foregoing for the simple reason of that badness having gone away when you swapped in Unbound. If I were charged with doing traffic throttling at, say, an ISP, I would do it with iptables/netfilter or equivalent, i.e., at a lower level in the network stack than where DNS operates. (I won't torture you with the '7 layer burrito' speech infamous among all junior sysadmins and aspiring network engineers, who are obliged to commit to memory the OSI Reference Model before interviewing for jobs. https://www.6connect.com/blog/moment-internet-history-osi-7-layer-burrito/ ) ___ 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] dig vs nslookup: was Weird network issue - slow to resolve IPs
On Wed, 17 Oct 2018 17:32:50 +1100 wirelessd...@gmail.com wrote: > > On 17 Oct 2018, at 15:58, Steve Litt > > wrote: > > > > What's your opinion of nslookup as an alternative to dig? Not sure, > > but I think you need to install bind to get dig, and not everyone > > wants to install bind. > > Since looking at Unbound and NSD, I’ve been trying out drill as an > alternative developed by the same NLnet people. > > https://www.nlnetlabs.nl/projects/ldns/about/ > > Install via the ldnsutils package. Very nice! I just installed it and will start using it. 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] Weird network issue - slow to resolve IPs [solved]
Hi, Steve! On 17/10/18 at 07:34, Steve Litt wrote: > Yes, yes, yes, yes, YES! > I just got thru updating my unbound doc at > http://troubleshooters.com/linux/unbound_nsd/unbound.htm , and added a > new glossary. i noticed a couple of lines are missing in the reverse-zone definitions of the private IP address blocks: > * 10.in-addr.arpa. > * 168.192.in-addr.arpa. > * 17.172.in-addr.arpa. > * 18.172.in-addr.arpa. > * 20.172.in-addr.arpa. > * 21.172.in-addr.arpa. > * 22.172.in-addr.arpa. > * 23.172.in-addr.arpa. > * 24.172.in-addr.arpa. > * 25.172.in-addr.arpa. > * 26.172.in-addr.arpa. > * 27.172.in-addr.arpa. > * 28.172.in-addr.arpa. > * 29.172.in-addr.arpa. > * 30.172.in-addr.arpa. > * 31.172.in-addr.arpa. > You might add the 16.172.in-addr.arpa. and 19.172.in-addr.arpa. zones, too. Good work, thank you! -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE 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
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] dig vs nslookup: was Weird network issue - slow to resolve IPs
Quoting wirelessd...@gmail.com (wirelessd...@gmail.com): > Since looking at Unbound and NSD, I’ve been trying out drill as an > alternative developed by the same NLnet people. > > https://www.nlnetlabs.nl/projects/ldns/about/ > > Install via the ldnsutils package. 'drill' is the very newest such tool, having advantages over the others concerning DNSSEC in particular. It's also claimed to be super-fast on account of relying on the ldns library. But the main point is DNSSEC support. I was trying to remember the name of the thing during the upthread discussion, and couldn't quite remember it. All I could remember that it was some variation on the concept of digging. Which, in a way, underlines one of the real-world reasons we-generic tend to stick with tools: familiarity. ;-> (I resisted the migration from nslookup to dig for a while, two decades ago, because my fingers' muscle-memory and my mind's habits knew all about how to use nslookup. It was annoying to start over with 'dig'.) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] who is working for who (was Avahi (was Weird network issue))
On 16.10.18 22:53, Bruce Ferrell wrote: > > For real fun, turn on Avahi along with all the pulse audio stuff. > > Watch your network get flooded with multi-cast audio. > > Scramble to shut it down as fast as you can. Errrm, devuan ascii is running both of those OOTB. On another current thread, I've asked what might replace pulseaudio, as it appears to suffer usability problems. OTOH, "aptitude why avahi-daemon" merely shows: i task-desktop Recommends avahi-daemon so there should be no cost to purging that, I figure. Erik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] dig vs nslookup: was Weird network issue - slow to resolve IPs
> On 17 Oct 2018, at 15:58, Steve Litt wrote: > > What's your opinion of nslookup as an alternative to dig? Not sure, but > I think you need to install bind to get dig, and not everyone wants to > install bind. Since looking at Unbound and NSD, I’ve been trying out drill as an alternative developed by the same NLnet people. https://www.nlnetlabs.nl/projects/ldns/about/ Install via the ldnsutils package. —Tom___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] who is working for who (was Avahi (was Weird network issue))
On Tue, Oct 16, 2018 at 10:37:57PM -0700, Rick Moen wrote: > > > So it comes down to a) try to kill the chatty discovery protocols and > > perpetuate the "geeks vs users" divide > > Was there a particular part of 'not on _my_ network' that was unclear? Maybe we need discovery protocols that are less chatty. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Devuan + remote desktop of Ubuntu = how?
Hi all, I recently installed Devuan Jessie on a computer for presentations via large TV. And that machine is also directly wired in a small LAN to another box that runs some old Ubuntu (probably 12.04 or so, it is also just to tell the audience what Linux is about). Machines can ping each other now, so besides introducing Devuan, I also want to introduce Ubuntu via Devuan by some kind of remote GUI access or like. Suggestions? Please note that there is no Internet access to those boxes, so anything needed for each comp must be downloaded elsewhere and brought on USB or CD. Misko ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] automatic init script generation
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 ___ 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
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 + remote desktop of Ubuntu = how?
On Wed, 17 Oct 2018 13:19:33 +0200 Miroslav Skoric wrote: > Hi all, > > I recently installed Devuan Jessie on a computer for presentations > via large TV. And that machine is also directly wired in a small LAN > to another box that runs some old Ubuntu (probably 12.04 or so, it is > also just to tell the audience what Linux is about). Stop there and do not bother about the second machine*. Linux is linux, Distros are just a choice about how you want to manage your computers. FWIW, I just tell people to go with ever distro they can get support for. As far as I know, just about every distro can support various desktop systems for the various look and feel buzziness. If you have the resources, perhaps a few print out of the various desktops made before hand In my experience, people really want to know what they can do with it, so you run through the various applications under each need, e.g; Browsers; firefox, chrome, epihany, quickzilla, etc down to lynx(?) Various mailers, Word processors like libre office, etc. Point out that linux WPs have always featured interchange of documents and can pump out pdfs, docs, etc. Do multimedia like VLC, the various mixers. Is there some common need that you can show specialist programs for? I run IceWM(?) and a righ click-> applications -> subject-area shows a list f the various applications that my system has installed, whether it is >Accessories >Crossover >devlopment >Education >Games >Graphics etc, etc, >Office >System >Other >Wine * In 1999, a couple of us from our LUG got word that due to a booking drop out, we could have a double stall at the then major annual IT in Sydney. We worked our but off to build stands and put together six different machines to show six different distros and all people wanted to know was what they could do on Linux. Everyone loved suddenly having access to all these "free" applications that could do so much. Whereas before you were always reaching into your pocket for limited use. >Machines can > ping each other now, so besides introducing Devuan, I also want to > introduce Ubuntu via Devuan by some kind of remote GUI access or > like. Suggestions? Please note that there is no Internet access to > those boxes, so anything needed for each comp must be downloaded > elsewhere and brought on USB or CD. Burn the basic DVD and do the installation from it and if you have it on hand, you can show how easily the computer can acquire other applications by; 0) open a terminal b) aptitude search some application (or hint utility). c)sudo aptitude install chosen-utility. d) utility. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support
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
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] who is working for who (was Avahi (was Weird network issue))
On Tue, Oct 16, 2018 at 10:53:07PM -0700, Bruce Ferrell wrote: > For real fun, turn on Avahi along with all the pulse audio stuff. > > Watch your network get flooded with multi-cast audio. Flooded? I'm sorry, but does you network is built over 33,6kbs modems? Have you lost the perspective? -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
