5 ms·

While I don't disagree that wpa_supplicant has been spawned from hell, I find it strange that the existence and popularity of NetworkManager is given as a clue

While I don't disagree that wpa_supplicant has been spawned from hell, I find it strange that the existence and popularity of NetworkManager is given as a clue for why {Net|Free|Open}BSD is better. You know, connecting to a WPA protected Wifi network is not the only problem users have. For example, another one would be connecting to a VPN, a task that NetworkManager greatly simplifies, assuming that such integration is available of course (e.g. if you think connecting to a Wifi network is problematic, try connecting to a L2TP over IPSec VPN). There's also the issue that the simplicity exposed in your example is a little misleading. Will the system persist that command and re-execute it on boot? Will it remember my previously used Wifi networks and connect automatically should I want that? How can I view the available Wifi networks in range? Being able to connect to a Wifi network using a simple ifconfig command is great, but the notion that your 80% of use-cases is the same as everybody else's 80% is misguided at best. > If I ever need them -- OH THE HORROR AND THE BLASPHEMY -- I have a Windows laptop, which for all intents and purposes is by now about as closed and as hard to wrestle with as Fedora And therein lies my problem with your entire comment. It's not that I disagree with your usage patterns, but I disagree with your assertions in light of these usage patterns. So you're saying that xBSD is simpler / better, yet you can't use it on your laptop, as it lacks things you need. Well, no shit.

weland 11y ago
> For example, another one would be connecting to a VPN, a task that NetworkManager greatly simplifies, assuming that such integration is available of course (e.g. if you think connecting to a Wifi network is problematic, try connecting to a L2TP over IPSec VPN). That's because there is equally no uniform and simple way to connect to use those, either. The problem is that the "simplification" that NetworkManager provides is illusory. Yes, it provides an interface that is easier to access, and all the complexity is moved in the back, where it's handled by NetworkManager. Unfortunately, the mechanisms through which it does that are fiercely complicated, too. I've had NetworkManager break on me countless times (I worked for a company that developed networking equipment for a while, so I've interacted with NM a lot), for a lot of silly things -- making me end up with slightly incorrect configurations or reapplying settings at weird times for no apparent reasons. The end result is anything but simplified: not only do I have to deal with the inherent complexity of a quirky VPN connection -- now I also have to understand how NetworkManager reasons about it and figure out where it's wrong. I also think it's misguided to have a single tool handle things so disparate like VPN and WiFi. It's not like you're ever going to be able to expose those through a unified interface -- NetworkManager's own D-Bus-based API being a prime example of that. > There's also the issue that the simplicity exposed in your example is a little misleading. Will the system persist that command and re-execute it on boot? Will it remember my previously used Wifi networks and connect automatically should I want that? How can I view the available Wifi networks in range? Being able to connect to a Wifi network using a simple ifconfig command is great, but the notion that your 80% of use-cases is the same as everybody else's 80% is misguided at best. You scan for networks with ifconfig <interface> scan. The system will not persist commands (arguably, a good decision) but persisting those settings is pretty easy -- you just add the same parameters you pass to ifconfig in /etc/hostname.<interface name>. (The same parameters as in argv[1:n]). The only thing it won't do out of the box is automatically connect to previously used wifi networks. I suspect none of the OpenBSD developers want that. I only needed a feature like that once, a few months ago when I moved to a new apartment and had no Internet connection of my own (cable company is shit) so I had to snoop from the free wireless of nearby cafes. The fact that the interface to ifconfig is so simple and uniform meant that the whole thing was a ten-line shell script to scan for, and connect to previously known networks, and a shell alias to save the current network to the list of known networks. There's an even easier way, using virtual networks, but I didn't know about it at the time. > So you're saying that xBSD is simpler / better, yet you can't use it on your laptop, as it lacks things you need. Well, no shit. I have a Windows laptop, which I also had when I ran Linux. My day-to-day laptop runs OpenBSD.
- xorcist 11y ago
  Network Manager still has problems. I've had a lucky streak for a few years where it hasn't given me problems, but the other day the GUI decided not to save my settings anymore. It looks like it does, but it doesn't. If I kill the beast and tap in the commands it just works, but if I run the daemon it keeps feeding the backends with old settings. How do I debug this? There's just sockets and layers of GTK. I'll probably end up doing whatever voodoo I need to keep it away and give it another few years.
  - weland 11y ago
    dbus-monitor ( http://dbus.freedesktop.org/doc/dbus-monitor.1.html http://dbus.freedesktop.org/doc/dbus-monitor.1.html ) and a lot of patience are your friends. I know of no other method.
  - fragmede 11y ago
    In case you're actually interested in fixing that particular problem, it's probably polkit that's gone bad. To examine the issue further, nm-connection-editor is a separate binary that you can run from the command line, and it'll print errors on stdout - including what it's unable to do.
- stsp 11y ago
  > The only thing it won't do out of the box is automatically connect to previously used wifi networks. I suspect none of the OpenBSD developers want that. That's not true. OpenBSD developers want this. There are several ideas floating around about making the kernel cache wifi passwords, scan and re-connect automatically when it lost link to the AP. This topic keeps coming up during hackathons. For various reasons it's not as easy to do as one might expect. The net80211 layer and wifi device drivers don't keep track of link state to the AP at present. This would need to be implemented first. It is essentially client-side roaming support. One way of doing this is to count missed beacons and assume the AP is out of range if no beacons have been seen for a while. Some devices provide such counters in hardware, some don't. The biggest part of the challenge is to make this work seamlessly with _every_ driver. Then there's a risk of feature bloat. Add too much automation and you end up with something opaque like network manager which just pisses many people off. Add too little automation and you don't cover many use cases. And networking is not just about wifi, it's at least about ethernet and VPN as well. Some tools already exist to handle aspects of this (e.g. ifstated(8), trunk(4), interface priorities managed with ifconfig(8), a ton of ipsec tooling), and should be properly integrated in the design. Another question is how to integrate with desktop wireless tools that come from Linux (e.g. wifi network pop-up menus for KDE4 and Gnome3) which usually require a backend using Linux-specific ioctls or dbus/NetworkManager/systemd APIs to function. But seamless integration with desktops would be outright awesome and make the system much easier to use for non-technical users. There's probably a couple of gsoc projects worth of work in this. If someone is seriously interested ("no talk without diffs attached" kind of serious) in pursuing this I might be available to act as a mentor.
mpdehaan2 11y ago
Watching Linux distros push essential functions into the Desktop layer (power management, network management, etc) without good CLI equivalents limited my window manager choices in the past. This was mostly because the Gnome/desktop folks at RHT were willing to do the work, and there wasn't anyone else to do it, and then that's what happened. What this did though is pretty much make it where Gnome was the only usable option, or you had to fight a good deal to make something else usable. as Fedora's desktop choices seem particularly rough, and have pretty much left me with using Linux in VM environments from Macs. This is very quickly becoming the default for most developers I know, with a few exceptions here and there. I don't think systemd hurts too bad in the service statup environment once you rememer the commmands are all different, but I don't like what it's doing with creeping into other areas, like what it does with logging.
- icebraining 11y ago
  I don't know about power management, but I've used nmcli for network management without much difficult, and nm-applet works outside of Gnome as well. I've never felt constrained to use Gnome, which is just as well, since I run Awesome launched by "startx".

weland 11y ago

> For example, another one would be connecting to a VPN, a task that NetworkManager greatly simplifies, assuming that such integration is available of course (e.g. if you think connecting to a Wifi network is problematic, try connecting to a L2TP over IPSec VPN). That's because there is equally no uniform and simple way to connect to use those, either. The problem is that the "simplification" that NetworkManager provides is illusory. Yes, it provides an interface that is easier to access, and all the complexity is moved in the back, where it's handled by NetworkManager. Unfortunately, the mechanisms through which it does that are fiercely complicated, too. I've had NetworkManager break on me countless times (I worked for a company that developed networking equipment for a while, so I've interacted with NM a lot), for a lot of silly things -- making me end up with slightly incorrect configurations or reapplying settings at weird times for no apparent reasons. The end result is anything but simplified: not only do I have to deal with the inherent complexity of a quirky VPN connection -- now I also have to understand how NetworkManager reasons about it and figure out where it's wrong. I also think it's misguided to have a single tool handle things so disparate like VPN and WiFi. It's not like you're ever going to be able to expose those through a unified interface -- NetworkManager's own D-Bus-based API being a prime example of that. > There's also the issue that the simplicity exposed in your example is a little misleading. Will the system persist that command and re-execute it on boot? Will it remember my previously used Wifi networks and connect automatically should I want that? How can I view the available Wifi networks in range? Being able to connect to a Wifi network using a simple ifconfig command is great, but the notion that your 80% of use-cases is the same as everybody else's 80% is misguided at best. You scan for networks with ifconfig <interface> scan. The system will not persist commands (arguably, a good decision) but persisting those settings is pretty easy -- you just add the same parameters you pass to ifconfig in /etc/hostname.<interface name>. (The same parameters as in argv[1:n]). The only thing it won't do out of the box is automatically connect to previously used wifi networks. I suspect none of the OpenBSD developers want that. I only needed a feature like that once, a few months ago when I moved to a new apartment and had no Internet connection of my own (cable company is shit) so I had to snoop from the free wireless of nearby cafes. The fact that the interface to ifconfig is so simple and uniform meant that the whole thing was a ten-line shell script to scan for, and connect to previously known networks, and a shell alias to save the current network to the list of known networks. There's an even easier way, using virtual networks, but I didn't know about it at the time. > So you're saying that xBSD is simpler / better, yet you can't use it on your laptop, as it lacks things you need. Well, no shit. I have a Windows laptop, which I also had when I ran Linux. My day-to-day laptop runs OpenBSD.

xorcist 11y ago
Network Manager still has problems. I've had a lucky streak for a few years where it hasn't given me problems, but the other day the GUI decided not to save my settings anymore. It looks like it does, but it doesn't. If I kill the beast and tap in the commands it just works, but if I run the daemon it keeps feeding the backends with old settings. How do I debug this? There's just sockets and layers of GTK. I'll probably end up doing whatever voodoo I need to keep it away and give it another few years.
- weland 11y ago
  dbus-monitor ( http://dbus.freedesktop.org/doc/dbus-monitor.1.html http://dbus.freedesktop.org/doc/dbus-monitor.1.html ) and a lot of patience are your friends. I know of no other method.
- fragmede 11y ago
  In case you're actually interested in fixing that particular problem, it's probably polkit that's gone bad. To examine the issue further, nm-connection-editor is a separate binary that you can run from the command line, and it'll print errors on stdout - including what it's unable to do.
stsp 11y ago
> The only thing it won't do out of the box is automatically connect to previously used wifi networks. I suspect none of the OpenBSD developers want that. That's not true. OpenBSD developers want this. There are several ideas floating around about making the kernel cache wifi passwords, scan and re-connect automatically when it lost link to the AP. This topic keeps coming up during hackathons. For various reasons it's not as easy to do as one might expect. The net80211 layer and wifi device drivers don't keep track of link state to the AP at present. This would need to be implemented first. It is essentially client-side roaming support. One way of doing this is to count missed beacons and assume the AP is out of range if no beacons have been seen for a while. Some devices provide such counters in hardware, some don't. The biggest part of the challenge is to make this work seamlessly with _every_ driver. Then there's a risk of feature bloat. Add too much automation and you end up with something opaque like network manager which just pisses many people off. Add too little automation and you don't cover many use cases. And networking is not just about wifi, it's at least about ethernet and VPN as well. Some tools already exist to handle aspects of this (e.g. ifstated(8), trunk(4), interface priorities managed with ifconfig(8), a ton of ipsec tooling), and should be properly integrated in the design. Another question is how to integrate with desktop wireless tools that come from Linux (e.g. wifi network pop-up menus for KDE4 and Gnome3) which usually require a backend using Linux-specific ioctls or dbus/NetworkManager/systemd APIs to function. But seamless integration with desktops would be outright awesome and make the system much easier to use for non-technical users. There's probably a couple of gsoc projects worth of work in this. If someone is seriously interested ("no talk without diffs attached" kind of serious) in pursuing this I might be available to act as a mentor.

mpdehaan2 11y ago

Watching Linux distros push essential functions into the Desktop layer (power management, network management, etc) without good CLI equivalents limited my window manager choices in the past. This was mostly because the Gnome/desktop folks at RHT were willing to do the work, and there wasn't anyone else to do it, and then that's what happened. What this did though is pretty much make it where Gnome was the only usable option, or you had to fight a good deal to make something else usable. as Fedora's desktop choices seem particularly rough, and have pretty much left me with using Linux in VM environments from Macs. This is very quickly becoming the default for most developers I know, with a few exceptions here and there. I don't think systemd hurts too bad in the service statup environment once you rememer the commmands are all different, but I don't like what it's doing with creeping into other areas, like what it does with logging.

icebraining 11y ago
I don't know about power management, but I've used nmcli for network management without much difficult, and nm-applet works outside of Gnome as well. I've never felt constrained to use Gnome, which is just as well, since I run Awesome launched by "startx".