Re: [DNG] Which DE?
Hi Jochen, On 2/3/20 8:11, J. Fahrner via Dng wrote: Am 2020-03-01 23:07, schrieb aitor: My vote is for tint2. I also vote for openbox with tint2. if you don't want to tediously configure it yourself, install Bunsenlabs https://www.bunsenlabs.org/ and then migrate it to Devuan. Bunsenlabs has a nice theme and helper scripts for the openbox menu. It saves you a lot of work. Jochen I use the same configuration for tint2 than bunsenlabs (i'm registered in both the english and spanish forums, and the currently non existent www.bunsenlabs.es dominium initially was paid by me years ago). On the other hand, I'm also working on a launcher for tint2, named popupmenu, but i'm using it as a replacement for the default menu of openbox when you do a right click in the screen so far: https://git.devuan.org/aitor_czr/popupmenu/blob/master/screenshot.png Its response is immediate, since it's multithreaded and it's displayed at the same time than the installed applications are hunted on the fly. At this point I have he doubt about how to display this menu according to the tint2 geometry. Johan Malm is also working on a similar project named jgmenu (the *sbuf* features used in simple-netaid have been taken from his project): https://github.com/johanmalm/jgmenu This menu seems to use an unix socket for setting the (x, y) coordinates, but i still didn't give it a try. I'd like to contact with the author in order to deal with this issue between us and the tint2 developers altogether. Another alternative to the mentioned menus might be Steve Litt's dmenu: http://troubleshooters.com/linux/ctwm/dmenu.htm Cheers, Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Which DE?
Hi Steve, On 3/3/20 20:05, Steve Litt wrote: On Mon, 02 Mar 2020 08:11:49 +0100 "J. Fahrner via Dng" wrote: Am 2020-03-01 23:07, schrieb aitor: My vote is for tint2. I also vote for openbox with tint2. Last night I installed tint2 on my OpenBox. Seems to work very nicely. The tint2conf configuration tool that ships with it is horribly incomplete, so config must be done manually via file edit and then applied via killall -SIGUSR1, which would be very difficult for non-power-users. if you don't want to tediously configure it yourself, install Bunsenlabshttps://www.bunsenlabs.org/ and then migrate it to Devuan.tint2) & #(sleep 5s && tint2 -c ~/.config/tint2/tint2rc1) & Bunsenlabs has a nice theme and helper scripts for the openbox menu. It saves you a lot of work. That's good info, because tint2conf sucks. SteveT It's possible to display several tint2 panels with different configurations by adding: tint2 & tint2 -c ~/.config/tint2/tint2rc1 & to your ~/.config/openbox/autostart file. The first one'll use ~/.config/tint2/tint2rc by default. On the other hand, I'm aware that you are an openbox user, and maybe the following logout yad script will be useful for you: https://sourceforge.net/p/yad-dialog/wiki/Examples/ It doesn't depend on dbus, as opposed to bunsenlabs logout dialog (at least time ago), developed by Corenominal. Cheers, Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FF now defaults to DNS-over-HTTPS for US
On Tue, 3 Mar 2020 18:43:01 -0500 Clarke Sideroad via Dng wrote: > On 2020-03-03 5:45 p.m., spiralofhope wrote: > > This helps me remember: > > E for English "grEy" > > A for American "grAy" > > > I attempt to be trilingual in "English". > Thanks, that memory tool is great. > In Canada we say GrEh, but we spell it the English way. (-; It's aboat the same thing, eh? SteveT Steve Litt February 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FF now defaults to DNS-over-HTTPS for US
Anno domini 2020 Wed, 4 Mar 15:01:55 -0500 Steve Litt scripsit: > On Tue, 3 Mar 2020 18:43:01 -0500 > Clarke Sideroad via Dng wrote: > > > On 2020-03-03 5:45 p.m., spiralofhope wrote: > > > This helps me remember: > > > E for English "grEy" > > > A for American "grAy" > > > > > I attempt to be trilingual in "English". > > Thanks, that memory tool is great. > > In Canada we say GrEh, but we spell it the English way. (-; > > It's aboat the same thing, eh? Are you sure that femails would not use slightly more elaborate color names? Maybe it's just a misunderstanding and "grey" is used for the more redish tones an "gray" for a more greeish tones? All indistinguishable for mail eyes, so mails think that it's something about geolocation? Nik > > SteveT > > Steve Litt > February 2020 featured book: Thriving in Tough Times > http://www.troubleshooters.com/thrive > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] why is polkit needed?
On Tue, Feb 25, 2020, at 3:28 AM, Didier Kryn wrote: > Le 25/02/2020 à 09:05, Steve Litt a écrit : > > On Mon, 24 Feb 2020 12:21:16 + > > Daniel Abrecht via Dng wrote: > ... > >> Without dbus, applications & daemons could do similar things using > >> unix sockets. ... > > Yep, socket, signals, fifos, inotify, netlink, semaphores, > shared-memory, what else? > > It's probably possible to build some well thought middleware with > these, but Dbus isn't that one. ^^ This has been in the back of my mind for some time. In the last few years, we have been inspired to collect a fairly complete set of requirements for what polkit, dbus (and init :) need to do, and what they don't. In great detail. Requirements are great, because once you have them you can do a much better job of designing software. Surely it is time to boil down the dbus/polkit requirements and and start over. Preferably with sane limitations on scope and configuration mechanisms. I mean, I'm just thinking out loud here something that I've been thinking for about 6 months. As it stands now, these systems can serve as a good proof of concept from which to harvest requirements. This is not a *fun* project. Speaking as a programmer, sysadm, and end user, I would gladly never touch dbus again, and I've gone out of my way to avoid using or installing it since my initial contact and my life has been better for it. But I mean, basic publish-subscribe message functionality doesn't /have/ to be a nightmare does it? Surely this was not a requirement? :) Polkit doesn't /have/ to be a total pain to configure? Surely ease of configuration should have been a top-level requirement for polkit, and a clean programming api and sensible message naming should have been first-pass requirements for dbus? Re this thread, clearly a multi-user system with a GUI does need polkit and /some/ sort of dbus mechanism (which I will henceforth refer to as the "dbus mechanism" as if it were some sort of doomsday device). But it doesn't have to be polkit as currently shipping. And clearly The DBus Mechanism just needs a do-over. Both of these things can be very useful even if done badly, as demonstrated by their current incarnation. So, I would consider rewriting polkit and dbus from scratch. Also, who has time to rewrite polkit and dbus from scratch? * polkit might be salvageable? * dbus probably not salvageable, also deeply integrated into every possible program; consider dbus compatibility shim D: Sounds like a medium-sized project. Ideally should be done by someone with a big ego and no coding skills, rolling it all in C++ as one huge binary and integrating it into systemd. No, wait, that was sarcasm. But seriously, it shouldn't be as difficult of a problem to solve, other than the problem of inertia keeping the existing hacks in place and the problem of raw development effort. But these are core system processes and important. If it were my OS I'd be working on replacing these things as a priority because they're core. Just thinking aloud. Also, hi. DD ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FF now defaults to DNS-over-HTTPS for US
On Mon, Mar 2, 2020, at 4:34 AM, Dan Purgert wrote: > On Mar 02, 2020, spiralofhope wrote: > That is certainly some Orwellian thinking right there. You say "Orwellian thinking" like it's a bad thing. :) DD ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] why is polkit needed?
tekHedd wrote: > Surely it is time to boil down the dbus/polkit requirements and and start > over. Preferably with sane limitations on scope and configuration mechanisms. > I mean, I'm just thinking out loud here something that I've been thinking for > about 6 months. I applaud your thinking, but alas I fear the result may be https://xkcd.com/927/ > Also, who has time to rewrite polkit and dbus from scratch? Alas I have neither the time nor skills to help with such a project :-( Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FF now defaults to DNS-over-HTTPS for US
On Wed, 4 Mar 2020 21:31:49 +0100 "Dr. Nikolaus Klepp" wrote: > Are you sure that femails would not use slightly more elaborate color > names? Maybe it's just a misunderstanding and "grey" is used for the > more redish tones an "gray" for a more greeish tones? All > indistinguishable for mail eyes, so mails think that it's something > about geolocation? Well, I'm not sure about mails or femails, but I'm very certain there is a subset of females that could certainly give your better descriptions of grey/gray than the platry described six grey/grays in rgb.txt. I am of course referring to those who work in textiles who have to consider the grey/gray content of material in choosing which patterns/colour to combine. The other 102 greyNN labels definitely has to be a typical male trait. Getting back to the subject, taking a tip mentioned earlier about where to point FF's new DNS has certainly uncovered at least one web site for me that the combined various powers prefer not to be visible. So good bt of info to file away. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] why is polkit needed?
Quoting tekHedd (tekh...@byteheaven.net): > Re this thread, clearly a multi-user system with a GUI does need > polkit and /some/ sort of dbus mechanism (which I will henceforth > refer to as the "dbus mechanism" as if it were some sort of doomsday > device). I don't think I buy that assumption, at all. Users who need access to a sound device can be added to the group with privileges to that sound advice, etc. Proper user-friendly administrative tools can front-end that granting of user privilege. A whole new system layer to regulate access to everything strikes me a solution in search of a problem. dbus as a generic object-and-message-passing mechanism seems per-se harmless enough, but the history of component software using a messaging bus (e.g., CORBA, KCOP, Microsoft's OLE) is wretched and wasteful enough that I doubt the competence at software design of coders making significant use of it, and, again, I see no compelling use-case at all. -- Cheers, "Why doesn't anyone invite copyeditors to parties, Rick Moen when we're such cool people out with whom to hang?" r...@linuxmafia.com-- @laureneoneal (Lauren O'Neal) McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
