I would most likely switch back to Windows as my primary/only machine (because I also like to play video games sometimes) if I had the same kind of unix-like command line environment that I get in OS X.

Right now I basically need 2 computers at home to meet all my needs, but this would allow me to reduce it to one, so I could get a much better one (instead of the 2 mid-range ones I have now).

Out of curiosity, why would you not just go with a Linux desktop for that?

Before you ask, yes I do have a Linux laptop (Acer C720P ChromeBook, unlocked with Debian + Gnome), and with all the sudden issues that pop out of seemingly nowhere (my latest dragon is a recurrent kernel module crash that can fill my disk up with .core files in 10 minutes), I've switched back to a 13" rMBP. Though, I have heard that 2016 is going to be the year of the Linux Desktop...

I just got tired of fixing sound issues, trying to make a scanner work or investigating CPU states to fix heat and battery draining issues on yet another laptop. Ultimately, I think, all of this is a result of the unresolved issue of who should write and test device drivers.

It doesn't help that I disagree profoundly with the prevailing package management philosophy of Linux distributions, but that is a comparably superficial problem that can be worked around.

Sure, that's what this whole thread is about. But I'm afraid that there is causality involved that we know about without collecting any sample data at all.

Developers of Linux device drivers for consumer devices quite often do not have access to all the hardware and information they need. And hardware makers quite often do not make high quality Linux device drivers for their consumer devices. For most consumer laptops, the vendor will not do integration testing to make sure everything works well together on Linux.

I don't think the right response to that is to deny that the average laptop or peripheral will work better with Windows. The right response is to make it clear that you have to make very deliberate hardware choices if you plan to use Linux and accept that much of the hardware you can use is always going to be slightly dated. And that is in fact what many Linux advocates are saying.

Choosing a Mac also restricts your hardware choices quite dramatically after all, so if a broad selection of hardware is your goal, Windows is the only game in town.

It's not the best desktop environment out there, but apart from desktop, linux is the most popular system at every step from small embedded systems to the most powerful supercomputers. That wouldn't be the case if it couldn't make hardware available in a reliable and efficient manner.

More specifically, it's the state of Linux device drivers and integration testing for laptops and consumer peripherals I'm complaining about. That's not a result of any inherent deficiency of the Linux kernel or its design. It's ultimately an economics issue.

Android certainly doesn't have the userland that is typically (incorrectly) called Linux.

But if you want to talk about userland, then you need to buy supported equipment. OSX doesn't work with a ton of equipment out there - as that equipment does not come with OSX drivers. Windows also works like shit when it doesn't have the drivers - anyone who has had to install XP regularly will quite happily attest to just how terrible it is at supporting network cards before you install drivers.

Then, of course, there's the bonus of the AMD Catalyst driver installer program for windows: at least as recently as win7, if you didn't have drivers for video, it fell back to VGA graphics. The Catalyst driver installer was too large to be seen on VGA - you couldn't see the bottom of the installer window to see what was going on, and couldn't drag the window high enough without a hard-to-discover key chord. :)

The argument to "buy stuff your operating system supports" sounds like a cop-out, but it really isn't. OSX, for example, is difficult to make run on things other than Apple-designed computers, but if you complained about it, people would write you off as an idiot.

The reasons were 1) it ran the unixy stuff I needed for university AND modern games at the same time, and 2) it was boring and conservative. In a time where Linux and Windows were changing and breaking (Windows 8, Gnome 3, ...) it was nice to use something stable, well-tested, and polished.

I always use Linux for desktops., I see no reason not to.

I would never go back to windows but would happily move back to linux if I had to

EDIT: I should note I didn't expect to like my Macbook air so much (fantastic machine)

For my laptops... always had linux laptop problems. Sometimes have gotten really close to all the way working.. but then maybe I will find out my battery drains in 2 hours because some power saving feature is broke in my kernel and I cannot be arsed to go fix it, rather just buy a macbook.

Now for this vs macbook.. it depends how next macbook line looks. I need a 32GB ram laptop. If Apple skips that ship again, this will start to look pretty dang appealing.

There, now we're even. Let's get back to EEE, and the real porblems and advantages with this news.

And also because the user experience of OS X (and the "just works" aspects of the OS in general) is far above that of any Linux desktop.

https://news.ycombinator.com/newsguidelines.html

Well, I guess it'll be easier to port roguelikes which use ncurses.

Is this not helpful?

https://wiki.documentfoundation.org/Development/BuildingOnWi...

LibreOffice has official Windows builds, so I would expect that they can already build the software on Windows.

I'd rather use a toolchain I know better. In fact, I'd love to use clang on Windows.

I mean, sure, but (unless things have changed dramatically in the many years since I was a Windows dev) you don't have to do anything more than install VS. The compilers and nmake can be used without opening the GUI. IIRC, you can feed a VS project file (or -I'm pretty sure- a solution file) to nmake and get the same result you'd get from loading the GUI and pressing build.

[0] I do know that they are both parts of the VS build tooling. ;)