Thousands of subreddits chose to go dark in an ongoing protest over the company's plan to start charging certain third-party developers to access the site’s data.
Wow. Front page of huffpost.com right now. Interesting…
I’m commenting from Arch Linux. I made the switch two months ago because I’m fed up with M$. What held me back for years was that I like gaming but thanks to Valve/Steam gaming gets better on Linux on a daily basis.
I love Linux, but in reality it still doesn’t support enough of the software people use. I own a bunch of audio software, and don’t feel like running it on wine or something like that.
Also, even the easiest Linux distros will eventually have an issue that forces you into to using a shell of some sort… I know a lot of people who would not be able to handle that. Also it can be a massive time commitment for troubleshooting.
Getting a bit of a downvoting there, @datavoid. I’m a Linux dev that works for a Linux shop that runs Linux on all his machines at home; I personally love the fact that I can send my test team and any customers having problems a list of shell commands to fix it all. (Quite a lot of our customers are more adept than I am, will send me back an improved version.) Much easier than a list of which buttons you have to push and a hundred screenshots, much more flexible when you’ve dozens of remote servers to deal with. But yeah, if you expect a GUI all the time, it takes a mindset change.
Linux has made enormous improvements in game compatibility recently, to the point that I don’t much bother checking ProtonDB any more for most things I’m interested in buying off Steam. But there’s still problem areas - funky DRM, very specific performance requirements, and reasonably small target audience - where some games just don’t work right, and that’s basically the problem checklist for most high-end audio stuff as well. Can probably add a driver requirement for specialist kit, too. Might be a struggle to fix that; requires manufacturer support, and they’ve not much interest in supporting a small market.
MacOS is built on BSD, which is like Linux but more arcane (sort of). (Edit: also the Android kernel is a Linux kernel). If you don’t find yourself using the shell in MacOS (or Android), it’s because they’ve done the work to make it unnecessary. The command line is still there, and can still be used to fix (or cause) problems.
The companies developing your audio software release it for Windows or Mac because that’s what the users are running. If the majority of their users were running Linux, they would be releasing Linux binaries.
As for being more reliable… it depends on your use case. Around 79% of all publicly accessible servers on the internet run something Unix-like, with about 38% of the total being Linux. Windows is used for about 21%. In my sysadmin work, I use Windows when it’s mandated by the software (again, because the developers chose to release for Windows only, not because the software is fundamentally tied to it), and Linux everywhere else. Reliability is a big part of that decision.
Not the end of big tech. You’re likely posting from MacOS or Windows and using services like AWS, Azure, or GCP on the sites you use and abuse.
The end of centralized social media though? I hope so.
I’m commenting from Arch Linux. I made the switch two months ago because I’m fed up with M$. What held me back for years was that I like gaming but thanks to Valve/Steam gaming gets better on Linux on a daily basis.
I love Linux, but in reality it still doesn’t support enough of the software people use. I own a bunch of audio software, and don’t feel like running it on wine or something like that.
Also, even the easiest Linux distros will eventually have an issue that forces you into to using a shell of some sort… I know a lot of people who would not be able to handle that. Also it can be a massive time commitment for troubleshooting.
Sadly Windows and macOS are (more) reliable
Getting a bit of a downvoting there, @datavoid. I’m a Linux dev that works for a Linux shop that runs Linux on all his machines at home; I personally love the fact that I can send my test team and any customers having problems a list of shell commands to fix it all. (Quite a lot of our customers are more adept than I am, will send me back an improved version.) Much easier than a list of which buttons you have to push and a hundred screenshots, much more flexible when you’ve dozens of remote servers to deal with. But yeah, if you expect a GUI all the time, it takes a mindset change.
Linux has made enormous improvements in game compatibility recently, to the point that I don’t much bother checking ProtonDB any more for most things I’m interested in buying off Steam. But there’s still problem areas - funky DRM, very specific performance requirements, and reasonably small target audience - where some games just don’t work right, and that’s basically the problem checklist for most high-end audio stuff as well. Can probably add a driver requirement for specialist kit, too. Might be a struggle to fix that; requires manufacturer support, and they’ve not much interest in supporting a small market.
MacOS is built on BSD, which is like Linux but more arcane (sort of). (Edit: also the Android kernel is a Linux kernel). If you don’t find yourself using the shell in MacOS (or Android), it’s because they’ve done the work to make it unnecessary. The command line is still there, and can still be used to fix (or cause) problems.
The companies developing your audio software release it for Windows or Mac because that’s what the users are running. If the majority of their users were running Linux, they would be releasing Linux binaries.
As for being more reliable… it depends on your use case. Around 79% of all publicly accessible servers on the internet run something Unix-like, with about 38% of the total being Linux. Windows is used for about 21%. In my sysadmin work, I use Windows when it’s mandated by the software (again, because the developers chose to release for Windows only, not because the software is fundamentally tied to it), and Linux everywhere else. Reliability is a big part of that decision.