Discussion on:

NetworkManager, the Fifth Horseman of the Apocalinux

no really.. I do..

Before the networkmanager-kde and networkmanager-gnome packages one had to deal with wpasupplicant by hand or use one of various flaky GUI interfaces. Network manager has been a lot less hit-and-miss than anything I've used in the past.

Wired is a "whatever". It just works thanks to hardware standards, dhcp and easily manipulated values. Want a different ip? "ipconfig eth0 192.168.0.2" and now your IP is .2 so wired we can ignore for now.

Wireless though. One has to scan for wireless networks, authenticate using wpasupplicant and finally toss out a dhcp request or set static IP values. If I'm not going to startx then I'm doing this by hand or with scripts that store credentials in clear text on the drive. This means connecting to a static SSID isn't so bad the second time outside of the clear text issue but connecting to new SSIDs always sucks; can I find it in the network scan, what encryption do I need, why won't wpasupplicant work this time, have I edited/created all the relevant config files and scripts? ... SSSSucks..

At least networkmanager gives this somewhat of a standard process across systems and wireless networks. It manages the wpa encryption, scans for wireless networks, manages dhcp issued or static IP, manages per connection prefered DNS servers.

Now, it's not perfect either.

- it has issue when a wireless networks disapear and reapear; reconnecting can be a pain leading to networkmanager crashing itself (a router reboot or wireless radio reset is enough to cause it)

- manually adding new wireless networks can be a pig of a task and more than once when scanning for the new wireless network and saving it's profile, I find out that Network Manager simply over-wrote an existing unrelated profile instead of adding a new one.

- it does not provide a way to specify binding order. Sadly, Windows does a better job of this; I can simply open advanced settings and say "if you have a wired connection, use that instead of wireless".. with network manager, I have to disable wireless and force the system to use wired or I have to live with wired (Gbit) running at the speed of wireless (54MB'ish) and neither option is acceptable. Binding order is not complicated enough to justify this kind of grief from Network Manger or the kernel NIC management.

I'd personally like to see more improvement in Network Manager unless someone can deliver a management utility which actually improves on it's functionality and stability.

(now, gotta go back and give the article more than a quick skim over..)

Dicking around with NetworkManager reminds me of the days I did a lot of contract work for small businesses using MS Windows desktops. Specifically, using software like NetworkManager tends to require rethinking how I use the computer, forcing me to maintain a more ephemeral relationship with my applications and general working environment, because at any time it may turn out to be easier to just reboot the damned machine than try to fix a networking hiccup. I remember many occasions where for some reason MS Windows would just "lose" the network -- wireless or otherwise -- and after screwing around with it I'd discover it would have been much easier to just reboot the machine. Changes in network configuration would, of course, cause MS Windows to "lose" the network, but so would the alignment of the stars, as far as I could tell. NetworkManager does much the same stuff.

The thing is . . . while NetworkManager makes things really smooth and easy and automagical when it works correctly it does so at the expense of making things nearly impossible to fix when it doesn't work correctly. Meanwhile, writing a couple of wrapper scripts for ifconfig , /etc/network/interfaces , and wpa_supplicant may require a bit more work to get started, but once you figure out how to make stuff work that way it always works . Even if you encounter an edge-case where things break, it's pretty trivial to fix, and it works deterministically. It doesn't wipe out your configurations, throw away a working network connection just because there were a few seconds of dead air, or pick networks seemingly at random so you end up connected to the wrong damned network. All of those behaviors, as you've pointed out, belong to NetworkManager; it works in a way that seems decidedly non-deterministic, much like MS Windows configuration.

I'd rather wrestle with configuration files than fight with a tool like NetworkManager that, when it fails to do what I want, offers no recourse for addressing the problem.

Ultimately, rather than throwing away all the deterministic operation of the underlying mechanisms already in place and replacing it, the correct approach to giving users a "friendly" interface would be to write software that serves as a "friendly" interface to those underlying mechanisms. In short, layer a GUI over the modular operation of what's already there, in the spirit of the Unix philosophy; don't throw away what's already there in favor of a tightly coupled, closely integrated, monolithic Thing that tries to make your decisions for you and refuses to let you get under the hood, in the spirit of the Microsoft Windows philosophy.

Agreed. That's really what Network Manager should be. My dad isn't going to learn command line so a helper app is a requirnment but there is no reason the helper ap shouldn't be using the existing back end applications. Heck, give KDE Wallet a cli friendly point of connection so credentials can still be managed centrally in an encrypted database without being limited to KDE gui apps. Wallet gives the added function of complaining when a new app tries to access data (or in my case, the first time each session that an app requests access).

(vpnc interactions could be improved as well)

No recourse though.. that does suck. I guess I haven't been playing between cli and gui wifi management enough to have noticed. I do have to hank Backtrack for forcing me to learn cli management though finding networkmanager seemed like a well integrated update to wicd on the GUI side.

In terms of Windows, the grief I'm finding results from bad drivers mostly. T60s are notorious for forgetting they have a wifi nic if I accept the driver update from Win Update or Thinkvantage. That and cell dongles who's driver developer's brain damage I can only guess wildly at. What should happen; plug dongle in, OS sees standard NIC, dongle deals with the authentication and cell network connection based on it's SIM card. What actually happens; huge flaky bloated one-off network manager utility hijacks the OS usually with a lot of breakage of existing Windows managed profiles and both providers in our area ship the same piece of sht hardware; thanks Rogers and Bell, way to deliver the most intrusive and user labour heavy solution.

Outside of those two issues, WinXP wireless nic management has been solid for me and Win7 a welcome update (neither is remotely perfect but for one as an update to the other, it's an improvement).

With this discussion, think I'll look back at the wifi scripts I did for Debian initially. It'd be nice to drop the extra resource weight of deamon and related task bar application. For the amount of terminal windows I keep open it's not like I don't have one an easy alt-tab away when needed.

Now.. where is Dcolbert.. must be busy today. I'd expect him to be all over this topic grinning ear to ear and waving cheer leader puffs (but please.. dcol, shorts.. not the mini skirt this time )

now that I think of it.. I wonder if network manager is my grief with SSH. I can forward to a dynamic port and proxy my cli network traffic.. wget returns my proxy IP when checking whatismyip but will Firefox or any GUI app recognize the SSH proxy forward? Heck no.. I've been completely cut off quick and dirty SSH network proxy connections since Debian 6. It suddenly seams very likely that the issue is Netowork Manager not handling things as it should if it's related to how the GUI apps punch through KDE to get network traffic.

If my apps suddenly work after ripping out networkmanager, that's the story I'm sticking with.

Yep, 100% :

Changes in network configuration would, of course, cause MS Windows to "lose" the network, but so would the alignment of the stars, as far as I could tell.

One minute the MS network is working, the next 1 - 24 hours you're trying to figure out why it isn't. And MS is so helpful after failing to find a troubleshooting solution offers to search online for a solution. If MS could go online I wouldn't need help or those ridiculous non-helpful event messages.

Linux is moving towards a ease of use interface. What you point out and the article author fails to note, is that you can still write scripts, edit a configuration file, install a package, read helpful error messages to re-establish a connection, or fix a problem.

Had some fun reviewing my cli networking scripts in the process along with the happy outcome of removing the dependency of a GUI from my network connectivity.

Sadly, GUI apps still refuse to tunnel through an ssh proxied port. The Foxyproxy icon just spins and pauses and spins and pauses.. no luck hard setting proxy entries either. I can send curl out through a proxied port from cli though so I'm thinking it's something in KDE4 giving me grief. Drag.. I was hoping to blame that bug on network-manager and get on with enjoying adhoc proxying (used to test server builds from remote locations and other work tasks in addition to home fun and mobile safety).

I believe the author's complain was also more to do with the classic cli apps being left to get stale or become incompatible with GUI layer apps. Where we should have GUI front ends for cli back ends, we're seeing GUI apps that do it all themselves or rely on one-off tweaks of cli apps which breaks scripting and hampers those who prefer the cli world.

Overall, clie, power user gui and ease of use gui are all welcome developer targets. I just don't want to see easy GUI replace the other options.

In the process of fighting with my networking issues on Debian, I discovered that when I had at first thought I had removed NetworkManager there was still a NetworkManager daemon running, even after having restarted the entire laptop. It's a bit like RealMedia software that way, I guess -- doing its level best to undermine any efforts to remove or deactivate it.

> I believe the author's complain was also more to do with the classic cli apps being left to get stale or become incompatible with GUI layer apps. Where we should have GUI front ends for cli back ends, we're seeing GUI apps that do it all themselves or rely on one-off tweaks of cli apps which breaks scripting and hampers those who prefer the cli world.

That's pretty much the whole deal, except for one thing:

It's not just about preference. It's also about the fact that, when all else fails, one of the benefits of the Unix philosophy is the ability to dig into the simple tools under the hood to fix the problem. That capability is essentially being tortured to death by software like NetworkManager.

As I said in the article, it's still better than MS Windows that way -- but it seems to be rushing headlong toward the MS Windows way of preventing users from doing that sort of thing.

I don't think it was anything malicious trying to undermine your efforts to uninstall it. Any time I've blown it off a system it's gone clean. I also boot to text terminal with network-manager not loading until I kick off X or start it by hand. My first config tweak after installing or updating X; "update-rc.d -f gdm remove" ("kdm" for KDE users).

Offhand, did you remove from gui package manager, aptitude remove or aptitude purge?

Oh.. another variable. I'm selective about my packages and do it all form the command line. In the beginning I did an aptitude install network-manager-kde leaving it to drag network-manager in as a linked dependency. If both are specified seporately at install both will need to be specified during the removal. I'm not sure if the install method would have specified them seporately.

"when all else fails, one of the benefits of the Unix philosophy is the ability to dig into the simple tools under the hood to fix the problem"

Agreed. I figured that was already implied by the mention of preferences, issue with back end utilities being left to go stale and statements that GUI utilities should be front ends for the cli tools not replacements. Clarification is never a bad thing though.

In terms of The Windows Way (tm), it would be the end of an era to see a true parent distro like Debian go the automagical bloat route but I can't see there not being a distro for the gearheads still.

> I don't think it was anything malicious trying to undermine your efforts to uninstall it. My first config tweak after installing or updating X; "update-rc.d -f gdm remove" ("kdm" for KDE users). If both are specified seporately at install both will need to be specified during the removal. I'm not sure if the install method would have specified them seporately. In terms of The Windows Way (tm), it would be the end of an era to see a true parent distro like Debian go the automagical bloat route but I can't see there not being a distro for the gearheads still.

From what I've heard, it sounds like Arch takes the best ideas from Debian and Gentoo, and leaves out the problems of Gentoo and has not been following Debian's apparent descent into Ubuntu-hood. FreeBSD, in my experience, has been better than Debian ever was (since I started using Debian heavily almost a decade ago) anyway, though. Given that I also prefer the BSD core utilities over the GNU core utilities, and like the BSD license more than the GPL, I'm unlikely to do anything with Linux-based systems again for a while for my own purposes; I'll go back to doing pretty much nothing but some system administration and occasional troubleshooting for others on Linux-based systems (and some development testing, of course) once that single driver issue gets sorted out for FreeBSD.

yeah.. I can relate to your grief. I thought networkmanager was using the regular cli stuff in the background and that the cli stuff was actually being maintained. Not sure I've tried to attach to an unprotected wireless though.

Regular users are not going to script. I love that scripting is an option but there needs to also be GUI "average user" options. Neither should replace the other though; either way should be usable even when both are installed and Network Manager type things really should be GUI front ends using the same back end software as the cli and scripting methods.

I'm also sticking with KDE4 which seems to have less arbitrary dependency links. aptitude install networkmanager-kde and off I go with the few grievences mentioned previously. I guess if you require Evolution, gnome means installing less rather than doing KDE plus Evolution plus what it drags in from GNOME. For me, Evolution remains a no-go until mapi for modern Exchange servers is supported. Until then it's the browser interface or a Windows vm for Outlook.

I like that Canonical is working closer with Debian now. I just really hope Debian resists the poor dependency choices Canonical likes to make along with many other Canonical config choices. I came from Mandriva to Debian because of it's more granular dependencies and more sane config file layout. Debian dev's, please don't push me towards Arch.

I wanted to uninstall Evolution. The problem was that uninstalling Evolution would have uninstalled GNOME, which was part of the pile of grabage I had to install to get this thing running in under 24 hours in the first place.

> I like that Canonical is working closer with Debian now. I just really hope Debian resists the poor dependency choices Canonical likes to make along with many other Canonical config choices.

As the situation with Evolution should illustrate, Debian has not Debian dev's, please don't push me towards Arch.

Too late for me. Next time I need to use Linux, I'm almost certainly giving Arch a try.

.

nt

... will usher in the rise of the Beastie.

has Immanentized the EschatOS?

I've thought about it, and come to the conclusion that the EschatOS will be immanentized in 2038, or thereabouts. I'm thinking maybe 19 January 2038, early morning -- maybe something like 03:14:07 UTC.

Stop. It's Unix time.

I must be on the right wavelength today.

are the ones which bother me as well. The dependency hell is very easy to detect when starting with a minimal install, then adding applications. In order to install and run x , I need mostly unrelated crap y, z, a, b, c. A couple of libraries? I get that, but they should be modular, and follow the UNIX Philosophy. For some tools which should be simple and small, it can be easier to just install apps ported over from BSD. But that only covers so much.

Ubuntu, specifically - blech. For something like that, I'd rather use a derivative form like Mint, still with the stupid sudo and no easily configurable root account and access. (In which case the Mint rolling Debian distro might be better.)

And since I do like a GUI, but don't care much for full-blown Gnome/KDE, it's annoying to have to install them anyway to have some functionality or apps otherwise lacking.

And it still burns my ass to not be able to install the latest XFCE on *BSD because of the sad nature of the GNU's Linux-centric/only thinking.

[ well not really ]
Mandriva has network profiles you can use.
set up your default connection [ home for example ] then copy the profile in the jquery ui perl script control center, and activate the copy, make the settings changes for connection to a public access system, no connection encryption used.
at BOOT time it tosses a network profile choice option up, default if at home, so no need to touch anything.
select the other profile [ if more than 2, the one for where you are ] when applicable at boot and up and running, no changing anything needed.

and silly RPM hacks in urpmi breaking package management.. booo.

whole seperate issue though.

the multiple profiles for network connection issue has so far best been addressed by Mandriva. doesn't mean there aren't other options, just Mandriva has made it the easiest to work with.

and they do have a cli version of all their control center tools included, the jquery ui is for when in a gui.

My understanding of the old GUI vs. non-GUI discussion is simply this:
There are people who just want to drive a car (GUI) and there are others who want to understand how a car is working and possibly apply some changes according to their taste (non-GUI). From time to time there are drivers who get curious about the "how-to" and mechanics who just want to drive.
So, let's have as much shades of gray as possible between black and white to make them all happy

That's the common comparison but command line can often be "just drive a car" also when the task is not really in need of a graphic layer.

Some people want to just get in the car and find stearing, pedals, lights, a radio and temperature control (cli) and some people want every bell and wistle under the sun (gui).

My example from last night. I can boot my computer and tell it to connect to my home network with a clean simple command or I can start up the GUI and use a conveluted graphic utility to connect to the network with bugs resulting from it's unnecessary added complexity. I can have my network connection made without a graphic layer running or I can make having Gnome/KDE or whatever running a requirnment for getting a network connection. I can check for newer software updates and have them downloaded and installed for all software on my system with a single cli command or I can start a graphic desktop, start a graphic package manager then click a few more times for what results in a far more conveluted process than the single command cli method.

It's really not as simple as cli = gearheads, gui = average drivers as some tasks are far less complex to acomplish by command line than by GUI where other tasks are indeed more efficient by GUI than cli.

If I've been somewhere before and connected, my computer connects to that network automatically. And if I have trouble I can use cli or gui as necessary. but then I'm not using Linux and its many splintered, yet oddly tied software packages.

My Windows, osX and Debian boxes can all do that too; remember connections and find/connect when in new locations. That's really not a CLI vs GUI feature but rather a feature of what network managers one has installed. The key point is having the option of using either cli or gui though which is a feature lacking from Windows where it's GUI for managing wifi profiles or nothing. (not sure if osX is using cli apps behind Aqua for that either though).

Now, what really burns me are these "value add" attrocities that come bundled with wifi drivers for Windows these days. No.. I don't need an Intel branded network profile manager just because I'm installing Intel wifi drivers; the Windows one works fine. And why are those nifty cell network dongles presenting a standard wifi or, better yet, NIC to the OS on this side of the usb plug; they have a sim in them already so use that to authenticate with the mobile network and let the OS manage it like any other NIC. WTF is this bloated flake of a connection manager I have to install before the stupid dongle will connect? (Bell, Rogers.. looking at you and your crappity selection of cell radio addons). Honestly, that alone is enough to make me simply get the little cell to wifi router boxes (Myfi?). But that's what one has to go through just to get a cell network device which doesn't require dirtying up the computer OS it's providing connectivity for.

If you do not exercise positive control over your network configuration, you are inviting security issues into your life. You should remain in conscious command of when your laptop connects to any networks, rather than just letting it connect to whatever's around willy-nilly.

Your conflicting with my plans to take over the world through rogue access points.. and I won't stand for that!

Nah, I'm not really sorry. I need to delay your plans for taking over the world through rogue access points so that my plan to take over the world through MS Windows exploits has time to come to fruition.

This is not a CLI v GUI post, its about stuff not working, or not working without unreasonable installation requirements. "Choice" doesn't mean rendering the CLI unusable, and you need it to allow your usage spectrum (perfectly appropriate idea) to exist.

Anyone is free to have their GUI, but Unix apps should remain CLI-accessible, and CLI apps should not die off or become otherwise unusable.

When you tried wicd are you sure everything to do with networkmanager was not running? I've gone so far as to uninstall networkmanager in order to get wicd running on not a few systems.

I agree with your positions put forth in the article. I've watched a few of my favorite little tools gather dust and finally fall off the table. Ubuntu's direction is an abomination. I saw in another thread somewhere the opinion that ubuntu is trying to gain the favor of hardware manufacturers by quietly phasing out compatibility with older hardware. The unity/compositing thing is good evidence of that mindset.

It's not too hard to remove the gunk after your typical Linux install, I would suggest looking at Mandriva after a good weeding. With a minimal X install you can run the draktools, which is very much 'old school' in look-n-feel. I haven't found anything broken on the cli either, eg wpa_supplicant. Works as always.

> When you tried wicd are you sure everything to do with networkmanager was not running? I've gone so far as to uninstall networkmanager in order to get wicd running on not a few systems.

I uninstalled it, too. Wicd just didn't want to work. I found several references to how to get around broken DHCP interoperation with Wicd online, and none of the proposed solutions worked out for me. I eventually gave up on it when I discovered the cnetworkmanager I saw in another thread somewhere the opinion that ubuntu is trying to gain the favor of hardware manufacturers by quietly phasing out compatibility with older hardware. The unity/compositing thing is good evidence of that mindset. It's not too hard to remove the gunk after your typical Linux install, I would suggest looking at Mandriva after a good weeding.

Much of the problem revolves around the fact that these systems seem to be bent on forcing everyone into an "all or nothing" approach. If you want some simple GUI tools, you're likely to need all of GNOME, even if you're using some minimal window manager like i3 and ignoring GNOME, for instance.

I was unable to get graphics working properly on this thing in under a day without installing the basic "desktop" setup, which comes with GNOME. Once that got on the system, I was unable to get networking to work without keeping NetworkManager on the system. NetworkManager wouldn't work without GNOME. Trying to uninstall Evolution made APT try to uninstall GNOME as well.

Ultimately, what it boils down to is that all these intertangled dependencies and the brokenness of GUI tools when doing anything nonstandard ensures that, even if there's a way to get exactly what I want working, it has gone from a matter of maybe twenty minutes' work to get it all set up half a dozen years ago to taking more than a day now -- more than a day, because that's how long I fought with it before giving up and doing things the "all things to all people" GUI-centric way that requires installing almost everything under the sun. Now that it's there, I can't rip it back out without breaking everything.

I bet you dollars to donuts that Mandriva doesn't clean up much more easily, though maybe some of the basic functionality I miss works better. My previous experience with Mandriva (admittedly a few years ago) actually showed it had worse issues in this area than Debian at the time. If Mandriva has remained static on this kind of thing, I suppose it might now be better than Debian (which has gone downhill far enough to be notably worse about this kind of thing than Mandriva was back then), but I'm skeptical.

. . . and, frankly, even what Mandriva was back then was not good enough for my purposes. I'm going back to FreeBSD as soon as I can with this laptop, and if I need a Linux-based system again I'm probably going to try Arch, which I hear is great for people who like a system with Tools That Work™.

Mandriva Free DVD, minimum install to get past the first boot, urpmi in only what you need and you shouldn't have any gunk to remove. Mandriva Free installs was where I cut my buildscripting teeth after Red Hat ftp installs taught me the minimal first boot step. (and boy did it suck when an ftp install lost connection and left one starting from scratch again)

but, the Free version of the Mandriva or should I say Red Mandriva now... is basically like a trial with very many limitations. like your thinking .> however, much is to be said about the bad ftps . . . I guess we're going to have to go back to the scratch-board and re-build a fully Self-Supporting-OSP for the sake of running ISO Linx and the few others. . . SPARC (anyone(...? ) )

just remember who is responsible for all of this OEM madness, it is actually Microsoft and divisions of Intel. Yeah , I kid U not > > > > http://www.linux.com/archive/feature/23279

Responsiveness to environmental changes.

The entire Linux concept is about instant adaptability. Mac and Windows users are basically stuck with whatever Apple or Microsoft offer, whenever they get around to offering it, however they choose to implement it.

However, like Chad says, there are forces within the Linux world who would like to drive several distributions into the same Mac/Windows mode. That's not necessarily a bad thing. It provides a good transition from Mac/Windows environment to a different, but somewhat familiar environment of Linux. But that's what it should be, a transitional environment, not the mainstream one.

I don't use Ubuntu, especially since it has gone so far away from the Debian Core and X Windows files registry/depository. I wish that soon they will come out with some more stable & non-stable revisions of the old gnu-src-shells for the sake of raw GNOME and GIMP production. This type of dev was a phenominal way for people to connect to OpenSUSE, YellowShell, CentOS, and Redhat Beta, all in a snap. Yeah , I know that some of these combinations are dangerous and they lead to tons of un-identified and potential worm-threats. But at the same time a lot of these things are still do-able anyways and it is up to us to release a better candidate for full-blown use. The Unity version is cool and all, like a large scalable resource-fork to Ubuntu, just as Fedora has done, but it is still very limited as far as foundation elements and core frameworks go. Hopefully, the Sabiyan Community will open the red doors once again for us white and red hats out there.

I'm late to this party and I agree with Chad's overall premise, but I'm not convinced that Ubuntu is necessarily the guilty party here. I decided to reacquaint myself with Linux a few years back (initial limited experimentation in 1994 & 1995) by installing Debian 3 (Sarge). I quickly learned that I couldn't get the Kmail app or any PIM application without also installing a full bluetooth stack.

Similarly, I bought a new HP printer for my mother's Mandriva 2008.1(Spring) computer a few years back. Since the printer was too new to be supported by a binary package from Mandriva, I had to install HPLIP from source. I couldn't believe my eyes when a dialogue appeared asking which MTA I wanted to install.

That's right. One of the libraries or other build dependencies for HPLIP had a full MTA (Postfix/Exim4/sendmail) as a sub-dependency!

Shame on me- I never started fresh and loaded each package individually to determine exactly where the bogus dependency came from and report it as a bug. Nevertheless, some lazy package maintainer had simply queried all packages installed on a system and made them all dependencies for that package.

of legend are traditionally practitioners of the "Black Arts", and common folk should always give careful consideration before engaging one. Frequently, their services will result in unwanted and sometimes horrendous consequences to the novitiate, up to and including the loss of their very soul. buwahahahahahahaha!

Sound familiar?

"Do not meddle in the affairs of wizards, for they are subtle and quick to anger"

Also, they are frequently loons.

Starting with a "normal" install and ripping out dependencies ALWAYS leads to headaches. I start from Debian netinstall media, and install what I want. Right now, I've got a Window Maker setup I really like. I have a dockapp that monitors wifi signal strength (and really, that's the only network info you *really* need superglued to your desktop), and do the actual management with wicd-curses in a terminal or wicd-gtk launched from the menu.

As to your dhclient woes, I'm stumped. I've been using Debian Testing since it was Lenny, and have never run into that problem with or without NetworkManager installed. I do wish iwconfig supported WPA(2) networks - that's the only missing from being able to run your networking with basic shell commands.