Has anyone been able to use darling for iOS CI jobs yet? Admittedly I haven't researched this in a while, but one of the biggest hurdles in large scale iOS development is sane DevOps infrastructure. I know due to Apple's TOS that you will never be able to build, sign, and distribute your app on non-Apple hardware. But i'd love to use darling to run unit tests/CI jobs on commodity cloud infrastructure.
Even if you do get dedicated mac instances, managing them is a bit of a nightmare since MacOS isn't designed to be headless.
I was doing this--using Darling to run the various tools from Xcode on Linux so I could build one of my macOS projects--five years ago and it worked great, but I haven't done it much since as at some point I started using MacStadium to rent Mac Minis. (I want to start using Darling again though, on the assumption that it is still working for running more GUI-oriented build tools--stuff like ibtool and actool, which I have sadly started to need, and now particularly the actual xcodebuild stuff, as Flutter is forcing me into that world due to its usage of CocoaPods... I hate it :/--from newer versions of Xcode.)
1. Be the change and make a framework that helps people create new and better toolchains for making iOS apps. It's more work, and requires taking the challenging path sometimes, but it's the better play for the long-term success of the community.
2. Use existing solutions that are locked in Apple's ecosystem, thereby railroading the community so that they too are locked in to Apple's ecosystem.
Why Apple's ecosystem worries me: Apple has shown time and time again that they will do the absolute minimum required to get people in the door before shutting it behind them. If someone else tills the soil and grows an orchard of delicious fruit that's reasonably priced and good for you, Apple will spend millions to fly in fruit trees with fruit that's almost as good and put a 'free with contract' sign up. What they don't mention is that they have no intention of watering the trees once the "competition" goes out of business.
I doubt any employer would let you do this though. And I have my Mac Mini for recording music and building IOS apps. But it is neat to see it's possible
Probably because it runs the risk of Apple revoking your developer account for supposed noncompliance, meaning your access to the closed iOS garden - and thus your business - disappears overnight.
For bazel users there is also this project[0] which runs the tools natively on Linux without requiring this layer. Although you lose tools like ibtool / actool which don't have open source re-implementations.
For unit tests, can you "just" build on Linux natively? I'm pretty sure Swift and Objective C are supposed to both work on Linux, although I assume library/API surface limits that.
This does generally work, but it requires a lot of manual effort to setup the environment correctly with Xcode's SDKs to satisfy the compiler / linker.
Also a mac mini is £700 which is the equivalent of ~3 days work for most trades here in Britain. I you value your time as much as a joiner and if it’s going to take you more than 3 days to get your environment setup and keep it maintained then you’re better off just buying a mac.
I work in games for a fully remote company. a Mac mini takes ~5 hours to compile and cook (read: prep the assets) for our game. It's not reasonable to ask someone to have that mac at home, and even if it was, you have to have it somewhere where it's available, has high speed internet, and that person is responsible for the hardware - making sure it stays on when it's needed etc. That person also needs to deal with any hardware failures/ warranty replacements. Instead, we could lease a mac from AWS for £20 for a day, run a build and use that.
That doesn't mean that this is a scalable solution for running our business on, but for the occasional one off mac build to make sure it's not fallen behind, it works just fine for us.
The difference between $20 per day and $2.40 per day at our current scale is practically 0 - we do a build every 2 weeks or so. We would save $500 a year on our current scale, which is likely less than it would cost in my salary to set up a scaleway account, spin up an M1 instance and configure it. Definitely worth it if/when we look at having more machines up and running though, thanks!
In some other countries I have seen an iMac been shared across teams that would take turns at the device.
In Germany I would state the same statement, we live between Windows and macOS on the office, but I also have some care for those that aren't so lucky.
Plus, I’ve found that most iOS codebases, tend to rely on parts of Foundation and the Objective-C runtime that are not implemented on Linux, even if the code doesn’t touch UIKit at all.
In this case I meant taking an approach similar to this one for bazel[0] that is not limited to only code that works on Linux. It would only allow you to build on Linux and would require any testing / running would still happen on macOS, but that might still be worth it in some cases. Theoretically you could deploy your iOS app that way as well.
Just thought it may be worth mentioning if there are devs from the project here, but Darling is one of the efforts that I would sponsor/donate to (just small amounts for now as I haven't made my millions yet ;-) if there were a more defined road map with milestones/goals.
This is an amazing and important goal! Thank you so much for dedicating your time and efforts to this!
Looks like an incredible project, but if GUI is not working, what is the current use case for it? Command line apps are usually open source and can be compiled in either system. What are people using this for in day to day work?
Some Dev commandline tools and compilers are starting to work, so these kind of environments will probably come first which will provide better performance than running under virtual machines.
> Some Dev commandline tools and compilers are starting to work, so these kind of environments will probably come first which will provide better performance than running under virtual machines.
Then it's not useful as the only thing interesting on macOs are the GUI applications. All the tools I used on macOs for the command line where already available on Linux.
As blunt as that is, I have to say I agree and thought the same thing reading through their page. I'm sure it's been quite a feat to get this far, but until GUI is supported well, I can't think of a single thing I'd ever personally use it for.
Good luck with supporting Mac GUIs. It's a constantly shifting target. Carbon is gone, but now Cocoa isn't always Cocoa because you also have to support SwiftUI, which is itself a moving target.
It is, but perhaps I'm not understanding how it is currently implemented. I thought there was a system framework it relied upon, and if so, that framework would need to be implemented in Darling. Perhaps the framework is embedded in every .app package? There's a similar issue with the Swift runtime. I believe Apple's goal is to make it a system framework, at which point it would also need to be implemented in Darling.
stupid question because I have not touched a Mac since 1999. What kind of apps are you using on Mac that if you were forced to switch to Linux you feel that you can't live without?
the appeal back then (and from I hear people say until today) was always how everything is neatly integrated. a coherent system from the hardware all the way up the stack. not sure if that is overselling it but at least that's how I understand is what people are happy to pay for.
I've never used a mac, but I do envy mac users for some of the productivity-focused tools like Alfred, Bear, Hazel, Keyboard Maestro, and similar.
While I do have some alternatives on my Linux system (Obsidian, Espanso, uLauncher, a bunch of scripts), they're not as integrated and somewhat of a pain to maintain properly.
I was an Apple user since 2008 until 2018, when I finally switched to Linux full time. At the time of my first switch attempt it was 2014, but I didn't realise how finely ingrained Apple's OSX workflow was in my mind. I had no problem finding replacement apps, but what was hard was using them and trying to build a comfy desktop environment. Essentially it took me from 2014 til 2018 to transition from OSX specific software to fully open source CLI apps. These days I run Arch and the only GUI app is Chromium. Not counting my i3wm and the lemon bar. It was a fun journey with with some challenging moments!
For me: Git Tower,
MoneyMoney (German banking app, absolutely fantastic),
Fantastical,
to some degree also OmniFocus.
Plus first-party apps like Safari with its fluid trackpad gestures, Photos with its iCloud integration, and of course Xcode, because being able to build/debug things for macOS/iOS is a bonus feature I can offer as a developer.
The list is a lot shorter than 10 or 15 years ago. Most new apps that come out are Electron, but even then there's sometimes no Linux port (Trello, WhatsApp).
That sounds somewhat resonant. I'd be really curious as to what insights you had or choices you made; considering the same type of switch. Did you ever write anything up on the journey or find any particular resources useful?
Not really. I've played it safe by buying a Linux desktop box in addition to my MacBook. elementary OS was fun (esp. the Daily build) because so many things can be fixed on an evening by sending a small PR, and they also receive support from the Touchégg developer now for better trackpad gestures. But I never managed to treat Linux as more than a thin shell around my IntelliJ IDE.
Thanks. I've tried it when it came out and wasn't really convinced. The video on its homepage looks better now, I'll give it another try when I'm on Linux again.
The apps that keep me using Apple products are Scrivener, Logic, Studio One, Final Cut, Photoshop, and Illustrator. There are a few others too.
I also like the integration between my phone and my computer. For example, taking a picture on my phone and having it show up in Photos automatically, the ability to copy and paste between my phone and computer, the ability to make phone calls on my computer, the ability to share browser windows between my phone and computer, and the ability to use my iPad as a second monitor.
I've been using Linux since Slackware's first release, and still use it today, but it isn't my main desktop for these reasons.
Ableton live (music application) - the only reason I still have mac. I tried to switch to Bitwig that is similar and runs on linux, but I have not had the time to develop a workflow with it.
I live and die by my IRC Client, Textual [0]. It may seem like a simple thing, but I've tried all the clients on both Windows and Linux and haven't found a suitable replacement.
This too. I sometimes boot a PowerPC iMac from 2004 to rip a CD, and it's amazing how little Apple has broken/removed since then, while adding gestures, cloud syncing, and all sorts of tiny quality-of-life improvements.
Asking out of inexperience with Mac command line tools ecosystem: outside of CI mentioned in the neighboring comments - are there any tools that could be useful on a desktop Linux?
This is a commonly repeated myth. The Quartz graphics framework does not use PDF internally. Its rendering model is roughly based on PDF, but not much more so than any other vector graphics format, like SVG or Cairo.
Yep, it looks like they have a kernel module for handling the Mach subset of syscalls.
> Emulating XNU system calls directly in Linux would have a few benefits, but isn't really workable. Unlike BSD kernels, Linux has no support for foreign system call emulation and having such an extensive and intrusive patchset merged into Linux would be too difficult. Requiring Darling's users to patch their kernels is out of question as well.
The module is amazing and actually kinda terrifying: it grafts in a decent bit of xnu, rather than re-implementing all xnu's features from scratch. This is made a bit more sane because Mach was designed to be extremely portable and has a good abstraction layer for manipulating very low-level stuff like page tables and contexts. But it's still kinda incredible. Part of me wonders if it wouldn't have been easier to graft Linux into xnu instead.
> If you want to run apps like Microsoft Office, Wine is probably a far better bet. I'd be surprised if Darling runs complex Cocoa apps anytime soon.
The advantage of Wine is that it's more mature. The disadvantage is that Windows is possibly the least Unix-like operating system in popular use and the number of ugly hacks they have to use to make Linux do what Windows does will never cease to be a source of friction and heisenbugs.
Whereas macOS is a Unix, so Darling doesn't have to imitate all the eccentric behavior of the Windows kernel, it can just implement the API.
I’m not sure the similarity is a benefit — the systems are divergent in some of the fundamentals. It might be better if they were less similar so that the differences were more visible.
There’s also libraries like GCD which GUI applications use and expect to work and have interesting interactions with pthreads. I’d guess it will be a while before they have simpler third-party apps working let alone something like Office. I see that they have the Coocotron examples working but Cocotron is the precise subset of the API that they’ve actually implemented so it’s not really indicative of the work in front of them.
Considering POSIX/UNIX heritage of both Max and Linux, disregarding user space libs, I'd estimate this to be a much smaller effort than Wine. So, besides GNUStep, Is there any project to reimplement open-source portable MacOS user space libs?
most macOS software uses the APIs offered by userspace libs almost exclusively. They represent a huge and vast interconnected set of libraries, developed over decades. Maybe not quite as large as the entire Windows API, but similar in scope.
The only pain point I have about Darling is that it is way more bothersome to install compared to Wine due to the fact it uses a kernel module. Except that, it is great.
Pop-up box comes up, here you can have as many credentials as you need, it saves them, just double click one and it will enter it in your terminal window. This an absolute life changing feature for me. I manage a ton of servers, and yeah we use SSO to ssh into them, but that is just ssh access. Once you are on a server they maybe several passwords and or accounts you need to login to or accesses (like postgres, mongodb, redis, etc.). Of course we have seperate passwords for each environment, so having this feature is pretty much a must for me now. Any terminal software that doesn't have a feature like this is a no-go for me (and so far iTerm2 is the only one I have found that has this feature, I have looked high and low for something similar native in Linux but have only come up with bupkis).
The other features I like about iTerm2 are pretty standard in at least a dozen or so other terminal emulators (tabs, split windows, etc.). Password management is THE feature that is painfully missing from Terminator, Tilix, etc.
> Password management is THE feature that is painfully missing from Terminator, Tilix, etc.
Never thought of incorporating this in the terminal emulator. I just use a command line client for my usual password manager. Any reason you can't do that?
> I just use a command line client for my usual password manager. Any reason you can't do that?
The obvious issue with this is the need to be in a session on your local machine. For example you would have to run the cli password manager, then ssh, then login to postgres. Then say you need to go to another machine and use a different password, now you have to back out to your local machine, run the password command again, then login to the other machine. The tool passmgr for example copies the pw to clipboard for 30 seconds, so now you up against the clock to get in and use it, what if you sit on remote machine for half the day? Now you have to constantly flip back to your local machine then back to the remote machine.
With in integrated password manager it doesn't matter what machine I am on, or even if I am daisy chained several ssh sessions deep, I can always immediately get access to the passwords I need.
I want an integrated password workflow, and calling a command line password manager client is the last thing I want to have to remember about. Even if it saves a few keystrokes, it's one less thing to think about.
Isn't having the part that submits the password embedded in the same shell history as the command itself more integrated than having a tool you need to tell to input your passwords pseudo-interactively each time? Isn't it also fewer keystrokes?
Either way, if you prefer something more interactive and keybind-y, one portable alternative you can use regardless of terminal emulator without necessarily involving a clipboard is to plug the password manager CLI into a terminal multiplexer, e.g.:
(I understand that this is kind of the opposite of what the terminal emulators you listed are about, which is having the terminal emulator do the multiplexing and other integrations. But you can get the same stuff done and it's more portable.)
Related unrelated comment. Is there any effort to make Darwin itself user friendly? Everything I've heard anecdotally is that Darwin is a world of hurt unless you really, really know what you're doing. It seems like that might be a slightly easier path towards having an open-source OS that can run mac apps than building a whole compatibility layer over Linux.
That sounds more difficult, actually. Because then you need to be able to run everything. Whereas, with linux, you can leverage most of linux's library and only use darling for the couple apps that you need that only run on Mac OS.
Not to in any way put down the developers on this, because I realize this is a hard problem, but it's been "almost working" for roughly five years. I don't think we should hold our breath on it, sadly.
The Github is still getting updates, at least as of November.
I think part of the problem is that most software that you would want to run on Linux from MacOS are also on Windows, and Wine/Proton already exists. As a result, I think people don't really feel the urge to contribute to Darling when they could just contribute to Wine.
Lots of questions around GUI apps. As someone pointed out, GUI apps have been "almost" working for years. Darling looks great but it hasn't gotten near as much love as Wine has gotten.
I've been keeping an eye on it, and will continue to keep an eye it, and I've noticed the development is very slow. At the rate it's going, it'll be years before it'll be a viable solution like Wine is. I hope visibility for it will increase so that the current devs get some more help on this.
I'd still like to give thanks to the devs as this is a very ambitious project. I'm sure people used to say "it'll be years before it'll be a viable solution" when Wine was in its infancy.
Having Linux run iOS, macOS, Android, and Windows applications running would be nothing less than mind-boggling, and would finally get people to stop yelling that nothing runs on Linux.
> Wine was originally released in 1993. You're talking about a period 7 years into it's development.
So? Darling is 9 years into its[1] development and hasn't really reached the maturity that Wine had after 7 years of development.
If memory serves me correctly[2], I'm quite sure that I played one or two Directx games on Linux using Wine in Dec-1998 - that's 5 years of development.
Fair enough, most of the games/apps did not run (Dune 2k was listed as "working" so I ran out and bought a copy only to find that it got no further than the game menu screen) but it ran more Windowed programs and full-screen games back then than Darling does now, so I don't think that I am performing an unfair comparison in that regard.
It might be that there is just not enough contributors to Darling to proceed at the pace that Wine did.
[1] I don't believe an apostrophe goes between the 't' and the 's'.
[2] At this stage of my life I treat my memory as a rough guide to past events, not as a record of what happened, so I could be wrong about the dates towards the end of the 90s.
> So? Darling is 9 years into its[1] development and hasn't really reached the maturity that Wine had after 7 years of development.
In 1993 wine had a much smaller target though, windows was in its infancy. Darling started in 2012, over a decade after mac-OSX, which even at that point was an established OS brand.
[EDIT: One more thing - In 1999 Wine ran my Watcom C/C++ IDE (with wasm inline and standalone too) perfectly. It just did not always run the programs I wrote in the IDE. I still have the CD somewhere.]
> Having Linux run iOS, macOS, Android, and Windows applications running would be nothing less than mind-boggling, and would finally get people to stop yelling that nothing runs on Linux
Nothing will stop those people from yelling that, because it hasn't been true in a very long time and that doesn't stop them. These are the same people who say they don't want to run Linux because they don't want to compile their sound card drivers. They are already way outside of rational territory and deep into religious territory. In their minds Linux hasn't changed a bit since 1999, even though if you were to compare mac os from that time period against modern linux, they would become enraged at the unfairness and injustice.
> These are the same people who say they don't want to run Linux because they don't want to compile their sound card drivers. They are already way outside of rational territory and deep into religious territory.
It's rational for me to want my sound card to work without having to compile code. No other operating system would make me compile code to fulfill such a rudimentary and basic expectation. That's not religion, that's usability.
I can't imagine trying to walk my parents through compiling a kernel driver to get their hardware working, and that's why I've never tried to get them to use Linux. If you want normal people to use Linux you should never, ever, ever ask them to even use a terminal, much less a compiler.
I've used Linux on the desktop, on and off, for over 20 years -- in fact, since the year 1999 as you mentioned. It still sucks. Every time I come back to it I have at least one driver problem. It's not ok, and it's not defensible. Instead of defending it and blaming critics for being "religious," admit that it has faults. Things only get better when we recognize the deficiencies and fix them, as Valve has been trying to do with Proton.
You missed the point. You typically don't have to compile anything for your sound card, assuming you even have one anyone considering that motherboards have had integrated sound forever now.
I've used Linux for around 8.5 years now, and I've never once had to compile a sound card driver to get my sound working. On the half dozen or so laptops I've installed it on since then, every one of them just had sound working without needing to compile anything.
>Every time Linux on the desktop is discussed, the reaction of the Linux desktop community is predictable: defending Linux and its problems, and downplaying the difficulty that many users have. A ton of people say "it works for me on my hardware" or "I didn't need to compile any drivers" or "the games that I want to play work fine". In fact, this comment thread has good examples of this type of reaction. So what? Until it works for everyone it's just not good enough.
I'm a bit confused; have you actually had this experience when you had to compile your sound card driver in the past ten years? It would be totally reasonable for you to be unhappy if you had, but given how much you're criticizing, I have to assume that if you had this experience you would have mentioned it. Given that, it sounds like the only criticism is that someone could theoretically happen to need to do this, but that's not really any different from any other operating system; the difference is that if your sound card doesn't work on Windows, you don't have the option to compile it at all. I'm not sure how often people have driver issues on Windows these days, having not used it much since before I swapped to Linux, but I'm not going to prematurely get angry about the idea that people _could_ be having driver issues but not have the option to compile their own if I don't actually hear about anyone having these issues.
>> They are already way outside of rational territory and deep into religious territory
> Until it works for everyone it's just not good enough.
You are pretty well proving the GP point. There is no system that works for everyone. Windows can be very challenging to get up and running on hardware setups that are not the most common.
> Windows and MacOS don't make people do that
False. And it's funny that this is about sound drivers. I have a piece of older but perfectly working Roland audio/MIDI equipment that uses USB drivers that are no longer supported on modern MacOS. How did I get it working? By compiling a fucking driver the other day. (And yes it works perfectly out of the box on any Linux kernel for the past 20 years).
Now go ahead and move the goalposts about older hardware not mattering or some nonsense. This hasn't been the only frustration with MacOS. It took these clowns the better part of a year to fix VLAN configuration in the network setup window. The only way to configure them for a lot of hardware was to drop down to the command line - so much for working for everyone.
Windows doesn't work for everybody either, and I do mean actual problems with Windows not working, even pre-installed from the factory.
I don't even have to look outside the circle of people I know in person to have seen this. Googling for Windows not working with $X specific laptop instantly reveals quite a treasure trove beyond the people I know, where $X can be pretty much any Windows laptop. Everything from fingerprint readers no longer working to even simple things like the function key hotkeys no longer working.
Issues with sound drivers not working are far from unheard of on Windows laptops.
You definitely seem to have missed their point, and, in my opinion, you're being unnecessarily antagonistic.
Agreed, you definitely missed my point, but in your defense the point was implied rather than explicitly stated so I'll take the fault for not being clear.
I don't mind building my own drivers (in fact I maintain one[1]), but I would never expect the average person to have to do that. It would be entirely unreasonable.
But, the vast majority of linux users don't have to compile any drivers. Unless you have some obscure piece of hardware or one that is so new that the driver isn't mainlined yet, you don't have to worry about it.
You say you've been using linux for 20 years. which driver(s) in the last 5 or so years have you had to compile yourself?
On most machines I tried, linux had every conceivable driver ready out of the box without any configuration.
This is absolutely not something one can say about windows (though at least nowadays it will try to fetch drivers from God knows where and often succeed). And Mac supports like 2 hardware devices all together, both of them manufactured by them — comparing an OS that exclusively run on specific hardware is just stupid and not made in good faith.
I've been slowly going through sound cards (Focusrite, MOTU, Rode) during the pandemic trying to find one that my work Windows laptop will detect. All of them have worked immediately plugged into Linux.
Interesting. I have had to compile drivers for every Linux install I've done in the past three years. Ubuntu, Xubuntu, elementaryOS, Pop!_OS, etc. Maybe we can all accept that people have different experiences?
And of course, you're under no obligation to listen to any of us whine, but if, on the off chance, you happen to want more people to like Linux, it seems like taking people's experiences seriously would be a good starting point.
I didn’t say that the contrary can’t happen - but wildly inaccurate, bad-faith claims that the account made I replied to are not ok either. Linux did come a long long way, and often used hardware will indeed just work out of the box most of the time - I think it is absolutely fair to point that out because it was not this way always — there was a time when the majority of hardware needed some tinkering.
May I ask you what hardware did you install linux on?
I'm curious what drivers you've had to compile? The only ones I've ever had to compile were GPU drivers for very very recent cards. On my current laptop, the only thing that doesn't work is the fingerprint reader (which doesn't even have a driver, makes me sad) - everything else is built into all the distros I've tried (Ubuntu, Fedora, NixOS). I am pretty curious in what places is the driver story behind?
Drivers for virtualized hardware is one big one. Parallels tools have to be recompiled for pretty much every new kernel version because Linux refuses to stabilize the kernel API. Often I have to edit the drivers by hand (example: replacing "sem" to "lock" for kernel 5.8 because apparently driver compatibility isn't as important as catering to kernel devs who don't know what a semaphore is?).
In case you don't think virtualization is a valid use case, this should hold true for any drivers distributed outside the kernel. It's also true for newer hardware - WiFi 6 has been a thing lately. And over the past couple years as laptops try to compete with Apple there have in fact been sound issues, though that one hasn't bit me personally.
Again, I want to stress that I'm not imputing some moral obligation for things to be different. But it is definitely a rough edge, it absolutely requires people to futz with compiling drivers, and it's something that makes some number of technical people say "screw it, this is too much of a pain in the neck."
In my opinion, investing in a proper driver architecture with a stable interface would be a massive step toward better Linux hardware support and broader adoption.
> Parallels tools have to be recompiled for pretty much every new kernel version because Linux refuses to stabilize the kernel API.
I don't think that's a fair comparison. Parallels comes with dkms module and while the process of installing involves compiling under the covers, it's just part of installation. It's not the late 90s "compile that driver yourself completely manually" situation.
If Parallels doesn't work with new kernel, that's their compatibility issue, but being able to fix the driver yourself just gives you more options. Linux -> you can fix the driver. MacOS -> you can on new macos, with annoying extra signing and other steps. (if the source for macos is even published - for parallels that's a no) Windows -> basically wait until the vendor produces an upgrade.
Parallels says for macos 12: "Productivity and integration features are not available to this VM yet." Even if you wanted to fix it manually - you can't. (https://kb.parallels.com/au/125561/)
Basically, you get the extra option to upgrade faster than your vendor is ready on Linux - if you use that path, why show it as "I had to do manual work to make things work", rather than something positive?
Not OP, but I do want to note, there is a difference compared to windows: Windows has a stable driver interface, which makes it at least possible to have drivers that are basically guaranteed to be future-proof. Linux has no such stable ABI, and frequently does breaking changes.
Both approaches have their upsides, but I've very rarely had drivers stop working between various windows release. Of course, there are exceptions to the rule here - Yes, I also have had some drivers stop working since Windows XP. But those are rare, and getting rarer as time goes on and MS locks the kernel up, preventing drivers from doing stupid things.
On Linux, the problem only exists for out-of-tree drivers, but those will break fairly frequently for all but the simplest drivers.
As I said in my sibling comment, I don't know how I feel about a stable ABI - I do fear it would make the situation worse with more out-of-tree/proprietary drivers. But it is worth keeping in mind that it does have its upsides.
Of course, MacOS being what it is, it chose the "worst of all worlds" scenario: Proprietary drivers with no ABI stability guarantee. It's not really worth discussing as a point of comparison, MacOS has the worst driver story from the lot, only saved by its intended minimal target hw support.
> I don't think that's a fair comparison.... the process of installing involves compiling under the covers, it's just part of installation. It's not the late 90s "compile that driver yourself completely manually" situation.
I don't understand. Do you think I'm lying or something? Because I'm not, and neither are these folks:
> In my opinion, investing in a proper driver architecture with a stable interface would be a massive step toward better Linux hardware support and broader adoption.
Eh, I have mixed feelings about this. Part of what makes Linux so great is that most of its drivers are open source - which allows the devices it supports to stay supported basically forever (though bitrot certainly is a thing). And they achieved this by making maintaining out-of-tree drivers so damn painful.
A stable interface would sort of undermine this. I honestly don't know if that'd be preferable to the status quo.
I think I'd be happy with a stable API, it wouldn't have to be a stable binary interface. Wanna change the internals of a struct? Totally fine. Not make binary shims for 32-bit drivers? Totally fine.
That would encourage open-source or at least source-available drivers (to allow recompiling for ABI changes), but recompilation should be straightforward and possibly automatic if the API doesn't change every couple months.
If you ever got in a situation where your sound card wasn't supported on macOS, instead of "you can compile a driver" the answer you'll get is "throw away your sound card and buy supported hardware."
You could apply the same fix to a Linux computer and purchase known working hardware, but because you have the option of fixing the software yourself that makes it a worse operating system?
Exactly how does one get into a situation where your sound card isn't supported on macOS, other than by putting together a Hackintosh? :) You're going to have to look for some pretty edgy edge cases where you will be left rending your shirt and wailing "if only I could compile an open source driver for [insert thing] but the cursed closed nature of Apple products prevents me from doing so!" (I mean, I'm pretty sure people can write open source drivers on Macs if they want.)
Granted, as someone who's been using Linux sporadically in various ways for the same two decades I've been a Mac-on-the-desktop user, I can't remember the last time I was left rending my shirt and wailing "if only I didn't have to compile an open source driver for [insert thing] to get basic functionality working." (Although I can remember more than one time I ran desktop Linux in a VM on a Mac, and spent several hours doing web searches for how to get [insert thing] working to find little more than other posts saying "I'm running desktop linux on a VM on a Mac and I can't get [thing] working".)
Apple stops supporting their own hardware all the time. They dropped a bunch of video cards especially in recent releases of the OS.
How this translates is by Apple officially dropping support for your whole computer. I guess you consider getting trapped on an old OS that stops getting security updates and becomes incompatibility with the latest applications to be superior to the situation on Linux. I do not.
Or, as others have pointed out, having to upgrade perfectly good hardware because the OS no longer supports it. That has happened to me on both Mac and Windows.
Honestly, better hardware support is one of the reasons that I have started using Linux more and more than proprietary options.
I actually really like Windows 10 but I have had way more hardware issues with it on my primary laptop. I had odd performance problems with it sometimes and the mouse pointer would lock up frequently ( Windows factory installed ). I put Windows 11 on this computer ( new enough hardware to meet all the Windows 11 asks ) hoping it would improve things. It was a disaster. My Bluetooth headphones rarely worked. Plugging wired headphones into the port would not silence the speakers. Blue screen of death ( have not see that in years - looks much friendlier now ) all the time which you know is a driver problem. Anyway, I have since out Linux on it and all my hardware woes are in the past. As I said, I actually really like Windows but it is a relief to get it off this machine.
I've got an old Macbook Air that has to be used with a USB sound device because the internal hardware died at about 4 years but wasn't worth replacing the motherboard. In other cases, I'm sure professional (or even hobbyist) audio people use hardware other than the computer's built-in sound devices. How long do the makers of those keep updating the drivers when it's a 5 generation old product and their developers have moved on to newer projects? A driver they gave you for OS X 10.5 isn't going to do you any good today.
They don't make people compile their own drivers because their respective corporations spend some good money to pay their developers to work on company provided hardware, or harware manufacturers to make their drivers first, and sometimes only their drivers. Linux developers otoh are often forced to reverse engineer closed source drivers on hardware they purchased themselves, so Linux support usually comes later.
The upside is that nearly all Linux drivers are FOSS, which makes a huge difference as there's no such thing as planned obsolescence among FOSS.
Never seen a perfectly good peripheral being supported by Windows until version x, so that you install Windows 10 and that card that worked fantastic under Windows 7 or 8 isn't supported anymore? No drivers, no party.
Sometimes the price to pay for running an OS that doesn't allow you compile your drivers is the purchase of new hardware along with system upgrades; that represents one of the hidden costs of closed source software that should be stressed more often.
Edit: ...and btw, it's like 15 years I don't have to compile my kernels anymore. A couple things or so have changed since 1997.
This comment is really fascinating: not only the author completely missed the point of the original comment they are responding to (which is: ”having to compile your drivers was the state of Linux in 99, but it' hasn't been anymore for at least 15 years, so complain that Linux doesn't work using this argument just shows you're out of date by two decades at this point”) but the author just refused to even attempt to understand when other people tried to warn them and instead went completely mad.
If you just want to be a consumer that does no tinkering then buy a computer that ships with a consumer focused Linux distro. Dell, Purism, System76, or even a Chromebook are more fair comparisons.
Stop claiming Linux is hard to use because it takes effort to run it on unsupported hardware... like any other OS.
> Until it works for everyone it's just not good enough.
No system is good enough by that definition. I've got a set of devices which either require lots of extra work or just don't work on all of Linux (parts of Lenovo dock), Windows (phone over bluetooth, also can't do clean install), MacOS (usb-c audio interface). We got to the level of "most things just work" on all of them.
Vouching for this, because while the topic is controversial and we could have done without the tone of the edit (true or not, it derails the discussion further), there is definitely some truth to what's said!
> "Typically" is not good enough. Windows and MacOS don't make people do that, and neither should Linux distros.
> A ton of people say "it works for me on my hardware" or "I didn't need to compile any drivers" or "the games that I want to play work fine". In fact, this comment thread has good examples of this type of reaction. So what? Until it works for everyone it's just not good enough.
The difference is probably that on Windows installing drivers is as easy as running an .exe or an .msi file, whereas on Linux the process can be more involved due to how different distros can be from one another, how the kernel versions might require different headers and how compilation of drivers might involve dropping down to the terminal which people sometimes forget isn't comfortable for people who don't necessarily use Linux in that capacity.
Wouldn't it be incredibly nice to have something like AppImage or Flatpak, but for drivers? Not the controversial distribution/update practices (though those criticisms are more about snap), but something that's as conceptually simple as clicking on an icon in a GUI somewhere to launch the installation and handle everything behind the scenes?
As for games, look at a recent video by Linus Tech Tips, "Gaming on Linux is NOT Ready... - Daily Driver Challenge Finale ": https://youtu.be/Rlg4K16ujFw
(Linus also demonstrated accidentally bricking his distro by not reading a terminal warning about problems with installing certain packages in the 1st video of the series, which is a really good example of some of the other problems in regards to usability)
There is a lot of progress, but also a lot of problems to solve.
GPU and wifi drivers were problematic in the same era as the sound card drivers were, and really aren't anymore unless you have a nvidia card and refuse to use closed source for drivers moral reasons. Were seperate sound cards to have remained a big thing, it's likely they would have been resolved too.
Ive only got ten years under my belt, but I don't think I have ever had to compile a driver! perhaps a few times in Arch, although it would be an AUR thing and hardly and intensive manual process. But certainly not in debian-based stuff. I dont even understand what it would be like to have the bad experiences people do with it.
I can only assume its hardware disparity. I never have much money so I always get older cheaper hardware I can afford, where support has most likely had time to mature. Perhaps people with these negative impressions of Linux are trying to install distros on newer, bleeding edge stuff?
I am not going to defend the Linux Desktop as there are many legitimate reasons to criticize it ( though the laptop I use the most does run Manjaro ). I must say though that suggesting the average Linux user has to compile their sound card drivers is pretty out of touch with even remotely recent Linux offerings. At this point, Linux is far more likely to support your hardware out of the box than either MacOS or Windows—-especially for older hardware. I am far more likely to be hunting around the web for Windows drivers or even totally unable to install Windows on my hardware than I am to have to do any hardware configuration at all on Linux. And I have considered putting Linux on a old iMac because Apple no longer supports the latest OS on it and this has started to become a compatibility hassle. In many ways, Linux requires less futzing around than the competition.
One area where I am dramatically wrong about this is with regards to high performance video drivers though that is improving. Even there though, a distro like Manjaro will likely work perfectly out of the box. To get performance a gamer wants might require a fair bit more knowledge but that said gamers tend to spend quite a bit of time managing and tuning things even on Windows.
Honestly that's because of hardware suppliers. Don't buy hardware without Linux support and this problem goes away. Windows, through sheer market power and mindshare, has created a situation where most hardware just works on Windows. This is not a rational expectation for other OSes. Trying to run Linux on a random Windows laptop is more or less like trying to run OS X on it. If it doesn't work that's on you
So far, my best experience has been on a LaptopsForLinux laptop. Every feature I expect to work on a laptop works (which is surprising when you're using Linux). I did try and buy another "made for Linux"-type laptop, which was some Entroware model, but I remember experiencing a lack of Hibernate and poor battery life.
I also tried a Dell XPS, but there were some BIOS problems, the keyboard layout was awful (which is not a Linux problem), and Hibernate was spotty at best.
Bad keyboard layout was also a problem with the Entroware.
Hibernate works perfectly on my LaptopsForLinux model. :+1: I just wish there was a keyboard protector in case I spill coffee on it.
Maybe laptop nirvana will finally be reached with the Framework when it finally reaches these shores. [EDIT] It has arrived.
Comparing the experience of porting an OS to hardware that did not ship with it to an OS that comes with the hardware is arguing in bad faith.
I have personally ported Linux to many devices the manufacturer never intended it to run on and I even have code in the kernel. I can generally make Linux run on anything by compiling a custom kernel or drivers with maybe a custom patch or two.
I love having that freedom but that freedom is too often confused as the default end user experience of someone that goes to a store and buys a computer that ships with Linux.
When comparing Linux vs Windows or MacOS for end users then talking about porting to unsupported hardware is silly. If you want to run MacOS on unsupported hardware it will take some hacking too.
I have helped hundreds move to Linux many of whom are elderly and non technical. I have them go buy a computer that ships with Linux and is supported so they never need to open a terminal and everything just works. Dell, System76, and Purism all have fantastic offerings here and I do not know of anyone who has switched back.
I've found numerous times Ubuntu just doesn't want to work. Ether Wifi or Bluetooth is broken.
Fedora seems to be a bit better, it's my daily driver on my old lightweight laptop. My big gaming PC runs Windows.
I make music and play games with it, no matter what the FOSS community wants to think , Linux doesn't come close in these aspects.
Each OS does different things well. Linux is very good for running on older hardware, or small computers like a PI.
Windows is exceptional at gaming and game development ( really any C# dev). Visual Studio is the greatest IDE ever made. If I had to write C# in note pad I'd give up coding.
Mac OS is best for creatives. Logic Pro is only 200$ , and easily replaces an entire studio. With Logic and a 300$ mic you can make something very nice. Your also forced to own a Mac if you want to make iPhone apps.
The music creation ecosystem on IOS is miles ahead of Android. It's at the point where I'm considering am iPhone in addition to my iPad for on the go music creation.
At the same time, as a phone, my Pixel 6 is everything I could ever want. Automatically letting me screen calls saved me hours per months.
I'll forever love Linux for giving a stable NodeJS dev environment when Windows wouldn't. Without desktop Linux I would of never been able to develop the apps which got me my first job. But you need to be open to hopping in the terminal.
Ubuntu is the only distro where my Bluetooth headphones reliably connected and auto-switched to stereo audio (not headset) mode. It's gotten a lot better, though perhaps only with quality hardware.
As far as WiFi is concerned, I'm more likely than not to blame the crap connection on the access point. I've had great success replacing rubbish APs with something basic but good, but for work I want wires if at all reasonable.
> Windows is exceptional at gaming and game development ( really any C# dev). Visual Studio is the greatest IDE ever made. If I had to write C# in note pad I'd give up coding.
It's one of the JetBrains commercial IDEs, but since i got the Ultimate package of their products for Java development and some other stuff, i also tried out Rider and found it to be pretty pleasant for everything from web development, to game development (with Unity in particular, though Godot also works obviously, as would other engines like Stride, or NeoAxis or whatever).
They have some pretty nice features for Unity, like giving you hints about methods which are slow and are used every tick, or maybe alternative methods that could be a better fit in some cases: https://www.jetbrains.com/lp/dotnet-unity/
Now, some people say that Rider's a bit sluggish like some other JetBrains products, but in my experience it's pretty close to Visual Studio (faster startup, slower when indexing project, faster for many code hints, slower for autocomplete), though maybe because of me enjoying messing around with the memory limits and usually increasing them slightly.
Nonetheless, for enterprise projects, i'd probably just continue using Visual Studio for consistency's sake. Heck, last i checked, Visual Studio even had plugins for supporting Python and other languages, which was interesting to behold. Apart from that, i'm not really aware of many other IDEs for .NET/C# out there, maybe MonoDevelop which is free, but also kind of abandoned: https://www.monodevelop.com/
Just figured that i'd mention JetBrains products in the first place, because they're my toolbox nowadays for which i reach whenever i want to do some development with the IDE helping me out regardless of whatever tech stack i'm dealing with (at least the common ones), so it has largely replaced Visual Studio for me. Though i still reach for Visual Studio Code for more rapid/lightweight editing of scripts, confguration files and such (or other text editors for when an IDE isn't necessary).
Just created an account on HN to say that all the JetBrains Products I used are outstanding! I switched from Atom to VS Code and since nearly 4 years I have a IntelliJ IDEA Ultimate subscription which is worth every penny.
By the way: JetBrains is also working on a more lightwheight editor called Fleet which seems to be comparable with VS Code, at least visually. There's already a product page for that at https://www.jetbrains.com/fleet/
Ha, that's amusing, because at the same time i hate Android Studio with a passion - it seems like the worst JetBrains product by far, though maybe because Android isn't a particularly nice platform to develop for.
Admittedly, most of my complaints there would be about the different Android SDK versions and how sluggish and slow everything feels at times, as well as about how Android seems to have a stripped down JDK inside of it, which causes weirdness with certain libraries, as opposed to just having something like OpenJDK.
But hey, whatever works for you! I don't really think that there are that many (if any) alternatives for Android development, to be honest.
You can still use Eclipse for Android dev, or just run your own builds with cli tools.
I'll agree Android dev is pretty frustrating, it's much better than it was just a few years ago, but it's still nowhere close to iOS. iOS users also tend to be much more willing to pay money, so there's that.
Heh, i'd say that Eclipse is universally even more horrible, because while Android Studio feels sluggish for Android development and other JetBrains products are generally pretty good, Eclipse has been slow, laggy and even buggy for me in every single one of its forms - be it using it for Java, PHP, or even more obscure tools like 4EM for enterprise modelling or EMF for model driven development.
It excels at having a large plugin ecosystem, moreso than JetBrains products have (probably close to what Visual Studio Code has, just look at https://marketplace.eclipse.org/category/categories/programm...) and being a common base for a variety of other tools out there, due to its modular nature, but there are plenty of disadvantages to that approach (loose coupling that ends up being brittle and worse runtime performance come to mind) and the workspaces concept feels shoehorned on.
That said, some out there swear by it and admittedly the customized versions of it, like Spring Tool Suite (STS), provide a lot of value to them and numerous other people, so everyone should probably just use what fits their needs. For Android in particular, however, i haven't found an IDE that's as pleasant to use as for other languages. Oh well, high expectations be damned~
I've been using GNU/Linux on the desktop for about 10 years now, must have used at least 10 different distributions, and I've never had to compile my own driver for anything. WiFi, Ethernet, sound, graphics, etc., pretty much just works. I don't use Bluetooth, so I can't say about that, but it's my understanding that Bluetooth gremlins are common everywhere.
For the past several years I've been recycling Windows 7 and up laptops by giving them a second life with GNU/Linux, and everything Just Works most of the time, including sound, videocard, power management, etc. The only thing I've had occasionally not working is the volume and brightness buttons, but they work most of the time as well.
When my partner's Windows 8 laptop shit itself after an unconsentual upgrade, I installed Ubuntu on it, and it worked just fine out of the box, for years. This person is not a computer nerd by any means.
I'm not saying your experience is not valid, but it is the complete opposite of mine.
Echoing the commenters pointing out that you leaned into the irrationally.
Separately:
> If you want normal people to use Linux you should never, ever, ever ask them to even use a terminal
What about Alexa or Siri? Would it be acceptable to ask them to use a voice-activated digital assistant to accomplish what people use the command-line for? What about a text-activated one, without the voice recognition problems?
I was going to say that I have not compiled a driver in years but I remember that I did compile a driver in 2020. It was to add support for a Xbox controller so that I could use it to play Steam games on my laptop. It was pretty straight-forward but I did have to run a compiler ( maybe via a script - I cannot remember ). I am not sure how easy it is to use an Xbox controller with Mac or Windows.
I am not a big gamer on any platform. In fact, I was using my son’s Steam account. He uses Windows himself but I was running it on Linux. I only played a few titles but they all played pretty well given that it was on an older laptop. Steam itself installed from the standard Manjaro repository but I did have to compile a driver for the controller.
Been playing a lot of steam games with proton, it is mind bogling how valve expanded from support for linux for the source engine to support 70% of the games.
The giant youtube channel Linus Tech Tips has done a recent series of videos on gaming on linux. On Jan 1 they published a 15 min summary video that covers that 70% claim in a much more nuanced way: https://youtu.be/Rlg4K16ujFw
Punchline: it's kinda true, but there's plenty of struggle for new and multiplayer games still.
There are even bigger caveats to that number than what they mentioned in the video. Since all the ratings are based on user reports, there is no standard for what is considered a working game. You can look through pretty much any game and find positive reports that mention frequent crashes, performance issues, missing textures, requires a custom proton version, etc., but since it launches, they gave it a thumbs up. I've tried platinum rated games that are completely unplayable, ProtonDB ratings are a general guide at best.
ProtonDB also considers a game as "working" if even a single person gave it a thumbs up, so the big "17,984 games work" on the home page is very misleading.
It may be true, but it really depends on how new the games you want to play are. I don't consider myself a hardcore player, but I'm perfectly happy with the games I've got on Linux; Overwatch, Diablo 2/3, Warframe, Risk of Rain 2, the Fallout series... they all work fine. It's certainly no Mac when it comes to game compatibility. Really, the only time a game doesn't work on Linux is when the developers go out of their way to ensure you aren't running Linux; with the prevalence of anti-cheat that has indeed seen a bit of a fork in the road. But developers can also whitelist Linux users, and now that the Steam Deck is getting ready to ship to hundreds of thousands of future owners, those devs have an incentive to get their games on Linux.
I think "asterisk" is warranted, since there are still show-stopper games that won't run without their precious kernel-level anti-cheat (sorry professional Valorant players), but the asterisk is shrinking, not growing. It's a fairly small caviat at this point, especially for more casual audiences, and I kinda wonder why it was such a sticking point for Linus. Wine is not a panacea, but if you look at the landscape and see the majority of Windows software running, I think there's hope in that.
I am sure it heavily depends on the kind games we play but I've had a 100% success rate over the past couple of years. I have to keep reminding myself to check protondb just in case. There are even a few games with native ports that I run through proton to avoid bugs in the native versions.
That's what's making the Steam Deck possible. And the release of the Steam Deck is only going to bring more attention to Proton and accelerate further development.
To get my bluetooth adapter to work I had to find a third-party driver, compile it, and manually setup DKMS so it'll update whenever a new kernel gets installed.
That's a much more complicated process that either macOS or Windows.
I don't doubt that happened to you, but I've had almost a dozen bluetooth devices and I've only had one not work OOTB. I'm using OnePlus Buds Pro with my linux laptop right now and it paired flawlessly.
Generally speaking, bluetooth is a complicated and proprietary mess though and many (especially cheaper vendors) don't bother testing at all. I'm actually amazed that bluetooth works as well as it does on linux. Taking a few minutes before a hardware purchase to check compatibility is a really good idea.
That seems like a terrible success rate, though, doesn't it? 1 out 12 bluetooth devices failed to work whereas they work 100% on Windows? For the average user, that is definitely going to be a dealbreaker.
I have several pieces of Bluetooth hardware that don't work on my Mac.
I get told that I should have bought something that was Mac compatible, and no one says that Mac's have a terrible out of the box experience or that it makes it a deal-breaker.
Any specific examples? I've been using Macs and PCs for over 25 years and Linux on and off for 10 or so and have never had issues with Bluetooth devices on Mac or PC. That even includes some hacky Bluetooth hardware and emulation hardware.
> That's a much more complicated process that either macOS or Windows.
Especially when the process on macOS or Windows is that they do not support that bluetooth adapter, they will never support it, and you should just buy a different one.
I do my hardware compatibility checking before I buy. If I'm going to have to track down and compile drivers, it's my punishment for wanting a bleeding edge thing, and I always know what I'm getting into.
For macOS to use a USB <> Ethernet adapter I had to hunt down some obscure driver, and after a certain macOS update it kept putting it in a folder on the desktop after each update despite it working if I just reinstalled it.
I absolutely used to love macOS and thought that they must have the cleanest nicest code in the world because they have such a well-developed UI+UX, but in the end, the core code below it has the same wrinkles as any software project. They’re just paved over. Plus, Apple loves to let stuff fail silently.
On the flipside I have an older but functional scanner[1] that doesn't have a driver for modern Windows (Latest version is for Windows 7 32-bit) or Mac (Latest version 10.6), but still works perfectly fine in Linux.
My Brother laser printer doesn't have a driver that works on MacOS anymore, it's old enough that it tries to install some 32bit software which is rejected.
Similar situation for Windows as yourself, only unsigned XP drivers.
> They are already way outside of rational territory and deep into religious territory. In their minds Linux hasn't changed a bit since 1999, even though if you were to compare mac os from that time period against modern linux, they would become enraged at the unfairness and injustice.
I agree that this is part of it. But I also just see plain antagonism against Linux because people recommend it. Just pure contrarianism.
But a lot of the recommendations for Proton are also "memey". It's a bad fit if you need Anti-Cheat or proper injection protection. And that's just the nature of the beast. A proper Anti-Cheat _shouldn't_ approve of the injection necessary to get Proton working
So I do have to keep a Windows installation myself. But Proton represents a really cool technical milestone. Weird the way people talk about tech in games.
>These are the same people who say they don't want to run Linux because they don't want to compile their sound card drivers. They are already way outside of rational territory
Not wanting to "compile their sound card drivers" sounds like a very rational argument to me...
>In their minds Linux hasn't changed a bit since 1999
It did, but other OSes are also a moving target.
Seen Linux (the vlogger) try to get a basic system running?
(And I'm an old UNIX+Linux hat with 25 years of experience).
I use Linux in various forms since 1995's Summer, starting with Slackware 2.0, and yes GNU/Linux desktop experience is still far behind the alternatives.
I am remembered of it every day I have to reboot Network Manager on Ubuntu LTS to reconnect to my wlan, on a EEE PC that was even sold with Linux on it.
When this netbook dies, the only desktops I will keep using are on the form of Android, VMWare or some headless stuff, anything beyond POSIX APIs is always expecting too much.
> because they don't want to compile their sound card drivers
I literally had to do this to get my sound card working on a new laptop recently. I know it is partially my fault for choosing such a new laptop and expecting Linux to work on it, but still... it's not an unreasonable expectation to have in 2022.
Nothing's special about 2022. The reason Linux doesn't work out of the box with things that aren't in a lot of developers' hands yet hasn't changed. What's reasonable about thinking that the year matters?
Google all the sound problems people had and the solutions for the 2020 Dell XPS 17. People have that attitude because it still happens from time to time. It’s much rarer. But it still happens.
I had to compile a driver for my USB gaming keyboard, from a third party source, btw that keyboard worked seamlessly on my windows machine. Whats your point?
I use linux exclusively for work, and windows exclusively for Personal use because many top games don’t even run on linux, yes I tried proton. And Adobe doesn’t even want to bless Linux, no Gimp is no where near to Photoshop.
Also, software that doesn't run in wine these days is usually due to anti-piracy/anti-cheat as they try to dig into your operating system. Since these are anti-ethical to how Linux works, if you are fine running these sorts of things then why would you try and switch to Linux?
Redragon keyboard. And where I tried to imply im trying to switch to linux I don’t know, I balance my usage with linux and windows. If running major softwares used by lots of people is anti-ethical to linux, people must stop suggesting it as a daily driver for them. Speak to any gamer about if he wants anti-cheat or privacy, without hesitation they will say anti-cheat, so stop suggest proton as a magical replacement. If linux wants to be a daily driver, it needs to be as seamless as windows. I don’t want to spend dozens of hours on what config, or driver i have to tinker with to get some basic software or hardware support. Linux is not there yet. btw Nvidia graphics are proprietary and not exactly opensource, since its anti ethical to linux philosophy, shall we stop using graphic cards?
Nvidia isn't the only game in town, my AMD GPU works great. But also I didn't say that running closed source is against Linux. Trying to run software rootkits for other OS' is anti-ethical to Linux.
And whenever anyone asks if they should switch to Linux,if all they want it to be is a Windows emulator then I would recommend against it.
> These are the same people who say they don't want to run Linux because they don't want to compile their sound card drivers. They are already way outside of rational territory and deep into religious territory. In their minds Linux hasn't changed a bit since 1999, even though if you were to compare mac os from that time period against modern linux, they would become enraged at the unfairness and injustice.
In common hardware and software configurations things have gotten way better indeed!
However, if you venture outside of what's commonly available, expect trouble, same as you'd get with FreeBSD and most other OSes out there.
For example, i bought a netbook much like this one: https://techbite.eu/en/laptopy/laptop-zin-3-14-1 because it fit within my price point (a university student at the time) and my other requirements for something lightweight and compact for note taking.
Sadly, upon purging Windows from it (since 4 GB of RAM total made it unusable) and replacing it with Debian, Ubuntu, Fedora or Linux Mint (in approx. that order), i ran into quite a few issues:
- on some distros (Fedora in particular, i think one or two more) the touchpad didn't work by default, some piece of configuration needed to be edited
- on some distros (can't remember which), sound didn't appear to be working correctly
- on none of the distros Wi-Fi seemed to work correctly out of the box
That last bit was especially sad, since the netbook doesn't have an ethernet port by itself, so i had to do an air gapped install of some custom drivers that someone had patched together... but not before discovering that most distros out there don't have GCC out of the box (or some of the other dependencies, can't remember) and that putting it on a USB stick is curiously difficult, when the install will fail unless you also manage to download all of the dependencies that you need for the package and installing all of them at the same time (no CD/DVD drive either, by the way). Oh, and curiously compiling drivers and messing around with DKMS or whatever isn't as straightforward as one might always expect, something about headers and versions and whatnot...
In the end, i got it working, sort of. After realizing that the fingerprint scanner which was working in Windows isn't detected at all as a device on Linux, i just gave up on that particular aspect and took Wi-Fi working as enough of a success for my needs at the time. Also, it seemed like the fingerprint scanning software on Linux had a very specific set of supported hardware, a la sound drivers in these older days.
Now, you could argue that i'm using a configuration that isn't necessarily supported with some seemingly random piece of hardware and you'd probably be right in doing so, since the official drivers were only available for Windows on the manufacturer's site. But i'd argue that it doesn't really matter because the outcome is what's important and what will impact how people feel about the OS.
The takeaway here is that no matter what you do, you probably should stick to the more common hardware configurations and devices out there. And not just in regards to Linux, but also things like your smartphones (my rugged model hasn't received any actual updates in a while because the manufacturers clearly don't care, as it turns out) and even SoC devices (e.g. Raspberry Pi over alternatives, unless you can get a really good deal).
That said, Linux has come a long way and i hope that most of the distros out there will just keep getting better, since Mint + XFCE made the resources constrained hardware pretty usable, as would Debian + XFCE and others (DEs like LXDE or LXQt or whatever). That's pretty cool, in my eyes!
Thanks, though nowadays i primarily use my desktop. At the time, for 215 euros, the netbook was suitable for the use case that i needed it to serve, though it definitely did take a bit of tinkering.
Now, if i actually wanted a laptop as a daily driver with Linux on it, i'd perhaps look into the direction of the ThinkPad models, either older or newer ones, whichever i could afford. In my experience, they have superior keyboards, good I/O, good driver support and are built to be reasonably sturdy (as long as you don't mind the bulkiness)! Granted, Lenovo might ruin the series in the future yet, after the whole rootkit scandal a few years ago.
Even if you do get dedicated mac instances, managing them is a bit of a nightmare since MacOS isn't designed to be headless.