From Windows to UNIX: Monolithic to Modular Design
-
There are endless differences between the Windows and UNIX worlds. One of the key ideological differences between these products and their resulting communities is the idea of approaching system design and system utilities as a monolithic (all in one) or modular (many small pieces) approach. Neither of these is right or wrong, but people moving from one environment to the other are often surprised at how these ideologies manifest themselves for system administrators.
In the Windows world, tools and applications tend to be highly monolithic. At the high level, this can be see in big applications like Microsoft Office with nearly all common business tools built into a single package. Or with system utilities that generally have all major features built into a single tool, requiring no outside tools for general use. At the lowest level, Windows applications are highly likely to be built with all dependencies, or most, included in them.
On the other hand, in the UNIX world we tend to see the opposite. End user applications tend to be smaller and more individual tasked focused. This often requires getting multiple applications, but smaller ones, to do the job of a single package on Windows. System utilities reflect this mentality similarly. UNIX system utilities tend to be extremely tiny and singular in their mission and doing many tasks assumes that small utilities will be used together, often literally together with commands strung together with one feeding into the next. This requires learning UNIX to learn many more utilities, but each one tends to be very simple on its own. It is also very common, especially on Linux, that packages have broad inter-package dependencies with common libraries being shared rather than baked in. Very different from standard Windows approaches.
Learning to think in these terms can be very beneficial for the Windows Admin moving to the UNIX world. Getting used to the idea of learning many small commands and utilities and planning to put them together into building blocks of a bigger solution is common and expected.
Part of a series on Linux Systems Administration by Scott Alan Miller
-
I can appreciate the idea of breaking all of these things apart, but at the same time, what happens when something that is dependent upon something else, and the dependency changes something making it no longer compatible?
-
@Dashrender said in From Windows to UNIX: Monolithic to Modular Design:
I can appreciate the idea of breaking all of these things apart, but at the same time, what happens when something that is dependent upon something else, and the dependency changes something making it no longer compatible?
Programs simply would not work...or at best would not install... at worst, they would install and randomly crash leaving you scratching your head.
I wound up re-compiling some of the programs I liked from source to make them work better (not perfect, but better)... It was a lot of fun chasing things like that down...but fortunately, it doesn't seem to be a problem I've come across in a few years now.
-
@Dashrender said in From Windows to UNIX: Monolithic to Modular Design:
I can appreciate the idea of breaking all of these things apart, but at the same time, what happens when something that is dependent upon something else, and the dependency changes something making it no longer compatible?
It's a valid question. Although the nature of small, discrete programs actually itself does a lot to protect against that. Because Standard Input and Standard Output are well defined and using a standard interface and nearly everything interfaces in text across the standard communications channels provided by the OS, this never really happens.
Standard utilities like grep, cut, sed, awk, more, head, tail, and more have not lost functionality since the early 1970s. They are stable and no one would deploy ones that broke that functionality.
In a monolithic world, things would break internal to the application and you would wait to update until they got it fixed. In the modular world, you don't update to a broken individual component. The protect exists fundamentally the same in both places.
-
@dafyre said in From Windows to UNIX: Monolithic to Modular Design:
Programs simply would not work...or at best would not install... at worst, they would install and randomly crash leaving you scratching your head.
This is why there are dependency matching systems that don't just verify dependencies of packages, but of versions of those packages. So things would install and just use the right versions, in most cases.
-
@scottalanmiller said in From Windows to UNIX: Monolithic to Modular Design:
@dafyre said in From Windows to UNIX: Monolithic to Modular Design:
Programs simply would not work...or at best would not install... at worst, they would install and randomly crash leaving you scratching your head.
This is why there are dependency matching systems that don't just verify dependencies of packages, but of versions of those packages. So things would install and just use the right versions, in most cases.
In an ideal world, and for me, most of the time, they did. But every now and again, I'd run into that problem... Like I said before though, I haven't sen it in a long time.
-
@scottalanmiller said in From Windows to UNIX: Monolithic to Modular Design:
@Dashrender said in From Windows to UNIX: Monolithic to Modular Design:
I can appreciate the idea of breaking all of these things apart, but at the same time, what happens when something that is dependent upon something else, and the dependency changes something making it no longer compatible?
It's a valid question. Although the nature of small, discrete programs actually itself does a lot to protect against that. Because Standard Input and Standard Output are well defined and using a standard interface and nearly everything interfaces in text across the standard communications channels provided by the OS, this never really happens.
Standard utilities like grep, cut, sed, awk, more, head, tail, and more have not lost functionality since the early 1970s. They are stable and no one would deploy ones that broke that functionality.
In a monolithic world, things would break internal to the application and you would wait to update until they got it fixed. In the modular world, you don't update to a broken individual component. The protect exists fundamentally the same in both places.
Of course you wouldn't update to a broken component, but how do you know it will break something until you update it? So you yum update and now somethings broke. Now you get to look through the logs at what was updated.. and check what of those things your stuff is dependent upon and then roll them back.. assuming it's that easy.. I guess this isn't that bad.
Just working through the processes in my brain.
-
@Dashrender said in From Windows to UNIX: Monolithic to Modular Design:
Of course you wouldn't update to a broken component, but how do you know it will break something until you update it? So you yum update and now somethings broke.
No, YUM protects you. YUM can be told not to update if it isn't a matching version.
-
@Dashrender said in From Windows to UNIX: Monolithic to Modular Design:
Now you get to look through the logs at what was updated.. and check what of those things your stuff is dependent upon and then roll them back.. assuming it's that easy.. I guess this isn't that bad.
If you have a situation where YUM does not know, then the YUM logs make rollbacks easy, too.
-
@scottalanmiller said in From Windows to UNIX: Monolithic to Modular Design:
@Dashrender said in From Windows to UNIX: Monolithic to Modular Design:
Of course you wouldn't update to a broken component, but how do you know it will break something until you update it? So you yum update and now somethings broke.
No, YUM protects you. YUM can be told not to update if it isn't a matching version.
Cool, that's good to know.
-
There is a lot of power in a managed repo based package management system. The packages know not only what packages they depend on, but what versions they are tested against.
-
@scottalanmiller said in From Windows to UNIX: Monolithic to Modular Design:
There is a lot of power in a managed repo based package management system. The packages know not only what packages they depend on, but what versions they are tested against.
How does a system handle two pieces of software that require two different versions?
-
@Dashrender said in From Windows to UNIX: Monolithic to Modular Design:
How does a system handle two pieces of software that require two different versions?
That's where it gets tricky. Typically, there are so many things that ensures that this does not come up that it isn't an issue (this implies that you are using obscure software or have diverged from the OS packages) but if it does, the second package won't install and will tell you that the needed package cannot be installed and why. This is what happened in our recent discussion about PHP7 and ownCloud 9.0.2. I had PHP installed and ownCloud demanded 5.x. The YUM system catches that I have a version too new and blocks me from proceeding until I address it.
That case was slightly more complex than that, but that's basically what happened. It really is not a common thing as long as you don't try to modify the OS that you are using (which is what I did.)
-
Remember that in a normal case, the OS provides all or nearly all of the "shared" dependencies. So tens of thousands of tiny packages are all tested and "locked" to versions that won't vary. Then software that is written for that OS knows what versions that it will get of nearly every, or actually every, dependency. So the people writing software target that OS and know that people using that OS will have that system. Just like if you write for Windows 2008 or Windows 2012, you know that the set of dependencies will always be the same. Same with Ubuntu or RHEL or Suse. So if it isn't compatible with the base OS, it's on the vendor for not having built to it.
-
I suppose it's less of an issue as well, since Linux Distros are free, you just have another VM running the other software.
Windows, you'd have the Windows tax. -
@Dashrender said in From Windows to UNIX: Monolithic to Modular Design:
I suppose it's less of an issue as well, since Linux Distros are free, you just have another VM running the other software.
Windows, you'd have the Windows tax.Exactly. A VM or a container or an application jail. Lots of options for mediation if you want the conflicting packages.
