From Windows to Linux: Installation Culture

scottalanmiller

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.