From Windows to Linux: Installation Culture

scottalanmiller

One of the many cultural differences between the Windows and the Linux world is how software is installed. There is, of course, a rumour that circulates that software on Linux is handled by compiling it yourself. This is, quite obviously, silly and untrue. That's not how enterprise software is handled with rare exception and not a good process and is available on Windows, just as it is on Linux and not done in enterprise circles in either case. Linux Admins are often expected to know how to do tasks like that, but not generally expected to do so in a business environment. If it were to be done, it would be done by an engineering role, not an administration one.

What makes the Linux and Windows worlds so wildly different is how package management is handled. It should be noted that this is a discussion about culture, not possibilities. You can certainly use Windows like processes on Linux and vice versa, although the capabilities of Windows for the later is currently very limited, it is expanding.

In the Windows world the expectation is that software is obtained manually, often by going to a website and downloading an installer package. Then the installation is done by clicking on the package itself and it launches a custom installer that installs the package (installs meaning it places the files in a common programs directory and registers itself in the Windows Registry so that other tools can look it up to see that it is installed.) The process is very "one off" and disorganized, but relatively flexible. Installation is effectively ad hoc. Updates are handled by downloading updates to the software and installing them manually as the original software was done or each package may maintain its own system for updating itself (e.g. Google Chrome.)

In the Linux world the customary approach is different in several ways. First, the operating system vendor maintains a rather sizeable repository of software that is tested against and works with the operating system. Software is expected to be installed by an installation system that looks to repositories, pulls software (and any dependencies) automatically and installs it via a central mechanism. This system allows for the central mechanism to manage updates across the board. Software from outside of the operating system's own repository will hopefully come from a custom third party repository which can be added and managed as part of the central system as well. The entire system is maintained for compatibility, patches and updates as a single whole, automatically. Of course there are exceptions and Linux can fall back to installing much like Windows does, but the packages are still managed by the central system providing a slightly improved continuity of tools.

The Linux ecosystem is heavily built around the concept of managed packages. Not managing packages. For someone coming newly into computers, it is extremely natural. For someone coming with Windows ecosystem expectations of seeking out packages on their own and dealing with them independently it can be very confusing.

Also of major difference is that the culture of Windows is for software to be self contained. All of the packages and code needed for an application to run is downloaded and installed with that app and if many apps use the same code, it would be downloaded and installed many times. If a patch is needed for a library, every app that uses that library would be updated individually. In the Linux culture, packages share libraries that are maintained central by the package management system and are installed, as needed, by the applications. If a patch is needed, all software that relies on that library would be patched automatically by the library being patched. Very different approaches.

Different Linux families handle these needs separately, but the general concepts are the same. Because of this package management is more complex, but more powerful in Linux. In the Windows world, learning to install software is not really a task, whereas in Linux learning the ins and outs of software installation is a major thing to learn. But likewise, the time and effort that Linux Admins then need to put into using their system is far less.

To make a quick comparison of the expected method of install for the same package on both systems assuming that we already know the name of the package that we want (when do we install something not knowing what it would be?):

Windows:

Find website of vendor (hope that you already know it, it is obvious or search engines provide good results)
Navigate website for downloads.
Find download that matches Windows version and architecture.
Determine which version is currently stable and appropriate.
Download installer, typically as .msi or .exe
Double click on the installer
Manually step through installation screens

Linux:

Type install command and package name

Results?

Windows gives us an installation with the hope that we went to the right website and picked the right package. There is always a danger that we downloaded the wrong thing and have malware or the wrong package that is not stable. When we need to update the package, we have to go through this process again, for every package on the system.

Linux by default used a key to verify that source of the file so was both easier and more secure. When the package needs to be updated, Linux will both check for this and manage the updates itself, no need for further interaction other than scheduling the automated update of the entire system.

The differences are dramatic.

Dashrender

This solution sounds great from a server perspective, a much more limited number of apps run on servers than what run on workstations.

The culture that since people are willing to pay for windows, allows it's shortcomings to covered by other paid for products instead of someone writing a free, soon to be included or at least in the mention repositories.

In fact the arena that Windows is in is so run by that 3rd party ecosystem that even when MS tries to add functionality to it's OS that could essentially put a 3rd party vendor sector out of business, instead of them moving on, they sue MS to keep them from making the change - just look at the browser wars. The fact that this hasn't happened with regards to Windows Defender just amazes me. The only reason I can figure it's being left alone is that government might realize that the general public is so unwilling/unable/un something that they can't be expected to maintain their systems, so it's for the better status of the internet that it's just included.
but that's just a thought.

scottalanmiller

@Dashrender said:

This solution sounds great from a server perspective, a much more limited number of apps run on servers than what run on workstations.

I wonder how true that is today. As the world moves from legacy to modern business apps, what is left for the desktop? In the Windows world many things run on the desktop because of the legacy ecosystem. But much of that seems to be cyclical - people use Windows before of Windows apps. Break the cycle and suddenly not just some, but all of the factors pushing them to Windows evaporate. The issues are often all tied together.

JaredBusch

I would argue that you Linux step should have a predecessor step. That is to determine the package name. Because if you do not know the package name you will not be able to install it. You may know there is some yum tool for updates. But if you do not know that the package is named yum-cron you will never get it installed.

scottalanmiller

@JaredBusch said:

I would argue that you Linux step should have a predecessor step. That is to determine the package name. Because if you do not know the package name you will not be able to install it. You may know there is some yum tool for updates. But if you do not know that the package is named yum-cron you will never get it installed.

That's true, but it is roughly true with Windows too. You need to figure out the name of what you want to install in both cases. In either case the situation might make one or the other easier or harder. On Linux you can easily search for tools with yum in the name, only takes a second and the results are definitive. On Windows you have to Google for results and hope that the results are valid and applicable.

Windows has a little more slack in finding the package, Linux has a bit more accuracy and tools for finding it quickly.

JaredBusch

@scottalanmiller said:

@JaredBusch said:

I would argue that you Linux step should have a predecessor step. That is to determine the package name. Because if you do not know the package name you will not be able to install it. You may know there is some yum tool for updates. But if you do not know that the package is named yum-cron you will never get it installed.

That's true, but it is roughly true with Windows too. You need to figure out the name of what you want to install in both cases. In either case the situation might make one or the other easier or harder. On Linux you can easily search for tools with yum in the name, only takes a second and the results are definitive. On Windows you have to Google for results and hope that the results are valid and applicable.

Windows has a little more slack in finding the package, Linux has a bit more accuracy and tools for finding it quickly.

you called out windows for finding the website of the vendor. That is really the same as finding the exact package name in linux.

scottalanmiller

@JaredBusch said:

you called out windows for finding the website of the vendor. That is really the same as finding the exact package name in linux.

Sort of. But in one case you have a set list of all safe packages. In the other you have an unlimited list with many dangerous or incorrect packages.

If I know I need a yum tool on Linux, I have all the same means of finding it as Windows plus ones that show me just a list of what is available and managed with yum in the name.

On Windows I lack that key part.

Dashrender

@scottalanmiller said:

@Dashrender said:

This solution sounds great from a server perspective, a much more limited number of apps run on servers than what run on workstations.

I wonder how true that is today. As the world moves from legacy to modern business apps, what is left for the desktop? In the Windows world many things run on the desktop because of the legacy ecosystem. But much of that seems to be cyclical - people use Windows before of Windows apps. Break the cycle and suddenly not just some, but all of the factors pushing them to Windows evaporate. The issues are often all tied together.

I agree with that in general. I am thinking about little tools that I've looked for recently - Windirstat, PUTTY, WINSCP - frankly all tools that should be native in Windows and I can't understand why they aren't!

I agree that it's cyclical windows begets windows. Linux by it's nature free begets free.

scottalanmiller

There are definitely cases where finding something on Linux might be harder, but I think that they are very rare. The chances that you know nothing about the package is low, and what would the equivalent to not knowing it at all on Windows be? Just searching for functionality on Google?

At least on Linux I can also search and then verify in the repo.

nadnerB

Where was this information when I was just starting out on Linux?
(We've been in an on/off relationship for 10 years... mostly off)

stacksofplates

@scottalanmiller said:

There are definitely cases where finding something on Linux might be harder

Unless you're using powershell.

Find and delete all files older than 15 days in a directory

Linux

find /some/path -type f -mtime +15 -exec rm {} \;

Powershell

$limit = (Get-Date).AddDays(-15)
$path = "C:\Some\Path"

# Delete files older than the $limit.
Get-ChildItem -Path $path -Recurse -Force | Where-Object { !$_.PSIsContainer -and $_.CreationTime -lt $limit } | Remove-Item -Force

# Delete any empty directories left behind after deleting the old files.
Get-ChildItem -Path $path -Recurse -Force | Where-Object { $_.PSIsContainer -and (Get-ChildItem -Path $_.FullName -Recurse -Force | Where-Object { !$_.PSIsContainer }) -eq $null } | Remove-Item -Force -Recurse

Disclaimer: I copied and pasted that powershell, so I have no idea whether it's the only way to do that because I have no idea how to use it haha.

nadnerB

@johnhooks Righto, that's a bit unfair, comparing a one liner to a Script.
Lets see about turning that into a one-liner
(evening up the comparison)

dir "C:\Some\Path" | where {$_.CreationTime -le ((Get-Date).AddDays(-15))} | del

stacksofplates

@nadnerB said:

@johnhooks Righto, that's a bit unfair, comparing a one liner to a Script.
Lets see about turning that into a one-liner
(evening up the comparison)
dir "C:\Some\Path" | where {$_.CreationTime -le ((Get-Date).AddDays(-15))} | del

Ya like I said I don't use it so I just thought that's what you needed.

Yours is also understandable haha.

scottalanmiller

@nadnerB said:

@johnhooks Righto, that's a bit unfair, comparing a one liner to a Script.
Lets see about turning that into a one-liner
(evening up the comparison)
dir "C:\Some\Path" | where {$_.CreationTime -le ((Get-Date).AddDays(-15))} | del

As @JaredBusch would say, a one liner and a single command aren't the same You are stringing commands in Windows to do a single command's work in Linux.

nadnerB

@scottalanmiller said:

@nadnerB said:
@johnhooks Righto, that's a bit unfair, comparing a one liner to a Script.
Lets see about turning that into a one-liner
(evening up the comparison)
dir "C:\Some\Path" | where {$_.CreationTime -le ((Get-Date).AddDays(-15))} | del
As @JaredBusch would say, a one liner and a single command aren't the same You are stringing commands in Windows to do a single command's work in Linux.

Can't argue with that. I don't think you'll get better than a one liner in Windows.

scottalanmiller

It's not bad, I use one liners all the time, and that's a very simple one liner. Linux culture is to use a string of separate commands instead of one that does everything.