Re: [DNG] Runit for Devuan: was Debian testing drop redis
Runlevels are one of those features that are hugely useful when doing development work, and useless almost everywhere else. When I wasn't doing dev work I only use the default and S runlevels (or equivalent). On 05/28/2018 05:00 PM, Steve Litt wrote: On Mon, 28 May 2018 17:36:33 +0300 mobinmob wrote: On 28/05/2018 08:54 πμ, aitor wrote: As i said in a recent thread, you can shutdown/reboot doing (it requires granted permissions): runit-init 0 runit-init 6 I'm working on a logout dialog for runit with suid permissions. Cheers, Aitor. You may want to look at the relevant utilities in void: https://github.com/voidlinux/void-runit I use Void's runit every day (and the PID1 once every 5 to 30 days when I reboot. I have the distinct impression that the Void folks made Runit more complicated than it needs to be. In an effort to kinda-sorta implement something like "runlevels" (which I never saw value in anyway), they have symlinks to symlinks, to the point that it's hard to know where the real file is. This becomes a problem for me, when I need to figure out exactly where to put the one needed symlink (the one in the service directory) when I add a daemon. So if anyone comes away from Void thinking runit is complex, well, it *can* be but doesn't need to be. SteveT Steve Litt June 2018 featured book: Twenty Eight Tales of Troubleshooting http://www.troubleshooters.com/28 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Intel fixes new microcode license
I like it, very simple. It looks like they are serious about getting these updates deployed. On 08/23/2018 01:15 PM, Bruce Perens wrote: The new license is here: https://t.co/x5JByIv3j9 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] GPL version 2 is a bare license. Recind. (Regarding (future) linux Code of Conduct Bannings).
On 09/17/2018 07:26 PM, goli...@dyne.org wrote: Didn't Linus self-eject himself? I read your response (which should never have had to be written) to Linus' post. Well done!! It will be interesting to see how his absence affects the kernel. If it goes where I suspect it might, I wonder whether there will be another fork in Devuan's future. Short translation of Linus's letter to the list: Gee, I've been being a bigger ass than I thought and driving away people I really want contributing. I'm going to take a break and get some training in how not to be such an ass, BRB and try to be nicer to each other! As a former kernel developer myself, this is probably overall a good thing. The new Code of Conduct is also nothing particularly special, as even in the '90's there were many *heated* discussions where it wouldn't have been broken by any of the participants. -- Dan ___ 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 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 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] The D in Systemd stands for 'Dammmmit!'
On 10/27/18 2:38 PM, Steve Litt wrote:
On Sat, 27 Oct 2018 14:24:22 +0200
info at smallinnovations dot nl wrote:
Not my words although i agree fully with them:
https://www.theregister.co.uk/2018/10/26/systemd_dhcpv6_rce/
"The overflow can be triggered relatively easy by advertising a DHCPv6
server with a server-id >= 493 characters long," Wilhelm noted.
They say: You must use systemd because sysvinit is soo old.
I say: You must use strncpy()/strncat() because strcpy()/strcat() are
soo old.
What's it been now, 30 years since the strn versions of those
commands have been around? You'd think they'd have taken that in and
adopted it by now. But no!
My first thought: you're kidding.
My second thought: what if they're not kidding?
My third thought: let's look...
dtaylor@boti:~/src/systemd$ find . -type f -exec grep -il strcat {} \;
./src/basic/unit-name.c
dtaylor@boti:~/src/systemd$ find . -type f -exec grep -il strcpy {} \;
./src/nss-mymachines/nss-mymachines.c
./src/libsystemd/sd-bus/test-bus-marshal.c
./src/libsystemd/sd-bus/bus-internal.h
./src/time-wait-sync/time-wait-sync.c
./src/nss-systemd/nss-systemd.c
./src/network/networkd-ndisc.c
./src/network/networkd-network.c
./src/portable/portable.c
./src/shared/import-util.c
./src/shared/dissect-image.c
./src/shared/bus-unit-util.c
./src/shared/clean-ipc.c
./src/shared/firewall-util.c
./src/machine/machinectl.c
./src/basic/time-util.c
./src/basic/khash.c
./src/basic/escape.c
./src/basic/json.c
./src/basic/path-util.h
./src/basic/cap-list.c
./src/basic/cgroup-util.c
./src/basic/path-util.c
./src/basic/fileio.c
./src/basic/unit-name.c
./src/core/automount.c
./src/core/manager.c
./src/core/dbus-execute.c
./src/core/dynamic-user.c
./src/boot/efi/boot.c
./src/journal/catalog.c
./src/journal/journald-audit.c
./src/resolve/resolved-dns-rr.c
./src/test/test-unit-file.c
./src/test/test-condition.c
./src/udev/scsi_id/scsi_serial.c
./src/udev/scsi_id/scsi_id.c
./src/udev/udev-ctrl.c
--
Daniel Taylor
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The D in Systemd stands for 'Dammmmit!'
On 10/29/18 2:59 PM, Rick Moen wrote: FWIW, strncpy()/strncat() were a huge advance over strcpy()/strcat(), but also have their own problems: https://blog.liw.fi/posts/strncpy/ https://www.reddit.com/r/programming/comments/ifje6/strncpy_just_say_no/ They do, but that's not an excuse for using strcpy(). Which they did. Author Lars Wirzenius (one of our Linux tribal elders!) recommends instead snprintf (but it has the problem of being slower than alternatives), or, better in his eyes, using a well-written helper library instead. (Lots more opinions at the Reddit thread.) Helper libraries are awesome, as long as they are also well written. -- Daniel Taylor ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 11/16/18 4:42 PM, Rick Moen wrote: Quoting Steve Litt (sl...@troubleshooters.com): What *I'm* talking about is I want to continue having /sbin separate from /bin and /usr/bin, because the /sbin varieties holds statically compiled programs guaranteed to work at the earliest of boots, and in the case of /sbin, guaranteed to be available as soon as / is mounted. Steve, I'm not sure where you arrived at the notion that binaries in /sbin should be expected to be, or necessarily ought to be, static binaries. I'm not aware of any such norm. (Compiling static is a crude but certainly effective way to end some dependency issues, but not necessarily desirable.) In case you were not aware (and absolutely no condescension intended if you were already well aware of this), the 's' in 'sbin' signifies 'normally needed only by the superuser'. It doesn't signify static. I thought it was "system", but I don't even know who originated the separation. It certainly precedes Linux. As for the "statically linked binaries in /sbin", that may come from the (formerly?) common practice of having all the binaries needed for system startup statically linked in case something happened to /lib. It's scary how unreliable our systems used to be compared to now. -- Daniel Taylor ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] calendars, contacts, to do lists
On 5/23/19 5:12 PM, Steve Litt wrote: * I don't want to depend on Google's calendar services, but I'd like to be able to use them to coordinate with other people who do. My software doesn't and never will coordinate with middlemen like Google. I'm sure you could write software that acts as a bridge between my software (or somebody else's software) and Google calendar services. Better also provide some sort of backup facility for the data stored on Google: They have no real incentive to keep your data intact. Unfortunately, for many of us this is the cost of living in the world. To coordinate with people I care about I need to sync not just with Google, but with FB. The latter I do manually, and with great reluctance and no JS, but it still needs to happen. Because people are more important than protocols (or pride). -- Dan ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Where to reply for Steve Litt
On 5/23/19 6:21 PM, Rick Moen wrote: Quoting Steve Litt (sl...@troubleshooters.com): Hi all, All: OH HAI! There's been some discussion about whom to reply to. I guess it's a personal preference, and my personal preference is described in the remainder of this email... If you want to reply to me, on-list, please reply to the list only. You can ask, but it's mostly futile because most people's software doesn't handle mailing lists intelligently. Exceptions include mutt (which I use) and emacs GNUS. Both of those have a (configurable) ability to do list-mode replying, in which the MUA trims out non-mailing-list addresses, whenever the user does a group reply that includes a mailing list address. (I'm being a bit inexact. The details are IMO not worth detail-freaking to death.) Shockingly enough Thunderbird isn't half bad. There are a lot of bad mail clients out there, though. -- Dan ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
