On Thu, 20 Aug 2015 22:28:45 +0200
Didier Kryn <kryn@???> wrote:

> Le 19/08/2015 20:09, Edward Bartolo a écrit :
> > The power inherent in C is due to it not
> > getting in the way of the coder, and I like that.
>

[snip]

>

>      I didn't review your code. This has been done by others anyway.
> My problem is that I don't see the big picture. 

My understanding is that the big picture is that Edward's making a very
simple system for dealing with Wifi, both in your house and travelling
from hotspot to hotspot. His solution has minimal dependencies and can
be run by anyone with just about any Linux configuration. One reason he
uses C is because there's no guarantee that Python or Ruby or Lua is
installed on the system.

Edward's front end obtains a list of Wifi transmitters, together with
their signal strengths and encryption type, by spawning "iwlist $netdev
scanning", where $netdev is typically but not always "wlan0". The user
chooses one wifi transmitter from the front end, sends its ssid to the
back end. The back end looks at its list of known ssids. If this ssid
is known, it connects with the known password. Otherwise (and here I
might be wrong), the back end signals the front end to query for the
new password for the new ssid, and after the user puts in both, the
front end sends it to the back end, that now does these two things:

1) Writes a new interface file, for this ssid, for future reference.

2) Connects to this ssid with the inputted password.

My understanding is the back end is calling the ifup program, which I
believe but am not sure, somewhere calls wpa_supplicant to do the work
on Wifi. But I could be wrong about that.

It's a pretty simple and, IMHO, robust architecture. One beauty of it
is that, although Edward's using Lazarus to make a nice GUI front end
for the thing, most people on this list could make a shellscript front
end for it. Or zenity. Or Tcl/Tk. Or Python. Or whatever. If I
understand correctly, his back end, and only his back end, is in C.

>      I would also like to know what your understanding is of how the 
> things are handled by the cooperative interaction of ifup, ifdown and 
> wpa_supplicant. This is something for which I cannot find a 
> comprehensive description, and I think a full understanding is
> necessary *prior* to endeavour what you are doing. 

You and I have a philosophical difference here. All too often, by the
time people reach *full* understanding, the project languishes and
nothing happens. Prior to the invasion of paid programmers in Open
Source, the world was full of software written with a partial
understanding, and incrementally improved (or rewritten) later.

I wrote the original VimOutliner in 2 days, using Perl, Vim, and
shellscripts. Kludge-city. If you'd seen that version 0.10, you'd have
laughed.

But unlike the other outliners of that era, VimOutliner worked, and
worked fast. People started using it. People started depending on it.
People a lot smarter than I started improving it. Within two years it
was head and shoulders faster and more convenient and easier to use than
any other outliner on the planet. That never would have happened
without my two day kludge.

Look at it another way. I was mouthing off about making a replacement
for NetworkManager and Wicd. But I did nothing. Several others were
talking about it, but they did nothing. Now Edward did it.

There are different kinds of Open Source. When Redhat pays three years
salary to Lennart and Kai and the gang, they can afford to take the
time for full understanding. When a guy with a day job makes something,
he gets it out there and the improvements come later. And for my money,
I prefer the stuff made by unpaid guys with day jobs: They (we) don't
have enough time to make entangled monoliths.

> This is because
> these 3 tools are doing a lot of things, and rather well and it is
> a waste of time and talent to re-invent the wheel.

He's not reinventing them at all. He's gluing them together so they're
fast and convenient for a user walking his laptop from McDonalds to
Starbucks.

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust