SoylentNews is people
SoylentNews
Forbes.com has published a piece by contributor Jason Evangelho entitled "5 Reasons You Should Switch From Windows To Linux Right Now".
When I published the highlights of my journey switching from Windows to Linux on my everyday laptop... it became one of my most viewed pieces this year. From where I'm sitting, that tells me a ton of people are interested -- are at least actively curious -- about ditching Windows and making the jump to Linux.
With that in mind, I wanted to present five reasons that may lead you to consider switching. Know that these are subjective, and they're targeted at the average Windows user and not folks who rely on Windows-exclusive applications for a paycheck.
One thing to know right up front: the modern Linux desktop OS is no longer the obtuse, bewildering and command line driven thing it used to be. Not remotely.
It's nice to see a free operating system getting some love in the mainstream press. Forbes running this article is more the story here than desktop Linux having advantages over Windows.
Be sure to read TFA to find out what the five reasons are. (Or see spoiler, below.)
1: Linux Gets Out Of Your Way
2: You're Not A Slave To The Terminal
3: Installing Software Is Even Easier
4: Updates aren't a headache. They're glorious
5: The Linux Community
(Score: -1, Flamebait) by Anonymous Coward on Tuesday July 24 2018, @09:44PM (5 children)
Bug or not, Windows handles it, but Linux doesn't. Absurd to blame the reality for being "buggy."
(Score: 2) by RS3 on Tuesday July 24 2018, @09:56PM (4 children)
It's generally well-known that some graphics chip manufacturers resisted opening up their hardware specs to open-source driver development. Many of them provided their own proprietary closed-source binary drivers, and they were always known to be crippled and buggy, lacked many of the Windows accelerator functions, etc.
I have _no_ doubt it was done intentionally; someone in M$ pushing it. It would be very interesting to compare the Windows driver source code to the Linux driver. I'd bet you'll find hardware ports and bits being accessed by the Windows driver that are not published in the hardware spec.
(Score: 0) by Anonymous Coward on Wednesday July 25 2018, @02:43AM (1 child)
It's the fault of Free Software developers for not being able to magically make the proprietary thugs cooperate, and not the fault of the proprietary thugs who deny users their freedoms and try to make every computer in the world a black box.
(Score: 2) by RS3 on Wednesday July 25 2018, @05:50PM
I think it's a matter of resources and priority. The Free Software mavens successfully reverse-engineered the stupid MS NTFS, SMB / CIFS, Apple HFS and HFS+, etc.
It should be doable (to those who do this stuff regularly) to run Windows in a VM and monitor all graphics chip ports and bits and see what's happening that isn't documented.
Have at it BMOC.
(Score: 3, Interesting) by tangomargarine on Wednesday July 25 2018, @02:44PM (1 child)
Do you remember that one article a few years ago where it came out that some motherboard was purposely designing their ACPI tables (or whatever the heck it was...it had to do with booting different OSs I think...) so that there were separate ones for Windows and Linux, and the Linux version was subtly/perhaps-not-so flawed in a certain way so booting Linux just wouldn't work?
Reverse-engineering things is hard enough when you're a large, well-funded company, let alone a bunch of guys working for free. Although I imagine a lot of that FLOSS work is done by Red Hat employees or whatever.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 3, Interesting) by RS3 on Wednesday July 25 2018, @06:03PM
I don't remember that MB specifically, but certainly many similar stories, including lots of weeping and gnashing of teeth when UEFI was announced.
I think it's a matter of a combination of smarts, ability, determination, time, etc. Years ago (many) I had purchased a very inexpensive diet analysis program on 2 floppies. You HAD to have the one master floppy in the drive for the software to run even from hard disk. You could NOT copy the master disk- you'd just get disk errors. I got very annoyed and reverse-engineered it with simple DOS debug and a printer. In doing so I found that they ran you through tons of routines that did NOTHING but wear out your finger pressing single-step. If you tried to run CALLs, it would crash. Single-stepping lots of bizarre code eventually showed that they intentionally buggered the single-step return pointer (if I recall correctly), so you had to step over that.
Eventually I figured out that they had intentionally marked some floppy sectors as BAD, and the init code, talking directly to the floppy controller, wanted to see that before running the program. A simple jmp into the code past the floppy read routine made it work. It took a few hours but I won.