Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I really do not understand the point of NetworkManager in Linux. Why does it replace the old methods of managing connections in Red Hat, for example?

share|improve this question

closed as primarily opinion-based by dr01, cuonglm, Archemar, don_crissti, garethTheRed Sep 29 '15 at 13:52

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

i'm not sure this question is actually answerable as you've asked it. – ixtmixilix Jun 18 '12 at 16:41
up vote 7 down vote accepted

Mostly to make configuration "just work" smoothly when one has a diversity of connection methods (many different Wi-Fi networks, Ethernet, 3G, Bluetooth etc...).

Configuring some of those by hand can be a hassle, specially when you only need them temporarily (e.g. on a laptop).

Of course, one can fall back to the older config and do it by hand or use, e.g. system-config-network (on Red Hat). Also other network configuration tools (like wicd, though it doesn't supports 3G or Bluetooth) are available.

share|improve this answer

The question is really hard to answer as different people have different needs. For some purposes network initscripts are perfectly sufficient, for some they are less practical and some are not implemented at all.

The classic initscript solutions (including RH/Fedora network initscript) works by configuring interfaces at boot time or when the administrator requests it. That is fine.

The initscript solutions are often used together with some kernel based triggers that listen to kernel events (carrier events, wifi scanning results, etc...) and perform tasks on behalf of the administrator. That's the good old way to handle dynamic events without long running processes.

But then even for basic tasks like DHCP client machinary initscript solutions start long running daemons. The same applies to IPv6 router discovery. That's even worse as those daemons are hard to track and therefore developers usually attempt to avoid adding new dynamic features to initscript solutions.

Most distributions are now switching to a daemon based network configuration solution, typically relying on a central configuration authority that either does everything in one process or starts and tracks other processes properly. For OpenWRT users it is netifd, for users of minimalistic network setups it is dhcpcd (not just a DHCP client despite the name), for infotainment systems and some laptop users it is often connman but for most universal distributions it is NetworkManager. There are other options of course.

share|improve this answer

It is for integration, the good old way is too resource based to be efficient (file edition, service restart..). Now things are working along with event busses, shared apis and stuff like that, so a lot of "managers" that are service providers appeared. Anyway if you don't use a evolved desktop manager, you can still do everything by hand.

share|improve this answer
I still do not understand the point. Can you explain more? – David James Jun 18 '12 at 16:01
@DavidJames Author meant that design of whole subsystem is better from performance point of view. Programs can exchange data in many ways. In old times, saving&reading files, restarting programs (e.g. daemons) was enough for discussed purpose. Nowadays, things got more complicated and we use different means to achieve much faster performance (Aurelien mentions about all details, search on internet to find answers) – Grzegorz Wierzowiecki Dec 27 '12 at 22:10

Not the answer you're looking for? Browse other questions tagged or ask your own question.