This post is my response to This video:
(Archival / downloadable copy)
OK, so I appreciate the tone of your video and your stated motivations for making it. I’m going to try to be diplomatic in my response.
1. Viruses.
The viruses you found were an exe file and a dll file. A windows executables and library. Not exactly a threat, especially if you don’t have wine installed. These are definitely not linux viruses and that machine is not infected – even if you did manage to run a virus-infected exe file, it’s not going to infect any of the other binaries on your system with the possible exception of windows binaries that your regular user has write access to.
The example you give is a really weird one, and I have no idea what is going on. My only guess is that perhaps this ‘imagination’ software (which I’ve never used, though I do see it in my repos) has an ability to optionally run some external windows-vased helper program if you have wine installed. The fact that the files were in /var/tmp indicates that it was your regular user who downloaded them, i.e you did it, or the program has a “download utility x” helper built into it. Or perhaps these files got into that temp directory via other means, and imagination didn’t run simply because sophos wasn’t allowing it to access the infected files.
There’s also the possibility that this was a false positive, and that the exe and dll files were not infected but simply used an executable compressor or something like that.
Yes, you found a virus, but your system was not infected by it. If I go to a website and download a virus intentionally, and then scan my ‘downloads’ folder, I’ll find a virus too. But I won’t be infected. In windows, even having that virus on your system is dangerous because simply double-clicking on that exe could infect a countless number of other executables. Though newer versions of windows have gotten better at protecting system files, and it’s quite possible to infect a whole lot of windows programs if you are using wine.
I will agree that perhaps the wording “Linux doesn’t get viruses” is a bit extreme – there are one or two linux viruses out there, and that perhaps it should be re-worded to something along the lines of “during normal use, linux applications will not be infected by viruses”, with the caveats of assuming you’re only using software from your distributions repository, and you’re not running things as root.
2. Uptime and reboots.
This is just wrong. I never ever reboot my machine, and I update it regularly. In 90+% of cases, this causes no problems at all.
Yes, there are cases where some library might be updated and it might render things which use that library unusable until you reboot, but even in this case, a reboot is rarely necessary – often you can just restart the underlying service or the GUI and things will work fine. Though sometimes it’s easier to just reboot than to figure out what you need to restart. It should also be noted that we’re talking about a miniscule percentage of updates here – usually when a service is updated, the update script will restart it for you.
Yes, from what I understand, systemd updates will likely require a reboot. This is one reason why we shouldn’t be using systemd. But that’s a whole other debate.
The machine I’m typing this on has an uptime of 138 days right now. That’s how long it’s been since we had a power outage. My laptop is at 103 days. My server at work is at 330 days (i.e: since the day it was commissioned). Next time I reboot, it will be using a newer kernel. Until then, everything is fine.
Compare this with rebooting three times during a round of updates.
3. Fragmentation.
You say that linux has “3 defragmenters”, but two of the ones you point out are tools which report on fragmentation, they don’t actually defragment. The two reporting tools are probably not necessary, since e4defrag has the ‘-c’ switch, kind of like ‘egrep’ being an alias for ‘grep -e’. The number of tools available isn’t a big indicator of a real problem, Linux types like to have lots of variety, e.g there are about 100 different tools for doing disk partitioning, but it’s not something a normal person does with any kind of regularity.
I’ve been using linux for 10+ years and I had never heard of these tools, so I did a defrag check on my machine, which initially started out with ubuintu 8.04 and has been upgraded multiple times without reformatting. I use it for everything you can imagine – gaming, audio/video production, media center, and coding. It gets heavy use and its disk has been up to 99% full more than once. I figured that if any disk is going to be fragmented, it’ll be mine.
The fragmentation score on my root volume was 0.
The fragmentation score on my home volume was 1.
I was a pretty damn advanced windows user for a long time before I made the switch, and I can attest that the same usage on a windows machine would have seen heavy fragmentation (actually the same use would have seen multiple reformats and reinstalls to clear out crud, but regular defragmentation would also be necessary). I used to defragment on a regular basis when I used windows (I had it set up as a scheduled task). Until today, I didn’t know that there were even degragmenting tools available for Linux.
Again, the wording on the claim “you don’t need to defragment” could probably use an asterisk on it, with a subtext “during the course of normal use”, and I can see how you think that the claim is misleading, but I think you’re attaching more signifigance to this than it deserves.
4. UUIDs in fstab – you can’t just switch disks.
Here I think you’re just wrong. Sorry, but you are. Yes, it’s true that you won’t get your full whiz-bang GUI interface immediately upon switching a disk from one machine to another, but saying that the system didn’t boot isn’t exactly accurate either. In your video, the machine boots to a grub prompt (which included an ‘advanced boot options’ choice which probably would have allowed you to boot the full system by specifying the root volume, if you knew the invocation to do so [I don't off the top of my head]). But the system also leaves you at a command prompt. It doesn’t give you a blue screen effectively saying ‘please insert your installation CD and reinstall’. From the command prompt you got, fixing this problem is as simple as doing something like:
ls -l /dev/disk/by-uuid
(jot down uuid of the disk in question)
vi /etc/fstab
(change uuid of root volume)
reboot
OK, so for your average nontechnical user, this isn’t obvious or intuitive, but it’s a far cry from a blue screen of death and a reinstall. You’ll note that the instructions above don’t include “insert your installation cd”, though that would also work – you could boot into the livecd environment and make the change you need to make to fstab from a nice gui without reinstalling.
Yes, back when /dev/sdX was being used in fstab, you used to be able to just put the disk in another machine and it would boot the full GUI. Sometimes. Assuming that the ‘X’ was the same on the new machine.
The reason this changed was due to the fact that in a modern distro devices can appear and disappear at any time because they might be plugged in or unplugged at any time. This includes hard disks (though I don’t recommend trying it unless you have a hotpluggable disk!). This support meant that there was no guarantee that /dev/sda would still be /dev/sda the next time you reboot – it might be /dev/sdb when you reboot, meaning that your fstab is incorrect and the system won’t reboot properly.
I’ll grant that perhaps fstab should be using disk labels instead – that would solve this problem (assuming it’s practical), but to do so would mean that all disks would need to have a label, and many don’t. It would also cause issues if you have two disks with the same label (e.g having a volume named “ROOT” in two computers, and taking the “ROOT” volume from one machine and putting it into the other – which “ROOT” should it use?)
I’d also grant that a more descriptive error message in this situation might be helpful, depending on how practical doing that would be. If the console had a message to the effect of “cannot locate root volume – perhaps you need to edit /etc/fstab?” it would be much more intuitive. Hell, it’s probably possible to build a text-based program that does this for you.
Technically, though, since you saw a command prompt and not a kernel panic, the system booted. I guess this comes down to your definition of “boot”.
It’s probably not awesome if people are making the claim that you can just pull the disk out and put it in another machine. There should probably should be an asterisk there, too. But “not booted” isn’t a correct desctiption of the situation either.
In Conclusion
I think you have misunderstood and misinterpreted a few things, leading you to some incorrect conclusions.
I think that this should probably be an interesting lesson for everybody involved – you can learn a few things about linux, and the linux community can learn how its “sales pitches” can be misinterpreted.
You should be careful and make sure the facts are on your side when using words like “misinformation”. Your video falls under that category.
I think you have done everybody a disservice by disabling comments on your video.