I grab a machine and install Linux, and it works more or less out of the box. Maybe a few fixable quirks. And I don't use Thinkpads.
I try to use Windows or macos, and it's a coin toss. Windows handling USB like hot garbage (hub balancing/buffer sizes leading to devices unable to activate, webcams glitching, input lagging at random intervals), display issues (macos doesn't support displayport MST), dock connectivity problems (macos freezing or crashing when connected except when it suddenly works for a day, Windows playing disconnect/reconnect sounds in a loop when the machine goes idle), and more, including just today out inexplicable crashing.
Install Linux or plug all the "made for windows/macOS" hardware into a Linux box, and all the problems went away.
My conclusion, supported by having been a proprietary kernel driver developer for Windows, FreeBSD and Linux, is that any hardware and driver combo tends to be a coin toss, irrespective of platform.
But with Linux, drivers that would otherwise be abandoned after a project was shipped, get a chance at being fixed and improved that their proprietary counterparts can never even dream of.
First, non-desktop uses of Linux significantly outnumber uses of Windows and macOS in general, and a large majority of drivers and functionality is shared there.
Second, drivers not made by the usual giants are, as I mentioned earlier and experienced first hand, written and shipped once, maybe with a few updates for obvious issues, but this shit is harder than you think, with obscure uncaught bugs littered all over the place. Drivers need pretty much perpetual maintenance for all but the simplest blinkenlights.
Third, even "desktop" drivers are run through their places in server environments, through e.g. workloads like Stadia.
Fourth, proprietary drivers are not subject to any scrutiny whatsoever, whereas you won't get past the gatekeepers if you don't pull your shit together for the open source kernels.
Popularity does not fix unmaintained code. Giving even just one annoyed and skilled person the ability to change the code does. And sometimes, external companies like Collabora will decide to overhaul things, which they again can't do for a proprietary driver.
Go to your favorite computer store. Randomly pick 5 laptops, regardless of the price. So no cherry picking.
Use these laptops with Windows installed on them, for a reasonably long period, for example 1 month, as your daily driver. Perform varied tasks on them, such as printing, connecting to external displays, to projectors, other peripherals, playing modern 3D games on them, etc.
Then do the same with Linux.
I'm willing to bet $100 that on average Windows will run better on them, have a longer lasting battery life, better network connectivity, etc.
And if you're trying to tell me that on average Linux runs better than MacOS on Apple laptops and desktops, then this discussion is not worth continuing, we both probably have better things to do with our time.
You're very right that there is no value in continuing a discussion if that's the level of debate you're presenting. I'm off.
Linux as a personal operating system got WAY better over the last years, sure, but you can't seriously argue that it got Windows AND MacOS beat.
Now, a mac on its own tends to work quite well out of the box, but this does not hold for peripherals, and I feel like the machines always end up developing... quirks.
I always felt that the path you picked just gives you the sum of all problems with few of the benefits. I could maybe do the other way around for compat, but the laptop wouldn't be able to stay on this side of the balcony railing for long if I did it the way suggested... :|
Apples, oranges.
But I guess that's kinda in-line with this thread, that Macs are a pain to run Linux on.
And actually, Windows 10 is also approaching this state, but it is not there yet.
I last installed drivers on Windows late last year.
So your example seems to be completely unrelated to the question.
Based on...? Apple is pretty straightforward: they support hardware until they don't. And they're quite explicit about ending support and it's almost always a major release. You might be able to hack support after that, but I've literally never had it be a "toss-up" about when Apple was or wasn't supporting their own hardware.
As for Windows... I've got a 10 year old 2600k based desktop that runs the latest version of windows flawlessly. I guess if you go back 20? 30? 40? years you might find something that can't run the latest version of windows, but you're going to be down a really, REALLY obscure rabbit hole. I can't say I ever recall it being a coin toss, it was about 10 seconds on google of finding or not finding a driver.
Linux on the other hand... the support of hardware is awesome, but determining if something is or isn't supported is generally an afternoon of reading mailing lists.
My favourite example is one that the OP mentioned - not supporting multiple stream transport on Displayport. For those who aren't familiar, Displayport MST is a feature that allows multiple streams over one Displayport cable. Some monitors support this directly, meaning you can have
Macbook -> Display1 -> Display2
Macbook -> Display1
Macbook -> Display2
Except they don't support it for this.
What they support MST for is to allow vastly-higher-resolution displays on macOS, such as 5K displays, by splitting the display image over multiple stream transports to bypass the limit on resolutions and refresh rates that Displayport provides (or provided at the time).
For some reason, they just haven't bothered to implement MST to allow for multiple displays; it exists and is supported, but only for high-resolution displays. This is great if you're googling around and see that macOS supports MST, then you buy monitors which support MST and hey surprise it doesn't work and there's literally no indication why.
Dell makes some Displayport monitors which support daisy chaining.
Linux, however, is another story. Bad sleep support, forget about printing, scanning, GPGPU computing, etc. We use it when we have to.
I upgraded from thinkpad x240 on which sleep worked perfectly too.
What phone are you having issues with? Every android phone I’ve used will communicate with adb. iPhone has never used USB mass storage, and support for that has nothing to do with MacOS.
Can’t comment on the daisy chain issue, I just learned that was a thing.
Screen will remain black. Or, screen will power on, display nothing. Or, screen will power on, mouse cursor will appear, but no password prompt.
No such problem with Linux.
Yeah there are things Linux doesn't support but just don't buy them. The things that it does support generally don't require any driver installation.
macOS does support MST! It actually does! But it only supports it for splitting one display image over multiple streams, to overcome bandwidth limits on Displayport streams.
For providing a signal to very-high-pixel-count displays, macOS uses MST.
For providing multiple displayport signals to multiple displays? Nope, not implemented.
Imagine my frustration after a day of googling and finding out that macOS supports the feature we wanted, but not the use that we wanted.
MST is supported specifically for early 4k displays that had scalers that couldn't handle 4k60, but could handle half the resolution, so they sent two streams. But that wasn't a bandwidth limitation; old MST 4k displays and modern SST 4k displays both used a single HBR2 link.
MSTs primary usecase today is multiple displays, by "daisy-chaining" through built-in MST bridges, dual DP dongles or docks.
Support for hacky displays is less interesting, and hopefully not relevant today.
The screens light up from the same DP stream, which is also why you can have, say, 2x 4k@60hz monitors in this configuration where true MST would need to drop it to at least 30Hz, or lower res.
May I ask how you learned how to do this? I'd like to learn too! I had a great experience developing a Linux user space driver for my own laptop's LEDs. Couldn't figure out how to control the fans though.
2. Play around with embedded. You can use an arduino, but get rid of the Arduino IDE. Once you've ridded yourself from their weird environment and code in C, you're pretty close to what kernel programming is: Direct hardware control, debugging over a serial console, and if you mess up you don't get saved by a segfault.
You can upgrade to playing with ARM boards later if you want. Things like a Raspberry Pi can also be useful to boot random kernels you've built later on for HW stuff, otherwise you can use VMs. QEMU can boot a kernel file directly, which makes debugging easier.
3. Look at one of the tutorial for writing hello-world kernel modules. There's also usually smaller cleanup tasks you can do to get started submitting work. Looking at Linux and FreeBSD both can be useful, and things like Plan9 have very small kernels that can be used as reference. Linux and FreeBSD are not that different. (Windows is a pain with really weird interfaces, but it can be made to work.)
4. Find something you want to do with the kernel or fix in it.
Kernel developers aren't that common, so I imagine a lot of places are willing to train people. The first job I had doing kernel work was pretty open, and just threw minor stuff to begin with at me, e.g. "things stopped working after kernel X.Y, figure out what happened". Bisecting, testing in VMs, printk'ing a lot to compare state, stuff like that. I later ended up being the owner of the kernel drivers of all our platforms, so I guess I did okay. :)
But not having the right documentation was a challenge. MSDN is okay, but the weird mechanics of MDL chains don't really get discussed on Stack Overflow.
How do people overcome this? I managed to reverse my laptop's LED commands: they were implemented via USB so I used wireshark to intercept and analyze the data sent by the proprietary vendor software. What if it's some ACPI thing though? Or some memory mapped I/O chip? How do people figure out how it works?
It isn't like the lack of support is Linux developers' fault. Apple doesn't provide datasheets for their hardware, and they don't cooperate with developers writing drivers for their custom hardware.
There are hundreds, if not thousands, of ARM SoCs that "run Linux", but that doesn't mean much because they're actually running Linux forks, and someone needs to maintain those forks, and build and release custom images for each SoC. I don't see M1 Macs diverting from that fate without significant support from Apple themselves.
Many of these Arm SoCs are running linux forks because there are some terrible baked in drivers, and no spec associated with them. Still, that is a step ahead of the M1 as there are at least drivers that don't have to be decompiled and reverse engineered.
The thing is, that these SoCs have no PCIe or other enumerable bus. You (=your kernel) must know what hardware it is running on and which drivers to load without being able to ask the hardware, what is really present. One wrong POKE and the entire system can hang.
And that is on top of the problem, how to boot in the first place. There is not such thing as UEFI on these SoCs. Every single one is a special snowflake with its own special way to boot.
Hence, kernels built for specific systems, even if it is just Device Tree.
Most device vendors don't really have a need or incentive to use this, though. A generic kernel is much larger and wastes flash space, and most vendors don't care about running anything but their OS image on it, so they of course just build a kernel specific to their hardware.
But in theory it should be possible at some point to use a generic ARM Debian installer to install your own OS on a random ARM device, assuming the relevant drivers and device tree have been upstreamed.
Again, the problem isn't that the mainline kernel _couldnt_ support these boards, is that no one wants to put in the work to bring their implementations up to the standards of the mainline kernel.
Eh, the majority of embedded crap comes with U-Boot (sometimes built without EFI support but always with Linux image support, at least).
It appears what should be being asked for is Apple to commit resources to natively support things like: Docker, Kubernetes, Virtualization and Linux drivers on their M1 Macs going forward.
> Apple designed their own interrupt controller, the Apple Interrupt Controller (AIC), not compatible with either of the major ARM GIC standards. And not only that: the timer interrupts - normally connected to a regular per-CPU interrupt on ARM - are instead routed to the FIQ, an abstruse architectural feature, seen more frequently in the old 32-bit ARM days. Naturally, Linux kernel did not support delivering any interrupts via the FIQ path, so we had to add that.
and many others
https://corellium.com/blog/linux-m1
It is on top of HN now https://news.ycombinator.com/item?id=25859907
You can see a list of differences between Macs and standard PCs here: https://en.wikipedia.org/wiki/Apple%E2%80%93Intel_architectu...
However, I’m optimistic that these will be mostly usable on Linux before they’re too obsolete or outdated. The platform is so popular and iconic that it’s drawing a lot of attention from Linux devs and reverse engineering crowds.
That's sound advice.
As someone who doesn't use Linux as their daily driver, can I expect Linux to run perfectly in a VM on an M1 Mac?
Sure the M1 is the new shiny, and people will be attracted to it in the short term, which might boost reverse-engineering efforts. But I expect that to die down as people get frustrated, and we'll have the same (or worse) situation as we do running Linux on Intel Macs.
Ethernet, waking up from sleep mode, brightness adjustment... take your pick.
A reminder that not only software bitrots, but hardware too. Make sure not to buy a Stinkpad (or any hardware) with non-replaceable parts!
(and I just bought an M1 Macbook Pro...)
Software will catch up with the M1, I hope!
Can't wait for [Your least favourite Electron App] to use even more CPU cycles!
Correct - that is why I bought a Thinkpad X1 Extreme - both SSD and RAM are user replaceable. Granted its not as thin as X1 Carbon but I don't need to carry it around much so that is not a big issue for me.
Can work in the meantime, before you have a new machine.
But I don't have a SATA reader either, so I'd need one of those :-)
Though, if you want a serviceable system, I'd stay away from Apple - the RAM in your new M1 mac is actually included in the SoC, not sure how much you'd like to get in there!
Sure, documentation helps, but it is overrated--people get lots of things working by reverse engineering.
https://shop.solid-run.com/product-category/embedded-compute...
You get upgradable ram, a PCIe slot for your favorite GPU/etc, and actual mainline linux support sufficient to boot most random linux distros (ok the onboard 10G+ nic might not work without patches).
Its not the fastest machine around (A72s) but there are 16 of them, so it does a decent job of building ARM software, and running VMs.
In fact I made the FreeBSD port of amdgpu work on my Macchiatobin :) Absolutely smooth experience btw, video output works even in UEFI (it actually runs the GOP driver from the card in QEMU), amdgpu works perfectly (played vkquake, supertuxkart, openmw, etc.)
[1]: https://www.jeffgeerling.com/blog/2020/external-gpus-and-ras...
So, yes you have to bring some storage, ram, ps and case. But one can cheap out and probably get all three for <$200, or go crazy and put 64G of ECC, and a few TB of storage in it. The cheaper off the shelf RAM/storage makes it a lot cheaper than a loaded mini with similar specifications.
And as another commenter points out, yes fairly common GPUs tend to work in it. Its not perfect, for that you have to spend more, but the time you will spend fighting with the mac mini+linux is going to be worth the difference.
Perhaps you're meaning to say Apple will iterate the hardware faster than people can add Linux support? That's plausible. It also was the status quo of Linux on PCs for many years. (Still the case with some hardware I guess.) That hasn't killed Linux yet.
That driver has been upstreamed, but I hear the 2017 and onward touchbar MBPs still require and out-of-tree driver, and a similar level of things don't work.
In 2019 I finally gave up and got a Dell XPS13. It's... basically perfect? The keyboard doesn't suck like recent MacBooks, though the touchpad isn't quite as nice (though really, it's perfectly fine). The only thing that doesn't work is the fingerprint reader, but I knew that going in and didn't care. And subjectively the hardware isn't as pretty, but... oh well. On the plus side, I really do like the "soft touch" palm rest better than the harsh aluminum of the MacBook.
I'm definitely interested in the Linux-on-M1 project's progress from an intellectual curiosity standpoint, but I'm expecting long-term as a user it'll be just as -- if not more -- frustrating as running Linux on any Intel MacBook from the last 5 years, which means I won't bother.
My personal laptop is an HP Envy X360 with a Ryzen 5 2500U. That was rough when it came out. Windows update updated the bios on the laptop which installed a new GPU firmware that wasn't supported by the Linux driver for a few months. It's been solid since kernel 5.0 came out.
IMHO, the Linux experience on the AMD APUs is better than the Windows experience due to how rough the AMD windows drivers can be for the APUs. The fans are always shrieking at me under Windows but at idle they are off in Linux and the battery lasts significantly longer.
The computer never woke and needed to be hard-rebooted if it was ever allowed to suspend? I ran into this after installing Linux on a MacBook, downgrading the kernel to an old LTS release eventually worked.
I think right now the new M1 machines are actually priced pretty reasonable. If they'd run Linux, I would buy them in an instant.
I mean, try to match the Air with a Thinkpad, especially if you consider the screen. I think there is not even one recent AMD Thinkpad with a > FHD screen. And who wants a 2020 Intel machine?
Edit: To make this clear: No Linux, no Mac for me (as I don't believe in MacOS's future at all). But even considering the horrible keyboard, I think the M1 macs are totally worth it just for the hardware. That's a first. And I am the kind of person who feels all warm and fuzzy over ejecting an ultrabay hard drive, or changing RAM/display in < 5 minutes in a laptop.
There are Mac desktops as well. That said, I'd say the list of mandatory components on a laptop is:
- Decent GPU Drivers
- Workable power management with sleep/ awake
- Trackpad (this should be straight forward)
The webcam, and brightness controls are stretch goals. I can't imaging the trackpad is vastly different from currently shipping ones. The Webcam might cause some significant headaches since Apple secures that fairly tightly.
The onboard wifi modem is likely worthless, from what I recall, many of them are even in Windows laptops due to proprietary drivers.
Hopefully with a little bit of money and some enthusiasm from the team, they'll be able to make more progress.
A lot of people bitching about this being a waste of effort, but all the things they do here have follow on effects. If they improve the Broadcom drivers for the M1, much of that work will directly benefit everyone else on Broadcom.
Honestly this sounds exactly like my experience with linux on any laptop, including three thinkpads.
Linux is a great desktop and server OS but the UX of a laptop actually demands a certain level of polish/fit-and-finish that linux desktop environments just don't have, otherwise it's constantly getting in your way.
Apple clearly doesn't seem interested. The M1 is just a scaled-up version of the iDevice SoCs. From the reverse engineering we've seen so far, it is extremely clear that not even a single step towards any standardization was taken. It's very much the ad-hoc hodgepodge of embedded crap companies build when they only care about their own complete product and don't allocate any budget towards any "refactoring" that doesn't directly benefit the end product.
They use some ancient Samsung UART for debug (because the first iPhones used a Samsung SoC?), old P.A. Semi I2C controller, the Synopsys DesignWare USB 3 controller (just like some random cheap Allwinner/Rockchip/etc), and here's the fucking kicker, a custom Apple interrupt controller and a custom IOMMU too. These probably predate GICv2/3 at least. But there was no reason for them to switch to the standard Arm GIC and SMMU so they didn't >_<
If you want something working, I'd also not recommend using hardware from someone like Apple.
Yes, it will have to be RE'd. Yes, that takes time.
A Mac with subpar support for a webcam, energy saving, suspend/resume, the trackpad, brightness/volume controls, etc is not a laptop, it's an expensive paperweight.
In my opinion, other than doing it for the sake of learning and the challenge of it, this will lead nowhere in the long term unless you get any kind of commitment or support from Apple. And I hope I'm wrong but that's very, very unlikely to happen any time soon.