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.
-
@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.
