NetworkManager 1.0 Released After Ten Years Development
An anonymous reader writes: After ten years of development focused on improving and simplifying Linux networking, NetworkManager 1.0 was released. NetworkManager 1.0 brings many features including an increasingly modernized client library, improved command-line support, a lightweight internal DHCP client, better Bluetooth support, VPN enhancements, WWAN IPv6 support, and other features.
One of the few unix command line tools whose command begins with a major letter.
The most important feature is that it can be disabled, masked and unistalled without loosing functionality, as oppposed to other new TM things that I can't get rid of that easily
Sure, you can also do it via cli (with more tools than just those you mentioned), but, do you remember all the steps?
Why remember them? Dump the commands into a script and just run it.
Can you automate it?
No, of course not, because command line tools are the absolute worst for automation. </sarcasm>
That said, if you're dealing with wireless, I'd suggest using wicd instead of either. Less shitty than NetworkManager, less complicated than command line, and it has multiple front-ends including gtk, qt, ncurses, and CLI. I started using it years ago because NM tended to break horribly and every few updates it would lose the ability to connect to hidden APs. Meanwhile, has always "just worked" and has been completely forgettable, which is probably the best compliment that kind of software can earn.
And that's really the problem with Linux. It's a great server OS - but in the end, as a desktop OS it just stinks because all the developers scream when you try to "complicate" matters using tools like systemd, NetworkManager, PulseAudio which are essential to make a modern desktop OS.
For networking you need to consider the mobile use case - home user is at home, and firewall is set up to allow services so they can stream their music and whatnot all over the network. They move their laptop to a wifi hotspot, and now the network stack should reconfigure itself to the hotspot. But oh, the firewall rules need to resync because the home user isn't at home and is in a public place, so maybe having those services exposed is a bad idea. (In an ideal world, you'd really have NetworkManager tell systemd or init to shut down those esrvices).
That's a common scenario - user moves between trusted and untrusted networks, and something needs to detect what kind of network it is, then manage the firewall, DHCP and other things altogether.
Perhaps if you're lucky, it's switching between Ethernet and WiFi, which means you can statically configure the whole thing, but more often than not, it's on the same interface. Or maybe it's both - a laptop user connected to a public guest network AND a private wired network. Or vice-versa. Or maybe both networks are the same.
Ditto audio - while a server doesn't need audio, a desktop user does, and it has to handle the variety of APIs to access audio, the need to provide for multiple audio routing paths because as audio devices appear and disappear, the preferred routing may change - e.g., switch between onboard speaker+mic to Bluetooth headset for communications WHILE still playing audio (movie or music) through stereo speakers plugged into the line out jack. Then when Bluetooth disappears, mix communications audio (or mute the movie/music) if a call comes in. Audio mixing is important for multiple audio sources - perhaps you have a few YouTube video tabs open and are listening to something else - it's a PITA to stop that just to get audio for YouTube because it needs to release the audio device.
It's amazing how, despite Linux being an advanced multi-tasking OS, a lot of things are still stuck in the single-tasking world that developers think is all you need. Maybe a decade ago, but modern day PCs are so much more capable.