Hacker News new | past | comments | ask | show | jobs | submit login

Love to see the competition between the projects trying to get linux running on the m1. Though I think they will hit a wall trying to enable GPU support.

I think opening up just enough to enable this effort also serves as some good nerd marketing for Apple. This race keeps the m1 in the news regularly, giving hope to those who want a low-power and performant ARM machine that wouldn't otherwise consider an apple machine.




Someone has begun digging the GPU.

https://rosenzweig.io/blog/asahi-gpu-part-1.html


It's not just someone, she's responsible for the Panfrost drivers so there's hope :)


Ha nice, she expects to find an eldritch horror in there somewhere.


Nice, that was a HN worthy article by itself.


You might like the discussion. It was posted 13 days ago, so many people were a little preoccupied with US events.

https://news.ycombinator.com/item?id=25673631


heh, between my clicky keyboard and his, I'm losing my mind a bit lol


Does it actually require any serious development or it is just mostly tweaking and changing things here and there? I am sorry if that sounds ignorant, but I thought these are just low hanging fruits to harvest. Also why Apple wouldn't do that themselves? To me it is an opposite to "nerd marketing", a big middle finger to Linux users - essentially "you are on your own".


A middle finger from Apple would be locking the bootloader–keeping it open, plus providing minimal tooling and telling people to figure it out, is about as close to "we'd love to see what you'll do with it" as Apple could possibly give.

(Dealing with the GPU is going to be the majority of the work, I'd think.)


> "we'd love to see what you'll do with it"

...without the documentation that would help you.

When Broadcom act like this they're considered villains and we're recommended to stay away from their hardware. But when Apple do it, they're being benevolent?

And that's ignoring the fact that I could actually get Broadcom documentation in exchange for dollars and NDA.


Broadcom is selling hardware with the intention to run Linux on it, I guess that is the main difference.


Apple unlocked the bootloader which is certainly signaling intent.


Maybe. Certainly people within Apple would have thought about Linux for this. But Apple would need to provide some form of mechanism for unlocked bootloaders anyway to facilitate kernel/driver developers and security researchers, so I'm pretty sure other OSes is not the main reason they do this.

It does work out for Apple in the end. Their current standard 10 years' support will look quite short now Moore's law is dead and their hardware has barely any moving parts. But they'll shush some complaints if up to date third party OSes are available in 2030.


> ...without the documentation that would help you.

Well, it's not really worse than their usual documentation on products they officially support: https://www.caseyliss.com/2020/11/10/on-apples-pisspoor-docu...


While Correlium is a bit of a minefield for obvious reasons, I don't understand why Apple hasn't blessed Marcan's work. I wouldn't expect them to commit any development resources of their own, but I'd think it would be in their interest to (A) provide Marcan with some documentation and (B) make an engineer available to answer occasional questions.

Apple makes money selling hardware, and Linux support will sell more hardware. Perhaps not much more, but for a commensurately low amount of effort. What does Apple gain by forcing Marcan to reverse engineer everything?


I can't see why they would? Marcan is capable to be sure, but he's also a random guy with a Patreon. Why would Apple ever officially bless his work? I'd sooner seem them collaborating with Corellium, because that at least gives them a corporate entity to interact with. Plus, like, releasing documentation without giving away the stuff they want to keep to themselves, and without promising too much and having it break later, is work in and of itself that Apple is really not getting anything from. I mean, this is the company that still FairPlays apps, so…


Hypothetical question: If Microsoft wanted to port Windows to the M1 (as Phil Schiller said was their choice), would you expect Microsoft to have to reverse engineer everything? Or would Apple share documentation and expertise, under the logic that Windows support will increase Mac hardware sales, if only a small amount?

I realize that Marcan isn't Microsoft—but he's not quite "a random guy with a Patreon" either. He's a professional freelancer, and I'm sure he has an LLC† and a set of professional references he can point to.

Put another way—on a scale between "Marcan" and "Microsoft", where is the threshold in which Apple would be helpful? I don't personally see a huge difference between a one-person LLC and a 100,000-person company in this regard. If anything, the 100,000 person company offers more opportunities for things to get leaked.

---

† Or something similar.


It always comes down to "it doesn't benefit them" eh…

There are some interesting situations though. Like in the big GPU world it's very common to document the ISA. Even nvidia does. I suppose that's because it benefits the vendor when games and GPGPU compute programs optimize for their GPUs, down to the assembly level. It's sad that Apple's approach is "just use Metal" rather than fully enabling developers to get to the actual… well, "metal"


That would definitely be crossing the line. But I wonder if this behaviour of Apple is another avenue of stifling competition - that is how many smart people this will get involved that otherwise could have worked on a competing product? Then you can see how much resources any company dealing with Apple has to commit just to make sure their software keep up with Apple updates - that inhibits their growth and thus keeps Apple on top.


> Then you can see how much resources any company dealing with Apple has to commit just to make sure their software keep up with Apple updates

Apple‘s competitors have sufficient cash flows to pay whatever they need to get the best people. They just don’t want to.


To be honest I’m amazed Apple even cares enough one way or another that they mentioned Linux virtualization in the M1 announcement. But it’s not a middle finger, this was more or less exactly how they handled multiboot on Intel: let the community figure out a solution, see if it gets uptake, support it with a first party solution if it does. That’s how we got Boot Camp, as there was a lot of interest in booting Windows at the time.

It’s a good sign that the latest betas (11.2 IIRC) officially support multiboot in the UI. That’s a good indication Apple sees the level of interest in Linux on M1 that they intend to at least let it happen.

I’d say it’s still up in the air whether they’ll go for full first party support with drivers or an open spec, but it’s definitely not out of the question. And they may even have direct interest in it, as I’m sure they’d like to get the benefits of their hardware in their data centers.


So essentially Apple is exploiting its consumers and get free research and development without having to pay salaries and tax? Probably that's why they are worth so much. I am only amazed that there is so many people willing to do this job for Apple for free - it would be a different ball game is macOS was open source, but sacrificing your own time and resources to enhance a commercial product... people are weird.


That’s... an incredibly bold take, especially on a forum operated by VCs, who certainly are familiar with the concept of finding product-market fit. Apple is observing the interests of people who use their products to help prioritize product development decisions.

Maybe the people doing this for free are just interested in benefitting from the result? As many people who work for free on open source do.

As far as I’m aware, there is no free (as in beer) hardware that runs Linux. Someone has put the effort into running Linux on every single for-profit/for-pay platform it runs on.

Are you under the mistaken impression I was suggesting that Apple waits for a community solution to be developed then packages that as a product? As far as I’m aware they didn’t do that with Boot Camp, but instead offered in-house drivers and blessed boot loaders and proprietary UI/UX for accessing both.


Well, that's why all the big companies open source stuff.

They're hoping to get increased for themselves, increased adoption of their internal tools outside of the company (easier recruiting plus purely internal tools are notorious for rotting quickly) and... free labor.


Just from a skim it seems like there is a new interrupt controller driver. The copyright header credits Linus Torvalds so they probably got started based on copying an existing one, but that sounds like substantial work and ongoing maintenance.


The interesting thing here is that now, when they own the CPU and GPU, and when MacOS is free, they probably might be more open to letting anyone install any OS on it. You want a Linux/BSD/Windows on M1, and you're not hurting any of their possible revenue streams, so why the hell not let you buy their hardware and throw whatever OS on it.

Somebody wants to copy the hardware over and sell it for half price? Yeah, good luck reproducing the M1.

Opening the boot loader to allow for Linux is quite an opposite of a middle finger, tbh. I don't know if they will divert some guys from working on MacOS towards Linux support, but this is already looking much better than before.


Were they ever opposed to running a different OS on their hardware? They released bootcamp, to help you do it for windows at least.

They don’t want you installing their OS on other hardware, not the reverse.


FreeBSD that didn't have a trillion-dollar company behind it never got such a treatment. They _might_ get it now.


I know it’s entering (dark?) gray territory, license wise, but has anybody ever attempted to wrap a Mac OS driver in a Linux compatibility layer?


Oh, like the old ndiswrapper approach for various windows XP NIC drivers. Which worked reasonably well...I remember using it for some laptop with a Realtek chip. https://en.m.wikipedia.org/wiki/NDISwrapper


marcan had answered it in one of the live streams - his opinion was that it was a last-ditch effort that shouldn't be required for most usecases.

Perhaps for some of the peripheral stuff (such as the touchbar), but the GPU ought not to need it.


Even Nvidia publish stuff for the Nouveau drivers now.

I wouldn't bet on it. Apple are very insular on matters like this, it's their toy, end of.


What will be interesting though is to measure the raw performance of this initial CPU only rendering. For now on it's a still image we don't know if it's sluggish as hell or actually pretty decent even without a GPU.

If the latest is true that could prove to be another prestige point for the M1.


A good number of comments here mention dealing with the GPU is going to be a major hurdle. What makes porting GPU drivers significantly more challenging than everything else?


They're very complex, very stateful devices which also run their own compiled shader code. Not to mention auxiliary DSPs like video decoders (not sure if M1 has it as part of GPU or a separate block), power gating control and many many more.

They may have in order of 100 registers to talk to them and they're horribly proprietary with pretty much no standardisation.

Reverse engineering that is hellish at best - you can see projects like nouveau which barely manages to get nVidia cores up and working without help from the manufacturer. And that's after years and years of development.


The hurdle Noveau is facing is that some things, like reclocking, need firmware loaded onto the card. The firmware is not in non-volatile memory on the hardware, but a file shipped with drivers, the one shipped with proprietary drivers is not redistributable and if you wanted to make your own, it needs to be signed by Nvidia anyway.

That's pretty much game over for Noveau, and it is not due to difficulties in figuring out registers and NV ISA.


The reclocking never really worked well on chips that were older than this signing requirement either.

But that's a bit besides the point :)


Why would you make your FW blobs be non-redistributable? An FW blob has only the purpose of running your hardware for your customers.

I can understand preventing FW patching, maybe. But redistributing the manufacturer's genuine FW, why not?


> What makes porting GPU drivers significantly more challenging than everything else?

Multiple reasons:

1) GPU manufacturers are notorious for not publishing documentation out of IP/patent concerns. Worst offender is NVIDIA here.

2) For embedded GPUs there isn't much interest in open source drivers... the big customers (think Samsung and the likes) have direct support from the chip design vendor and get drop-in drivers as part of the board support package (BSP, basically a conglomerate of bootloader, kernel+modules+initrd, firmware blobs for components such as wifi) so they don't need OSS drivers

3) The mobile GPU space is... splintered. With desktops you got the three major players AMD/ATI, NVIDIA and Intel's built-in Iris, in the GPU space there are more.


> GPU manufacturers are notorious for not publishing documentation out of IP/patent concerns. Worst offender is NVIDIA here.

I think easily Apple takes the cake from nVidia - they don't even provide drivers for anything but their platforms (that is for their proprietary GPU core). The GPU core that's actually in the M1.


A lot of this comment I don't understand how it applies to the Apple M1. I'm not saying it doesn't. I'm completely ignorant of these things. Am I just missing it?


Apple's M1 chip has a custom GPU built into it. There is no documentation on how that GPU works and Apple hasn't released any.

Making any modern GPU work is a lot of work because of how complicated they are. That's even with the full documentation.

In the Apple M1 case, the GPU will have to be reverse engineered to understand how it works, then a driver will need to be written for Linux that supports it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: