Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal
El 22/08/17 a les 02:48, Alessandro Selli ha escrit: > On Mon, 21 Aug 2017 at 10:32:43 +0200 > Narcis Garcia wrote: > > [...] > >> This logic does not guarantee 100% predictable naming (think about >> removable NICs), but gives enough confort to a sysadmin deals any with >> situation. > > If it's not 100% predictable and configurable by the sysadmin then it does > *not* provide "enough confort", as in an Enterprise environment this means > 100% certainty that the system comes up with each networking card having > a definite, assigned name and that everything that depends on networking is > always going to work fine short of a hardware failure. > Randomness is very unwelcome in critical systems and in data centers, where > even a tiny percentage of random malfunction has to be multiplied by the > numer of racks and devices that are present to be deemed acceptable. > > > Alessandro Please, differenciate between predictable name and definitive name. persistent-net.rules allows 100% definitive names. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new behaviour of /dev
Le 22/08/2017 à 01:27, Adam Borowski a écrit : Hi! Do you remember when for decades we had to populate /dev using mknod (using makedev or something) -- both on Linux and on Unices that predated it? Then when udev came to make device creation dynamic. I just installed a new server, not using d-i but manual debootstrap. Not even regular debootstrap but with --variant=minbase as --exclude is still buggy and fails to exclude THE THING THAT SHOULDN'T BE NAMED. Everything worked fine, except for one detail: somehow /dev/ttyUSB* were mode 600 root:root instead of 660 root:dialout. Turns out, udev was not installed. Nor mdev, nothing. No initrd either. Yet it boots and works correctly. fstab has no entries except for / -- and even this is pointless if you mount rootfs rw on cmdline (the ro + remount dance does nothing good on any modern fs other than ext4). If there was any userland configuration, it is done by openrc by default. Hotplugging USB devices seems to work fine, new nodes get created without udev's involvement. Obviously, I guess running without udev is a bad idea in the long run -- you want correct permissions to get applied, hotplug hooks to be run, etc. But this suggests 90% of udev/mdev/vdev code can be thrown out. That the kernel can now do most of this work by itself is news to me. This is the result of enabling devtmpfs when building the kernel. Devtmpfs was implemented a few years ago and is, in my opinion, a reaction of the bad behaviour of Udev developpers. For the same reason (explicitely), the kernel now loads the firmware automatically instead of requesting it to the hotplugger. Definitely, the hotplugger has less and less to do, and, definitely, I think Mdev could do it pretty well. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] An alternative to renaming [was Re: Proposed change in behaviour for ascii: eudev net.ifnames]
Le 22/08/2017 à 03:38, Adam Borowski a écrit : Per the other thread, the only thing you need udev/mdev for anymore is setting permissions and calling hooks. Don't tell me that udev is a "big price" on any machine bigger than a microcontroller these days. The price of depending on Udev-Systemd and Dbus. The price of not being assured of the future of Eudev and of Vdev. The price of the complexity of all these. You might have missed the context. We were talking about how to ensure that Xorg works with mdev, rather than udev. But why? mdev is not meant to be used beyond an initramfs, it can't do hotplug, and on modern Linux coldplug is almost entirely done via hotplug -- with shit happening if your software can't take a device which took a while to start. What makes you think it should be restricted to initramfs? For sure it was meant to have a small footprint and small resource usage, but I don't think it sacrifies any functionality, except it lacks the equivalent of libudev, which library seems to be used only by Udev itself and Xorg. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal
Le 22/08/2017 à 09:10, Narcis Garcia a écrit : persistent-net.rules allows 100% definitive names. Definitive but with a possible mess. A new eth1 could be created by the kernel in the same time eth0 is renamed to eth1 by Udev. The race problem pointed by Adam. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] An alternative to renaming [was Re: Proposed change in behaviour for ascii: eudev net.ifnames]
On Tue, 22 Aug 2017 03:38:50 +0200, Adam wrote in message <20170822013850.ute5cf7ycrlvc...@angband.pl>: > There are cases when the old way had its merit -- but here, we have an > equivalent of a car that needs to be started with a hand-crank. ..you may have missed "Brave New World" by Aldous Huxley and George Orwell's "1984", or at the very least, the main point of these 2 books and your own nation's history, in these Trumpian times. ..an hand-crank car keeps you in control of what's going on around you, if you pay attention. Your new shiny AI car may decide to kill you to save e.g. "a more worthy person" from something really, really bad, e.g. Trumpian embarrasment, e.g. because you pay attention to what's going on around you. ;oD -- ..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
[DNG] Doedn't the NIC name issue already have a solution?
On Tue, Aug 22, 2017 at 12:48:53PM +1200, Daniel Reurich wrote: > > That said in most cases where I have 2 or 3 interfaces it's generally > been firewall/routers or Virtualisation Hosts in which case I always > install ifrename and use an /etc/iftab to give a more purposeful name to > the interfaces. > You mean the solution to this problem already exists? But not installed by default? Is there some reason for using this? -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] An alternative to renaming [was Re: Proposed change in behaviour for ascii: eudev net.ifnames]
On Tue, Aug 22, 2017 at 01:08:25AM +0200, Adam Borowski wrote: > > Manually creating the configuration -- or even manually triggering its > creation -- is a pretty bad idea. It just guarantees you won't have working > X when you make any change to your hardware -- and sometimes software as > well. In the old days, this was exactly what you always had to do. I had to manually calculate all the timing numbers from hints privided by the monitor documentation (usually hidden in the advertising blurb on the box the monitor came in), having been warned that if I got them wrong I could destroy the monitor. That was in the old days, when momitors didn't have much to say to computers. THe current situation is just dreamy by comparison. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] An alternative to renaming [was Re: Proposed change in behaviour for ascii: eudev net.ifnames]
On Mon, Aug 21, 2017 at 03:52:44PM +0200, Didier Kryn wrote: > > Note that a similar problem with disks has been solved elegantly by > referencing disks by their uuid or label in /etc/fstab. Maybe > /etc/network/interface could specify the MAC address as a hook. This would > only suppose that the hotplugger creates a symlink to the interface in some > /dev/net/by-address/ subdirectory. With this solution, it is up to the admin > to decide if s?he wants a simple configuration based on interface name > (eth0) or a secured one alla "Address=a0:d3:c1:9d:a5:86". It turns out that something like this already exists. The ifrename command renames interfaces using a /etc/iftab file. But it is not installed by default. Ifrename must be run before interfaces are brought up, So it seems to be something that has to be used during init or hotplugging. Is it a systemdism? -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FWIW fixed :: network down after ASCII upgrades
On 08/21/2017 10:07 PM, Gary Olzeke wrote: > Haven't been on my ascii setup for a week or so. > so I did the 'update & 'upgrade routine > installed these upgrades:: [see below] > > ' > did a reboot and lost my network connection. > ifconfig isn't available anymore (am I getting old?!) > ip was too confusing to me > ' My first guess is that the network names changed. Like you, I'd use ifconfig to check them. It is still available, but it's not installed by default. Install the net-tools package to get it. > ended up doing this: > sudo bash /etc/network/if-up.d/upstart .(ethtool script didn't help??) > ' That won't do anything unless you're using upstart as your init system, and there's no version of upstart in ascii. fsmithred ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] An alternative to renaming [was Re: Proposed change in behaviour for ascii: eudev net.ifnames]
On Tue, 22 Aug 2017 09:09:11 -0400 Hendrik Boom wrote: > On Mon, Aug 21, 2017 at 03:52:44PM +0200, Didier Kryn wrote: > > > > Note that a similar problem with disks has been solved > > elegantly by referencing disks by their uuid or label > > in /etc/fstab. Maybe /etc/network/interface could specify the MAC > > address as a hook. This would only suppose that the hotplugger > > creates a symlink to the interface in some /dev/net/by-address/ > > subdirectory. With this solution, it is up to the admin to decide > > if s?he wants a simple configuration based on interface name > > (eth0) or a secured one alla "Address=a0:d3:c1:9d:a5:86". > > It turns out that something like this already exists. The ifrename > command renames interfaces using a /etc/iftab file. But it is not > installed by default. > > Ifrename must be run before interfaces are brought up, > > So it seems to be something that has to be used during init or > hotplugging. > > Is it a systemdism? > > -- hendrik No, it seems to have been about since at least 2006: http://www.enterprisenetworkingplanet.com/netos/article.php/3586546/Nail-Down-Network-Interface-Names-with-ifrename.htm Rowland ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new behaviour of /dev
Quoting Didier Kryn (k...@in2p3.fr): > This is the result of enabling devtmpfs when building the > kernel. Devtmpfs was implemented a few years ago and is, in my > opinion, a reaction to the bad behaviour of Udev developers. Plausible. > For the same reason (explicitly), the kernel now loads the firmware > automatically instead of requesting it to the hotplugger. And this _definitely_ seemed to be a reaction to systemd/udev developers' bad behaviour. I [half-]remember when it happened; it was a reaction to a specific bit of coder insanity, maybe that kdbus episode? > Definitely, the hotplugger has less and less to do, and, definitely, > I think Mdev could do it pretty well. And simply. You just create a custom hotplug handler script /sbin/hotplug (the default value of /proc/sys/kernel/hotplug as decreed in the kernel configuration) like this: #!/bin/sh test -n "$MODALIAS" && modprobe "$MODALIAS"; exec /sbin/mdev However, for my own needs, I personally favour just compiling needed drivers into the Linux kernel monolithically. (Yes, average desktop user cannot be expected..., blah, blah, blah.) I really don't know why so many people think hotplugging is a major need, anyway. I happily used Linux for a very long time before it existed. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] FWIW fixed :: network down after ASCII upgrades
I am on ASCII but there were no device renaming; wlan0 is still wlan0. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] An alternative to renaming [was Re: Proposed change in behaviour for ascii: eudev net.ifnames]
Le 22/08/2017 à 15:09, Hendrik Boom a écrit : Note that a similar problem with disks has been solved elegantly by referencing disks by their uuid or label in /etc/fstab. Maybe /etc/network/interface could specify the MAC address as a hook. This would only suppose that the hotplugger creates a symlink to the interface in some /dev/net/by-address/ subdirectory. With this solution, it is up to the admin to decide if s?he wants a simple configuration based on interface name (eth0) or a secured one alla "Address=a0:d3:c1:9d:a5:86". It turns out that something like this already exists. The ifrename command renames interfaces using a /etc/iftab file. But it is not installed by default. The problem is the rename, because of the race condition. In comparison, here is a citation of the mount man page: The device indication. Most devices are indicated by a file name (of a block special device), like /dev/sda1, but there are other possibilities. For example, in the case of an NFS mount, device may look like knuth.cwi.nl:/dir. It is possible to indicate a block special device using its volume LABEL or UUID (see the -L and -U options below). See the option to use uuid? Mount doesn't require that /dev/sda1 be *renamed*; it just can find the block special device itself, given the uuid. The randomness of disk naming is solved without messing with those names. It doesn't seem a problem to offer a similar option in the ip (or ifconfig) command. The advantage of supporting an option like "hwaddr=a0:d3:c1:9d:a5:86" is that the admin is free to specify interfaces by names or by MAC address. Of course, there is now the possibility to change the MAC address of an interface, but this is a case of severe hacking where the admin has to understand what s?he does. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] An alternative to renaming [was Re: Proposed change in behaviour for ascii: eudev net.ifnames]
Quoting Hendrik Boom (hend...@topoi.pooq.com): > In the old days, this was exactly what you always had to do. I had to > manually calculate all the timing numbers from hints privided by the > monitor documentation (usually hidden in the advertising blurb on the box the > monitor came in), having been warned that if I got them wrong I could > destroy the monitor. Early in the days of multifrequency and then multiscanning monitors, the very cheapest ones omitted protection circuitry, such that if you sent them video signals outside the high and low vertical and horizontal frequency limits, you could if you were very unlucky and rather inept/incautious drive the monitor into burning itself out. (More specifically, you would start X11 up and hear and see sounds of failing to quite sync, and if you were stupid and ignored these clear signs of distress, after half an hour or so of this torture the monitor could fizzle out.) All of the _better_ multifrequency (and, later, multiscanning) monitors such as (at the top end, among many others) the NEC MultiSync series including protection circuitry. (The earliest MultiSyncs were actually in the mid-1980s, very early, but imitators took a while to follow NEC's lead.) Subsequent to that (mid-1990s), all monitors have both included protection circuitry _and_ sent EDID (Extended Display Identification Data) information automatically, declaring the frequencies they can do. ISTR that EDID was one of the accomplishments of the Video Electronics Standards Association (VESA). And then, LED monitors obsoleted tube monitors, and it became impossible even in theory to blow up your monitor, that way. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] opinions and experience with monit
dear DNG'ers on my quest to study more supervision programs for my own use, I've found out (just now!) about monit: https://mmonit.com/monit/ I'm wondering if you have experiences using it and what are your opinions, it seems to me that is a well written, minimal enough addition to sysvlinux when more features are desirable but no entanglement is aloud. is there someone here who knows it / has already experience with it? ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] An alternative to renaming: UUID=MAC
Didier identified the *exact* same problem as was found for block devices (sda, sdb, etc.) and, if UUID/MAC solution worked for that, it must help for this. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] opinions and experience with monit
On 2017-08-22 10:54, Jaromil wrote: dear DNG'ers on my quest to study more supervision programs for my own use, I've found out (just now!) about monit: https://mmonit.com/monit/ I'm wondering if you have experiences using it and what are your opinions, it seems to me that is a well written, minimal enough addition to sysvlinux when more features are desirable but no entanglement is aloud. is there someone here who knows it / has already experience with it? ciao Evilham uses it in conjunction with the mirror status page. I trust his judgment in such things. I do know that Monit sends very nice messages when a mirror goes offline and seems to be quite configurable. I'm answering for him because he won't be back online till tomorrow. Now others with hands-on experience can chime in with their opinions. golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] opinions and experience with monit
On Tue, 22 Aug 2017 at 18:54, Jaromil wrote: > > dear DNG'ers > > on my quest to study more supervision programs for my own use, I've > found out (just now!) about monit: > > https://mmonit.com/monit/ > > I'm wondering if you have experiences using it and what are your > opinions, it seems to me that is a well written, minimal enough > addition to sysvlinux when more features are desirable but no > entanglement is aloud. > > is there someone here who knows it / has already experience with it? > > ciao > I used to use it to restart my crashing tomcat processes. Quite nice, very flexible and does what it promises. I'm not using it anymore because I changed jobs ( ultimate solution for crashing services :) > > -- Sent from Gmail Mobile ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] What does Linus do?
There's a lot of heavy discussion going on in 'Proposed change to ascii' and 'an alternative to renaming' But what does Linus do? How does he think this should play out? I am a big fan of 'going with the flow' apart from when it is a really bad idea such as systemd. For the rest, I sold my car last year, and yes, it had a starting handle. Two of my four motorcycles still have kickstarts, but the other two can be converted to kickstart if I want to. All of them have 2 cylinders even though 'essence of motorcycling' is one cylinder. In view of the above, perhaps I should say I WAS a big fan of going with the flow when the going was good! DaveT ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] openbox-themes in ASCII?
Am 21.08.2017 um 21:57 schrieb fsmithred: > On 08/21/2017 08:59 AM, Michael Siegel wrote: >> Am 18.08.2017 um 16:04 schrieb fsmithred: >> >> What exactly do you mean by "some themes don't work"? I use obconf >> for setting the wm theme and gtk-theme-switch2 for setting the GTK >> theme. I just installed the openbox-themes package again and went >> through all the themes as well as the corresponding GTK themes >> where available. I couldn't make out any problem. >> > > The colors that I got did not match the colors in the samples. Lots > of gray, especially the hightlight. Some of those corrected when I > used lxappearance-obconf. And you are referring to the Openbox themes themselves and not the corresponding GTK2 themes coming with some of them? As you probably know, the Openbox themes themselves are not responsible for what's happening inside application windows. That's why you will have so set Openbox and GTK2 (or Qt etc.) themes separately. Maybe lxappearance-obconf tries to find the GTK themes automatically. >>> Separating the themes into several packages shouldn't be hard, >>> either. >> >> Good. I think that would make a lot of sense, from a user >> perspective as well as for maintenance purposes. So, if I gave you >> the theme files, could you package them? That would be great. As >> soon as I'm able to do the packaging myself, I could take over all >> the maintenance. >> > > If you edit the existing theme files, I should be able to replace > them and rebuild. Let's start with one or two and make sure it > works. Well, I wasn't going to edit anything, but there are new versions for some of those themes that we could try. Maybe we could try building per-collection packages right away. I'll think of something. >> Well, I don't know if it's a reasonable aim to make anything work >> with GTK3. From what I've read, theming for GTK3 seems like a >> tedious waste of time. I mean, if someone volunteers to do it, >> great. But I don't really mind if that doesn't happen. >> > > Good point. I was not thinking. As it seems, some of the theme creators are taking care of GTK3 support upstream. But as GTK3 seems to excel in regular API breakage that doesn't really help either. msi ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] fvwm
Hi all, Fvwm is a lightweight GOSFUI (Graphical Operating System Facing User Interface (http://www.troubleshooters.com/linux/gosfui.htm)) that is extremely configurable and extensible. Not many people use it, but those who do love it. The trouble is, it's very difficult to configure, and configuration tips and instructions are handed down from mentor to mentee with secret handshakes and incantations. There's almost no web documentation suitable for someone not already an expert. Nevertheless, Devuan has a very nice fvwm package that doesn't work until one copies a file, and then works great. Today I managed to integrate dmenu in with fvwm, creating a highly productive interface. I found a couple issues with Devuan Jessie's Display Manager screen that make using fvwm (or anything but the default) just a little more difficult: 1) "Press F1 to select session" 2) Choice of GOSFUI is not sticky As far as #1, what the hell does "session" mean? A session is something that runs for awhile, and usually the implication is it's already running. I think the word "session" needs to be changed to "GOSFUI". If you'd rather not use a word directly created to handle the exact concept, you could substitute "window manager or desktop environment". To articulate just "window manager" or just "desktop environment" is to create arguments, and also could lead to errors in very literal thinking people. #2 is bad because: a) Most other display managers default to the last GOSFUI that was run, not to the distro's default. b) People preferring not to use the distro's default are going to get mighty tired of F1-ing around the GOSFUI loop in order to pick their choice. I assume that slim (it is slim, right?) has a config for "sticky" selections, and the other thing is just a change of prompt. SteveT ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] fvwm
Quoting Steve Litt (sl...@troubleshooters.com): > Hi all, > > Fvwm is a lightweight window manager Fixed it for you. ;-> > I found a couple issues with Devuan Jessie's Display Manager screen For reference, the default X11 Display Manager in Devuan is 'SLiM', as you guessed. https://wiki.archlinux.org/index.php/SLiM https://en.wikipedia.org/wiki/SLiM http://www.archlinuxuser.com/2013/02/how-to-install-configure-slim-login.html The default window manager is xfwm starting with xfce4-session as an X11 Session Manager and the rest of the XFCE4 suite (xfm file manager, etc.) If it's unclear what a display manager (DM) is: https://wiki.archlinux.org/index.php/Display_manager (Provides graphical login, some allow user to choose wm.) If it's unclear what a session manager (SM) is: https://en.wikipedia.org/wiki/X_session_manager (Keeps track of what processes you're running and, if you suddenly logout and log back in, restarts them.) If it's unclear what a window manager (WM) is: https://wiki.archlinux.org/index.php/Window_manager (Special type of X11 client that controls the placing and organisation of all other X11 clients.) > ...that make using fvwm (or anything but the default) just a little more > difficult: > > 1) "Press F1 to select session" > As far as #1, what the hell does "session" mean? ITYM, what does 'session' mean as used in the 'SLiM' X11 Display Manager UI? In this context, it seems to mean state maintained by an X11 session manager such as xfce4-session. The ArchLinux wiki page says the SLiM DM parses these from /usr/share/xsessions/ by default. But the question you really wanted to ask is: How do you add fvwm to the things SLiM offers the user at login? On https://wiki.archlinux.org/index.php/SLiM, it looks like they say you need to edit both /etc/slim.conf and ~/.xinitrc, and hash out the line 'sessiondir /usr/share/xsessions/' in /etc/slim.conf in order to 'disable automatic detection of installed environments'. I gather that SLiM has a bias in favour of assuming that _naturally_ you are running a session manager. fvwm being blessedly unencumbered with extraneous baggage does not start up a session manager -- though I suppose you might be able to tack one on, in theory. > 2) Choice of session is not sticky Fixed it for you. ;-> It appears that each user can configure a default session by adding a DEFAULT_SESSION=[$THING] line in ~/xinitrc . The $THING would be the session manager or its wrapper script if you're running a session manager, e.g., 'startxfce4' wrapper for the XFC4 suite that starts up xfce4-session, xfwm, and probably a bunch of related junk, or 'fvwm2' to start just the fvwm WM (which as mentioned isn't bundled with a session manager), or the 'startfluxbox' wrapper for the Fluxbox WM, etc. Details are on http://www.archlinuxuser.com/2013/02/how-to-install-configure-slim-login.html ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] fvwm
On Tue, 22 Aug 2017 16:17:37 -0700 Rick Moen wrote: > But the question you really wanted to ask is: How do you add fvwm to > the things SLiM offers the user at login? No, that happened automatically once I installed the fvwm package with apt-get. SteveT ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] fvwm
I usually fire up fvwm for the rare instances that an app is awkward using tiles under i3. -- Joel Roth ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
