Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On September 2, 2015 2:12:33 AM GMT+02:00, Gregory Nowak wrote: >On Wed, Sep 02, 2015 at 01:59:55AM +0200, poitr pogo wrote: >> i'm against moderation. I'm against allowing enemies to sit at a campfire of refugees that have just been kicked out of their home. >I also realize I'm not the owner of >this list, so I'll quietly resume my seat now. if you like to open up a new unbiased mailinglist to debate pro and cons of systemd, please do. we can host that also here at lists.dyne.org but be warned: systemd will end up being always the subject, not leaving space for anything else, because they are superior and they have already solved all problems better than anyone else. Those who have been involved in the past 3 years of debates and have experience the prevarication in their logic can confirm. ciao -- Jaromil, for the Devuan Panther Party for Self Defence ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] wpa_supplicant/ifup integration documentation
Le 01/09/2015 04:10, Isaac Dunham a écrit : On Mon, Aug 31, 2015 at 09:38:12AM +0200, Didier Kryn wrote: Sorry, this thread became private my my mis-clicking on Icedove. Le 30/08/2015 22:37, Isaac Dunham a écrit : On Sun, Aug 30, 2015 at 12:58:59PM +0200, Didier Kryn wrote: Le 28/08/2015 04:28, Isaac Dunham a ??crit : I could make something similar to wpa_config but using wpa_cli more rather than writing a config file; *however*, this would be harder to edit and would lose comments if you make the changes permanent. wpa_gui works by interaction with wpa_supplicant, through the control socket, I guess, and the changes can be made permanent. Actually I am perfectly happy with wpa_gui; it is just perfect; I don't need anything else on my laptop. But some people consider that Qt is too big, and I agree that a lighter version with the same functionality is always a progress. Also a version working without X windows, but still GUI-like (ie ncurses), could be usefull. wpa_gui works through the control socket, as does wpa_cli. If you "make the changes permanent", you send a command over the control socket that writes out the in-memory config. Comments are not part of that in-memory config, so you will lose them. dialog is an ncurses-based tool for the "GUI-like" interface you mentioned. So the only thing which this UI would miss is that it couldn't put comments in the config file. I agree that most ESSIDs have no meaning and therefore motivate a description. This is a minor problem which no UI currently addresses. I don't think a comment is the proper method to do that. Comments are meant for humans who read the file, not for use by applications. What is missing is a formal field which could be called 'description' and should be managed by wpa_supplicant. To summarize, I see three possibilities 1) hack wpa_supplicant.conf from the UI to put a specially formatted comment. Very bad for the reason explained above and because it needs root permission and incurs race conditions with wpa_supplicant itself. 2) put the load on the user: let him choose or ask for sensible ESSIDs. 3) patch wpa_supplicant so that it accepts and stores a description phrase for every ESSID. Things could be staged: 2, then 3. And 3 might be just a request to the author of wpa_supplicant. What do you think? I'm *not* saying that I'd like to be able to *write* comments. In fact, I don't want to write any comments that aren't important for the person who edits wpa_supplicant.conf manually, and wpa_config currently doesn't write any comments except the ones wpa_passphrase makes. I simply would like to write to the file without *losing* all the comments that are there, which is what will happen if you use wpa_cli save_config or similar features in wpa_gui. Consider a file like resolv.conf . Either you write it by hand (and put comments at your will) or you let resolvconf write it for you, in which case it adds the comment "please do not edit this file". I think the situation is similar here: either you edit wpa_supplicant.conf by hand, or you rely on some tool to do it. IMHO mixing both behaviours is such a serious burden for little need that nobody ever did it for any config file. The only race in adding a network is when you (a) start wpa_supplicant, (b) invoke "wpa_cli reconfigure", or (c) use a respawner and have wpa_supplicant randomly crashing, in the midst of writing a new network entry to the config. Writing a new entry to a temp file, then appending it to the config, then reloading, is the most reliable approach, because you can fail much harder by using wpa_cli add_network/set_network/enable/save_config: suppose that wpa_supplicant starts after you start adding a network or crashes/restarts in the midst of it. You certainly know this better than me. I was naively thinking "wpa_cli add_network" would just pass the command to wpa_supplicant and wpa_supplicant was the only process reading/writing the file. Having only one process reading/writing the file seems to me a trivial way to avoid race conditions; I certainly miss something here. Finally, there's one fundamental flaw in wpa_gui, which actually was the initial motive for wpa_config: it's rather exasperating to have a tool to configure a program that won't work until the program is properly configured. The people who most need a tool for configuring wpa_supplicant are those who cannot configure it themselves. This means that wpa_config needs to write out a basic wpa_supplicant.conf itself on request. Don't you think this initial file could be created during package installation? For wpa_gui as well. It could be re-created with dpkg-reconfigure. I think wpa_id_str is adequate as far as a "description phrase", apart from the fact that you don't want it to be invalid for a logical interface. I am pretty sure there are very few cases where a wifi connection needs a static IP config. For th
Re: [DNG] wpa_supplicant/ifup integration documentation
Didier Kryn wrote: > I am pretty sure there are very few cases where a wifi connection needs a > static IP config. For the vast majority of cases, the config is dynamic and > one single id_str is enough for all; doing otherwise would bloat the > interfaces file for the sole sake of this description. That makes sense - provided that it's still possible to manually add entries which fall into that other 1%. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
Tobias Hunger writes: [...] >> on the same grounds, because systemd covers so much ground >> and does so many things (that *it should not* be doing) that any good >> engineer who wants to design an alternative will see a lot of insane >> features and immediately say "Nope, I'm not doing that, it's not the >> init system's job"; and systemd proponents will always answer "See? >> systemd is the only one that does that stuff, and all the competition >> is inferior". > > Go talk to other developers, find out what bothers them about the > non-systemd and systemd status quo and address those issues one by one. > Then blog about that solution and try to get developers to use it. Act on > their feedback when they provide it. > > I do not see that happening anywhere at this time. So far it is mostly > claiming everything used to be fine before systemd. It was not. Considering just the discussions on this list during the last couple of weeks, this is obviously a strawman. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] wpa_supplicant/ifup integration documentation
On Wed, 2 Sep 2015 10:05:11 +0100 Simon Hobson wrote: > > I am pretty sure there are very few cases where a wifi connection needs a > > static IP config. For the vast majority of cases, the config is dynamic and > > one single id_str is enough for all; doing otherwise would bloat the > > interfaces file for the sole sake of this description. > That makes sense - provided that it's still possible to manually add entries > which fall into that other 1%. I hope so, since my home LAN is all fixed IP addresses. ;-3) Cheers, Ron. -- To the make of a piper go seven years of his own learning and seven generations before. -- Neil Munro -- http://www.olgiati-in-paraguay.org -- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Doing away with multi-threading in my project (netman)
Hi all, I think, I found an alternative to multithreading in netman. This is using interprocess communication, although what I have in mind may not be proper interprocess communication. The idea is this: the backend would be converted into some sort of a daemon exporting one function and importing another one. The frontend would use the exported function from the backend to send it commands. The backend would do the same thing with the exported function from the frontend: Visually, this is as follows: Frontend -->> Backend Frontend <<-- Backend In my humble opinion, this may help getting rid of having to use multithreading to avoid temporary frontend deadlocks. It also solves the issue with zombies being created, and would permit me create a responsive application but using the KISS principle. Edward ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Doing away with multi-threading in my project (netman)
Am Mittwoch, 2. September 2015 schrieb Edward Bartolo: > Hi all, > > I think, I found an alternative to multithreading in netman. This is > using interprocess communication, although what I have in mind may not > be proper interprocess communication. > > The idea is this: the backend would be converted into some sort of a > daemon exporting one function and importing another one. The frontend > would use the exported function from the backend to send it commands. > The backend would do the same thing with the exported function from > the frontend: > > Visually, this is as follows: > > Frontend -->> Backend > Frontend <<-- Backend > > In my humble opinion, this may help getting rid of having to use > multithreading to avoid temporary frontend deadlocks. It also solves > the issue with zombies being created, and would permit me create a > responsive application but using the KISS principle. > > > Edward > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > What about using unix domain sockets and a cleartext protocol? Nik -- Please do not email me anything that you are not comfortable also sharing with the NSA. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On Tue, Sep 01, 2015 at 10:09:40AM +0200, Jaromil wrote: > > Speaking of which, my patch for "nodm" is online at [1]. > Great :^) I hope Enrico has time to have a look and perhaps include the > patch upstream. Unfortunately, most likely I will not: I only have time to work on nodm when a customer pays for it, and this is not happening at the moment, and there does not seem to be any incoming request for it in the near future. I of course would be very happy if people with time and energy could take over maintenance of nodm, so that it can be maintained regardless of how my work life goes. Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Doing away with multi-threading in my project (netman)
Hi, Thanks for the reply. If Unix Domain Sockets can do the job nicely, why not? However, I will wait for other replies for their opinion. Thanks. On 02/09/2015, dr.kl...@gmx.at wrote: > Am Mittwoch, 2. September 2015 schrieb Edward Bartolo: >> Hi all, >> >> I think, I found an alternative to multithreading in netman. This is >> using interprocess communication, although what I have in mind may not >> be proper interprocess communication. >> >> The idea is this: the backend would be converted into some sort of a >> daemon exporting one function and importing another one. The frontend >> would use the exported function from the backend to send it commands. >> The backend would do the same thing with the exported function from >> the frontend: >> >> Visually, this is as follows: >> >> Frontend -->> Backend >> Frontend <<-- Backend >> >> In my humble opinion, this may help getting rid of having to use >> multithreading to avoid temporary frontend deadlocks. It also solves >> the issue with zombies being created, and would permit me create a >> responsive application but using the KISS principle. >> >> >> Edward >> ___ >> Dng mailing list >> Dng@lists.dyne.org >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >> > > What about using unix domain sockets and a cleartext protocol? > > Nik > > -- > Please do not email me anything that you are not comfortable also sharing > with the NSA. > ___ > 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] Doing away with multi-threading in my project (netman)
Edward Bartolo writes: [...] > The idea is this: the backend would be converted into some sort of a > daemon exporting one function and importing another one. The frontend > would use the exported function from the backend to send it commands. > The backend would do the same thing with the exported function from > the frontend: > > Visually, this is as follows: > > Frontend -->> Backend > Frontend <<-- Backend This is not possible because functions can't be 'exported' in this way (OTOH, the whole backend - frontend split is pretty pointless, anyway ...) > In my humble opinion, this may help getting rid of having to use > multithreading to avoid temporary frontend deadlocks. As I already explained to you quite some times: There is no such need. You just have to stop fighting the API for dealing with deceased subprocesses and start using it instead. This means the GUI/ frontend either needs to handle SIGCHLD in order to get notified when a child process terminates so that a suitable wait call (which doubtlessly exists in the Free Pascal libraries) can be used to get rid of the zombie without having to wait for it or (the by far most simple solution), it (the GUI) needs to set the disposition of SIGCHLD to SIG_IGN because then, zombies won't even be created. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Doing away with multi-threading in my project (netman)
Quote: "This means the GUI/ frontend either needs to handle SIGCHLD in order to get notified when a child process terminates so that a suitable wait call (which doubtlessly exists in the Free Pascal libraries) can be used to get rid of the zombie without having to wait for it or (the by far most simple solution), it (the GUI) needs to set the disposition of SIGCHLD to SIG_IGN because then, zombies won't even be created." Aha, that gave me an idea, thanks for that. I can use the signal of the arrival of a new zombie as the time at which to re-enable grayed out buttons. The benefit of all this: very little changes to code and no multi-threading complications. Thanks. :D On 02/09/2015, Rainer Weikusat wrote: > Edward Bartolo writes: > > [...] > >> The idea is this: the backend would be converted into some sort of a >> daemon exporting one function and importing another one. The frontend >> would use the exported function from the backend to send it commands. >> The backend would do the same thing with the exported function from >> the frontend: >> >> Visually, this is as follows: >> >> Frontend -->> Backend >> Frontend <<-- Backend > > This is not possible because functions can't be 'exported' in this way > (OTOH, the whole backend - frontend split is pretty pointless, anyway > ...) > >> In my humble opinion, this may help getting rid of having to use >> multithreading to avoid temporary frontend deadlocks. > > As I already explained to you quite some times: There is no such > need. You just have to stop fighting the API for dealing with deceased > subprocesses and start using it instead. This means the GUI/ frontend > either needs to handle SIGCHLD in order to get notified when a child > process terminates so that a suitable wait call (which doubtlessly exists in > the > Free Pascal libraries) can be used to get rid of the zombie without > having to wait for it or (the by far most simple solution), it (the GUI) > needs to set the disposition of SIGCHLD to SIG_IGN because then, zombies > won't even be created. > ___ > 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] Doing away with multi-threading in my project (netman)
I found this code in gensigset.inc and signals.inc fpc source library. Is this what we are talking about? function FPSigaction( sig: cint; act: psigactionrec; oact: psigactionrec ):cint; function fpsigemptyset(var nset : tsigset):cint; var i :longint; Begin for i:=0 to wordsinsigset-1 DO nset[i]:=0; fpsigemptyset:=0; End; And: type sigset_t = array[0..wordsinsigset-1] of cuLong; tsigset = sigset_t; sigset = sigset_t; psigset = ^tsigset; psiginfo = ^tsiginfo; tsiginfo = record si_signo : longint; si_errno : longint; si_code : longint; _sifields : record case longint of 0 : ( _pad : array[0..(SI_PAD_SIZE)-1] of longint ); 1 : ( _kill : record _pid : pid_t; _uid : uid_t; end ); 2 : ( _timer : record _timer1 : dword; _timer2 : dword; end ); 3 : ( _rt : record _pid : pid_t; _uid : uid_t; _sigval : pointer; end ); 4 : ( _sigchld : record _pid : pid_t; _uid : uid_t; _status : longint; _utime : clock_t; _stime : clock_t; end ); 5 : ( _sigfault : record _addr : pointer; end ); 6 : ( _sigpoll : record _band : longint; _fd : longint; end ); end; end; On 02/09/2015, Edward Bartolo wrote: > Quote: "This means the GUI/ frontend > either needs to handle SIGCHLD in order to get notified when a child > process terminates so that a suitable wait call (which doubtlessly exists in > the > Free Pascal libraries) can be used to get rid of the zombie without > having to wait for it or (the by far most simple solution), it (the GUI) > needs to set the disposition of SIGCHLD to SIG_IGN because then, zombies > won't even be created." > > Aha, that gave me an idea, thanks for that. I can use the signal of > the arrival of a new zombie as the time at which to re-enable grayed > out buttons. > > The benefit of all this: very little changes to code and no > multi-threading complications. > > Thanks. :D > > On 02/09/2015, Rainer Weikusat wrote: >> Edward Bartolo writes: >> >> [...] >> >>> The idea is this: the backend would be converted into some sort of a >>> daemon exporting one function and importing another one. The frontend >>> would use the exported function from the backend to send it commands. >>> The backend would do the same thing with the exported function from >>> the frontend: >>> >>> Visually, this is as follows: >>> >>> Frontend -->> Backend >>> Frontend <<-- Backend >> >> This is not possible because functions can't be 'exported' in this way >> (OTOH, the whole backend - frontend split is pretty pointless, anyway >> ...) >> >>> In my humble opinion, this may help getting rid of having to use >>> multithreading to avoid temporary frontend deadlocks. >> >> As I already explained to you quite some times: There is no such >> need. You just have to stop fighting the API for dealing with deceased >> subprocesses and start using it instead. This means the GUI/ frontend >> either needs to handle SIGCHLD in order to get notified when a child >> process terminates so that a suitable wait call (which doubtlessly exists >> in >> the >> Free Pascal libraries) can be used to get rid of the zombie without >> having to wait for it or (the by far most simple solution), it (the GUI) >> needs to set the disposition of SIGCHLD to SIG_IGN because then, zombies >> won't even be created. >> ___ >> 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] Doing away with multi-threading in my project (netman)
On Wed, 2 Sep 2015 11:47:34 +0100 Edward Bartolo wrote: > Hi all, > > I think, I found an alternative to multithreading in netman. This is > using interprocess communication, although what I have in mind may not > be proper interprocess communication. > > The idea is this: the backend would be converted into some sort of a > daemon exporting one function and importing another one. The frontend > would use the exported function from the backend to send it commands. > The backend would do the same thing with the exported function from > the frontend: > > Visually, this is as follows: > > Frontend -->> Backend > Frontend <<-- Backend > > In my humble opinion, this may help getting rid of having to use > multithreading to avoid temporary frontend deadlocks. It also solves > the issue with zombies being created, and would permit me create a > responsive application but using the KISS principle. I like it. A lot! IMHO the front end should do nothing but display ESSIDs with strength and encryption, letting you click on the one you want or right click and say "turn off" to turn it off. If you've already dealt with that ESSID, the back end has the password and uses it to join that ESSID. If the back end hasn't dealt with it, it sends the front end a message saying "get me the password", the front end queries the user for the password, and the front end sends it back to the back end. Assuming one user, this doesn't even have to be stateful, but if it has to be stateful, there are a million ways to do it. I like it! SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Doing away with multi-threading in my project (netman)
What about multithreading? Should I do away with it and let the frontend monitor for zombies to call waitpid? Edward On 02/09/2015, Steve Litt wrote: > On Wed, 2 Sep 2015 11:47:34 +0100 > Edward Bartolo wrote: > >> Hi all, >> >> I think, I found an alternative to multithreading in netman. This is >> using interprocess communication, although what I have in mind may not >> be proper interprocess communication. >> >> The idea is this: the backend would be converted into some sort of a >> daemon exporting one function and importing another one. The frontend >> would use the exported function from the backend to send it commands. >> The backend would do the same thing with the exported function from >> the frontend: >> >> Visually, this is as follows: >> >> Frontend -->> Backend >> Frontend <<-- Backend >> >> In my humble opinion, this may help getting rid of having to use >> multithreading to avoid temporary frontend deadlocks. It also solves >> the issue with zombies being created, and would permit me create a >> responsive application but using the KISS principle. > > I like it. A lot! > > IMHO the front end should do nothing but display ESSIDs with strength > and encryption, letting you click on the one you want or right click > and say "turn off" to turn it off. > > If you've already dealt with that ESSID, the back end has the password > and uses it to join that ESSID. If the back end hasn't dealt with it, > it sends the front end a message saying "get me the password", the > front end queries the user for the password, and the front end sends it > back to the back end. Assuming one user, this doesn't even have to be > stateful, but if it has to be stateful, there are a million ways to do > it. > > I like it! > > SteveT > > Steve Litt > August 2015 featured book: Troubleshooting: Just the Facts > http://www.troubleshooters.com/tjust > ___ > 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] Doing away with multi-threading in my project (netman)
Personally, I'd go way out of my way never to multithread unless there were a huge reason to do so. Your app does such a small, quick job that there's no reason. You mentioned the front and back end communicating with each other, and everyone mentioned fifos. I agree. And if there's a reason for one program to tell the other that info's ready for it, that's what SIGUSR1 and SIGUSR2 are for. Or at least what *I* use them for. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust On Wed, 2 Sep 2015 19:45:08 +0100 Edward Bartolo wrote: > What about multithreading? Should I do away with it and let the > frontend monitor for zombies to call waitpid? > > Edward > > On 02/09/2015, Steve Litt wrote: > > On Wed, 2 Sep 2015 11:47:34 +0100 > > Edward Bartolo wrote: > > > >> Hi all, > >> > >> I think, I found an alternative to multithreading in netman. This > >> is using interprocess communication, although what I have in mind > >> may not be proper interprocess communication. > >> > >> The idea is this: the backend would be converted into some sort of > >> a daemon exporting one function and importing another one. The > >> frontend would use the exported function from the backend to send > >> it commands. The backend would do the same thing with the exported > >> function from the frontend: > >> > >> Visually, this is as follows: > >> > >> Frontend -->> Backend > >> Frontend <<-- Backend > >> > >> In my humble opinion, this may help getting rid of having to use > >> multithreading to avoid temporary frontend deadlocks. It also > >> solves the issue with zombies being created, and would permit me > >> create a responsive application but using the KISS principle. > > > > I like it. A lot! > > > > IMHO the front end should do nothing but display ESSIDs with > > strength and encryption, letting you click on the one you want or > > right click and say "turn off" to turn it off. > > > > If you've already dealt with that ESSID, the back end has the > > password and uses it to join that ESSID. If the back end hasn't > > dealt with it, it sends the front end a message saying "get me the > > password", the front end queries the user for the password, and the > > front end sends it back to the back end. Assuming one user, this > > doesn't even have to be stateful, but if it has to be stateful, > > there are a million ways to do it. > > > > I like it! > > > > SteveT > > > > Steve Litt > > August 2015 featured book: Troubleshooting: Just the Facts > > http://www.troubleshooters.com/tjust > > ___ > > 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] wpa_supplicant/ifup integration documentation
On Wed, Sep 02, 2015 at 10:05:01AM +0200, Didier Kryn wrote:
> Le 01/09/2015 04:10, Isaac Dunham a écrit :
> >I simply would like to write to the file without *losing* all the comments
> >that are there, which is what will happen if you use
> > wpa_cli save_config
> >or similar features in wpa_gui.
>
> Consider a file like resolv.conf . Either you write it by hand (and put
> comments at your will) or you let resolvconf write it for you, in which case
> it adds the comment "please do not edit this file". I think the situation is
> similar here: either you edit wpa_supplicant.conf by hand, or you rely on
> some tool to do it. IMHO mixing both behaviours is such a serious burden for
> little need that nobody ever did it for any config file.
Frequently I find myself thinking that a GUI is good for getting things
roughly correct, but it's much more useful to edit it when you want to
fine-tune things.
> >The only race in adding a network is when you (a) start wpa_supplicant,
> >(b) invoke "wpa_cli reconfigure", or (c) use a respawner and have
> >wpa_supplicant randomly crashing, in the midst of writing a new network
> >entry to the config.
> >Writing a new entry to a temp file, then appending it to the config,
> >then reloading, is the most reliable approach, because you can fail much
> >harder by using wpa_cli add_network/set_network/enable/save_config:
> >suppose that wpa_supplicant starts after you start adding a network or
> >crashes/restarts in the midst of it.
>
> You certainly know this better than me. I was naively thinking "wpa_cli
> add_network" would just pass the command to wpa_supplicant and
> wpa_supplicant was the only process reading/writing the file. Having only
> one process reading/writing the file seems to me a trivial way to avoid race
> conditions; I certainly miss something here.
wpa_supplicant would be the only process reading/writing the file, but
you need five commands at minimum.
Here's roughly how you'd add an open network with wpa_cli:
NETNUM=`wpa_cli add_network` || fail
wpa_cli set_network $NETNUM ssid "$SSID" || fail
wpa_cli set_network $NETNUM key_mgmt NONE || fail
wpa_cli enable_network $NETNUM || fail
wpa_cli save_config || fail
And doing it manually:
cat $CONFIG >$TEMPFILE || fail
echo -e "network={\n\tssid=$SSID\n\tkey_mgmt=NONE\n}\n" >>$TEMPFILE || fail
cp $TEMPFILE $CONFIG
> >Finally, there's one fundamental flaw in wpa_gui, which actually was the
> >initial motive for wpa_config:
> >it's rather exasperating to have a tool to configure a program that won't
> >work until the program is properly configured.
> >The people who most need a tool for configuring wpa_supplicant are those
> >who cannot configure it themselves.
> >This means that wpa_config needs to write out a basic wpa_supplicant.conf
> >itself on request.
>
> Don't you think this initial file could be created during package
> installation? For wpa_gui as well. It could be re-created with
> dpkg-reconfigure.
Theoretically, it would be nice if this happened when wpa_supplicant
was installed; no other package has a logical reason to provide a
systemwide default config file.
Practically,
(a) no distro that I'm aware of ships wpa_supplicant with a configuration
file, and
(b) I originally wrote it without any expectation of it being properly
packaged; I use a built-from-scratch musl/busybox system frequently,
and this was one of the main targets.
> >I think wpa_id_str is adequate as far as a "description phrase",
> >apart from the fact that you don't want it to be invalid for a logical
> >interface.
>
> I am pretty sure there are very few cases where a wifi connection needs
> a static IP config. For the vast majority of cases, the config is dynamic
> and one single id_str is enough for all; doing otherwise would bloat the
> interfaces file for the sole sake of this description. By just putting
> "iface default inet dhcp" you cover all cases with dynamic IP config, that
> is 99.99 of cases. This also can be done during package installation.
True.
However, it may be desireable to use multiple configs for some dynamic
configs:
if it's best to use with one network, you can put
that in the post-up field.
Eg:
iface chico inet dhcp
post-up vpnc --username /etc/vpnc/csuc.conf
(this is how I'd make http://myweb.csuchico.edu/~idunham/csuc-vpn.htm
work with the networking service.)
But in general, I'd assume that people don't need custom configurations,
or special network identification.
After all, the vast majority of UIs don't offer the latter.
Thanks,
Isaac
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Doing away with multi-threading in my project (netman)
On 09/02/2015 10:27 PM, Steve Litt wrote: > Personally, I'd go way out of my way never to multithread unless > there were a huge reason to do so. Your app does such a small, quick > job that there's no reason. > > You mentioned the front and back end communicating with each other, > and everyone mentioned fifos. I agree. And if there's a reason for > one program to tell the other that info's ready for it, that's what > SIGUSR1 and SIGUSR2 are for. Or at least what *I* use them for. Yeah ok, let's do this :) But where's the most current code? :-D I lost sight of it at some point. Best regards, T. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Doing away with multi-threading in my project (netman)
I am trying to reap zombies. The "while(fpwaitpid" pascal code is
freezing my application.
*
procedure handle_sigchld(sig: longint; info: psiginfo; context:
psigcontext); cdecl;
var
Status: cint;
a_pid: pid_t;
begin
Status := 0;
a_pid := -1;
// This is freezing my application
while (fpwaitpid(a_pid, Status, WNOHANG) > 0) do
begin
backend_lives := backend_lives + 1;
showmessage('hi strunz!!!');
end;
end;
var sa: sigactionrec;
initialization
sa.sa_handler := @handle_sigchld;
fpsigemptyset(&sa.sa_mask);
sa.sa_flags := (SA_RESTART or SA_NOCLDSTOP);
if (fpsigaction(SIGCHLD, @sa, nil) = -1) then
begin
// do nothing
end;
**
Any ideas?
Edward
On 02/09/2015, Steve Litt wrote:
> Personally, I'd go way out of my way never to multithread unless
> there were a huge reason to do so. Your app does such a small, quick
> job that there's no reason.
>
> You mentioned the front and back end communicating with each other, and
> everyone mentioned fifos. I agree. And if there's a reason for one
> program to tell the other that info's ready for it, that's what SIGUSR1
> and SIGUSR2 are for. Or at least what *I* use them for.
>
> SteveT
>
> Steve Litt
> August 2015 featured book: Troubleshooting: Just the Facts
> http://www.troubleshooters.com/tjust
>
>
> On Wed, 2 Sep 2015 19:45:08 +0100
> Edward Bartolo wrote:
>
>> What about multithreading? Should I do away with it and let the
>> frontend monitor for zombies to call waitpid?
>>
>> Edward
>>
>> On 02/09/2015, Steve Litt wrote:
>> > On Wed, 2 Sep 2015 11:47:34 +0100
>> > Edward Bartolo wrote:
>> >
>> >> Hi all,
>> >>
>> >> I think, I found an alternative to multithreading in netman. This
>> >> is using interprocess communication, although what I have in mind
>> >> may not be proper interprocess communication.
>> >>
>> >> The idea is this: the backend would be converted into some sort of
>> >> a daemon exporting one function and importing another one. The
>> >> frontend would use the exported function from the backend to send
>> >> it commands. The backend would do the same thing with the exported
>> >> function from the frontend:
>> >>
>> >> Visually, this is as follows:
>> >>
>> >> Frontend -->> Backend
>> >> Frontend <<-- Backend
>> >>
>> >> In my humble opinion, this may help getting rid of having to use
>> >> multithreading to avoid temporary frontend deadlocks. It also
>> >> solves the issue with zombies being created, and would permit me
>> >> create a responsive application but using the KISS principle.
>> >
>> > I like it. A lot!
>> >
>> > IMHO the front end should do nothing but display ESSIDs with
>> > strength and encryption, letting you click on the one you want or
>> > right click and say "turn off" to turn it off.
>> >
>> > If you've already dealt with that ESSID, the back end has the
>> > password and uses it to join that ESSID. If the back end hasn't
>> > dealt with it, it sends the front end a message saying "get me the
>> > password", the front end queries the user for the password, and the
>> > front end sends it back to the back end. Assuming one user, this
>> > doesn't even have to be stateful, but if it has to be stateful,
>> > there are a million ways to do it.
>> >
>> > I like it!
>> >
>> > SteveT
>> >
>> > Steve Litt
>> > August 2015 featured book: Troubleshooting: Just the Facts
>> > http://www.troubleshooters.com/tjust
>> > ___
>> > 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
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
