after using linux (even those with GUIs) for over 13 years, I would personally still buy laptop with windows installed as primary OS.
The ease of day-to-day apps such as Microsoft Office, especially Word and Excel is unparalleled. If you are into DB and work in place that has MS SQL, MS SQL combined with SQL Studio is a very powerful feature. IDE selection is somewhat better because you have more options available -- things like Visual Studio (even for non Microsoft programming languages) are available.
If you go down Linux route and you need GUI, a portion of your time would be consumed by hunting for and finding analyzing options available for you on Linux -- for GUI stuff, Windows seem to be default.
In my opinion, if I am buying a non-Apple laptop, unless Microsoft rolls out a Linux distro with emphasis on GUI and which they will support and develop, I won't bother with Linux as my default OS on my machine.
It seems like most of those are a non-issue if you aren't working on a Microsoft stack.
Word and Excel are probably worth running Windows/Mac over Linux GUI alone if you have to spend any time in them, which I do in a non-Microsoft stack for business-related things. I'd imagine most people have to spend some non-negligible time in these.
O365/open source office products come nowhere close.
> Word
99% of uses can be trivially replaced by plain text, Markdown, or Org. For the others you probably want a real typesetting system anyway, so Word would still not be appropriate.
> Excel
If you're at a point where it feels appropriate to use vendor-specific spreadsheet features then you have already outgrown by far spreadsheets. It's probably both simpler and more maintainable to decouple your data from your code by using a database (even SQLite, if you still want to pass files around) and/or a scripting language instead.
> 99% of uses can be trivially replaced by plain text, Markdown, or Org.
For organizing content, yes. For communicating with others, no. For example, we are using Word documents on the edge, when communicating externally. We cannot expect them to access our internal wiki, and neither we want them to.
> If you're at a point where it feels appropriate to use vendor-specific spreadsheet features then you have already outgrown by far spreadsheets. It's probably both simpler and more maintainable to decouple your data from your code by using a database (even SQLite, if you still want to pass files around) and/or a scripting language instead.
Sure, if you have the budget to do it right. The excel-based solutions are often done so, because everyone has excel anyway, and the one coming with that has no budget or buy-in to procure the server-based solution.
> For organizing content, yes. For communicating with others, no. For example, we are using Word documents on the edge, when communicating externally. We cannot expect them to access our internal wiki, and neither we want them to.
You can't just copy the Markdown (or whatever format your wiki uses)? Most of them read fine as plain text.
> Sure, if you have the budget to do it right. The excel-based solutions are often done so, because everyone has excel anyway, and the one coming with that has no budget or buy-in to procure the server-based solution.
You don't need a server to use SQL (see: SQLite, H2, Derby, or even Access).
> You can't just copy the Markdown (or whatever format your wiki uses)? Most of them read fine as plain text.
In the process you will lose links, images, etc. Additional complication is, if these are multiple wiki pages, you have to save each separately.
You are not going to explain that to normal users. (Ever explained to a user, why he cannot attach word documents into bug tracker, but he is supposed to put the content of the document right into the appropriate text fields? Not fun).
> You don't need a server to use SQL (see: SQLite, H2, Derby, or even Access).
The reason why Access is not being used is, that it is not a part of the most sold Office SKUs (neither SoHo nor Pro). In fact, I just tried to quickly find out, which are the the non-365 SKUs that do include Access, and I failed.
And again, normal users are not going to use sqlite, h2 or derby without having some kind of forms frontend. Access would be ok, but it is not accessible to everyone who has Excel anyway.
Err, no? They're preserved in the source just fine.
> images
Good riddance.
> Additional complication is, if these are multiple wiki pages, you have to save each separately.
Depends on your wiki system. For example, Gollum[0] (GitHub's wiki) stores everything in a Git repo, so it's trivial to get everything out using your regular file management tools.
> And again, normal users are not going to use sqlite, h2 or derby without having some kind of forms frontend.
DBeaver seems fine to me, and supports pretty much everything.