Great work and even more surprising: a great writeup (writing that as someone who always struggles to document my own work). This really gives me hope to have an usable, native Linux on the M1 machines.
I really wished Apple would see, how much benefit this would bring to their platform. Their new hardware is really exciting, the first ARM on the desktop, which doesn't just compete, but in many aspects beat current x86 chips. A lot of the Linux and tech enthusiast crowd would love to jump onto Apple Silicon. And while they might not bring huge profits by themselves, these are the people who do come up with great new technologies. Better give them a home on Apple devices. It doesn't need a complete and formal documentation of every aspect, just supporting those projects with a little bit of information would go a long way. A single engineer who would answer questions by those developers might be sufficient. So come on, Apple, do it! :)
> A mid-1987 Personal Computer World preview of the Archimedes based on the "A500 Development System" expressed enthusiasm about the computer's performance, that it "felt like the fastest computer I have ever used, by a considerable margin"
Well, in this millenium :). And while I remember the Archimedes well, this was another day and age and unfortunately it failed to gain much traction back then. A lot of bad tech could have been avoided, if it had become main stream. I fondly remember the times, when there were plenty of competing processor architectures, almost every one more interesting than the x86 architecture.
>> This is a company that actively fights right to repair and implements software DRM to lock out non-Apple authorised replacements.
But they do all these things for obvious reasons. Reasons you and I may not agree with or be happy about, but still obvious reasons. In the case of repair/replacement it's just because they want you to use expensive replacement parts, they want to lure you into their Apple stores, and they don't want any liability/accountability for repairs with 'unofficial' parts.
I don't see how providing specifications about how their GPU's work so someone can make a Linux driver out of it hurts their commercial interests or liability though. Yes people may screw up their system if they install Linux on a Mac and it doesn't boot anymore, but as long as you can still take it into an Apple store and they can restore it to MacOS, why would Apple actively fight the extremely small minority of people who want to do that? And even if more people (developers/enthusiasts) would buy M1 hardware and immediately slap Linux on it, why would they care about that? They still made the sale, and these people will still walk around with a machine with a big fat Apple logo on it?
They previously spent a lot of effort accomodating people who wanted to run Windows on Macs using Boot Camp, so why would they be worried about people running Linux on M1 macs?
Edit: I can imagine Apple want to protect their IP and hence don't want to disclose anything about out it, period. Much like NVidia and most other GPU manufacturers do. But if AMD and Intel can be OSS-friendly, Apple could be too, apparently IP protection does not have to be a deal-breaker.
As a Linux person, I have to say my iPad almost got me into becoming also an Apple person. Let's be real, Apple would not lose a single penny to inviting the Linux crowd directly, however, some of those Linux people will become Apple people. There are two reasons to not open up, for the future outlook:
1. Why tho?
2. MacOS increasing lock-down makes even Linux attractive to a wider customer base, and therefore threatening their huge, carefree software extortion business.
Personally I think, they do number 2 on their customer base. I think not opening up to Linux is an indirect admission to their unfair competition game. I think Linux support would very much limit how much they can push their DRM, subscription, software extortion and expropriation mischief. It would allow for consumer choices.
I don’t think they care, unfortunately. Apple sells billions of devices to non-techies. The user base that might run Linux or do development on Apple machines is a small fraction like 0.001% or less. The reasons behind preventing you from installing Linux is likely more a consequence of preventing device theft or software piracy.
Seconded. Despite being a genuinely challenging and complicated process with countless moving parts, it was written to be as approachable as possible. They didn't feel a need to "prove" how hard the work is by writing from deep within the weeds.
Alyssa is a hero for her work on Panfrost, which gave us open-source 3D graphics on ARM Mali GPUs. I am eternally grateful for this; the Samsung Kevin I use is the only blobless laptop currently in production, and now it has 3D accelerated graphics thanks to her work!
But part of me is sad to see her working on such closed hardware now.
Does anybody think Linux on the M1 will ever be able to touch the internal SSD? Apple has been locking that down with proprietary controllers and signed firmware since their Intel days (i.e. T1 chip). Are people really going to drag around their shiny new macbooks with an external USB-C dongle hanging off of it because that's required in order to run Linux?
I worry that the endgame here is Linux becoming Just Another MacOS App. Apple is quite happy for Linux to be a MacOS app running in their VM. Elite developers will buy Macbooks and run Linux in a VM because "we'll have Linux on the bare metal soon, it's just temporary" and that will just keep getting pushed back and pushed back and pushed back...
Apple don't block access to their NVMe controllers at all. They do appear to have a, well, interesting approach to spec compliance, but Linux is now entirely capable of handling the SSD on all x86 Apple hardware. In the M1 case the NVMe controller isn't exposed via PCI so the existing driver won't work, but there's already in-kernel abstraction between the actual NVMe code and the PCI interface, so adding an alternative shouldn't be a problem.
The M1 systems depend on some number of blobs, but the amount of non-free code required to boot one looks like it'll end up being less than a typical x86 system requires.
I have a branch adding proper NVMe platform device support based on some work by Armd. It's currently blocked on some driver deps (clock/power) and I'm working on a hypervisor for reverse engineering for now, but once those do go in (other people are working on them) it should be simple to bring up properly.
Please, please, please drop the internal SSD myth.
That isn't true, and has never been true, ever. That is a complete bullshit story made up by a YouTuber who saw that the SSD didn't show up under Linux back when the T2 Macs were released (because it didn't have a compatible driver) and decided that must mean Apple were "blocking Linux".
All internal Mac SSDs work fine under Linux these days and have for years. I have a local branch with preparatory work to bring up the M1 SSDs already (requires some driver refactoring to do it properly).
Her work on this closed hardware might define it for the future - practicalities matter. If Linux de-facto runs and even better, if it's in wise use, that makes the hardware more open and it might help bend this new platform towards openness. Getting in this early might be a benefit there too.
> Well-written apps generally require primitive restart, and it’s almost free for apps that don’t need it.
I'm really surprised that primitive restart is forced on in Metal, but they also have a hardware bit for it! Primitive restart makes your whole pipeline slower, because you can't just chunk your index list when building your vertex packets to send to the work distributors; the possibility of a primitive restart index means you have to linearly scan for it. Though I'm not a hardware guy -- maybe the degenerate tris thing makes it just as annoying in practice.
I'd guess that the limitation to force primitive restart on in Metal came from another IHV limitation (maybe old PVR chips?)
That said, you really shouldn't be using tristrips in 2021 anyway, they have poor locality, and are hard to optimize. Index buffers solve the problems that tristrips wanted to solve to begin with.
IME, a well-written app should just ignore tristrips / restartable topologies, and just use straight tri-lists.
In theory you could do parallel scan tricks to implement primitive restart at full speed, but obviously it's going to cost you and it complicates the index fetch immensely since it effectively ends up being split into two parts.
Most likely, Apple simply doesn't build GPUs big enough to run into that problem, but it makes you wonder what they're doing on their hardware with AMD GPUs.
Hopefully one day companies like Apple will be forced to disclose documentation to the devices they sell so that consumers can make the full use of them and won't have to waste time on reverse engineering.
that would put a lot of obligation on the vendor to honor some kind of contract they don't need to do today. They can change anything they want with zero cost today.
Does documentation necessarily create such an obligation? That would jeopardize most open-source projects, most of which explicitly promise no warranty.
The big issue with this is apple does not own all of the IP in a any of their hardware, much of it is a mixture of licenses from many vendors some of it owned by apple much of it just licensed.
Apples licenses for these will include very strict NDA clauses that make it impossible for apple to share the documentation they are provided but that vendor.
As long as they are "your" speakers. Subscription sounds like you're renting speakers. I know that's probably a facetious/pedantic point but it strikes to the heart of the fact that we should be calling for more accurate description of the relationship between a consumer and the hardware they acquire i.e. calling a spade a spade. You're not buying a laptop, or an M1 CPU in a metal case. You're buying a magic Apple service delivery box that happens to permit certain other uses. Customer expectations should match description should match function.
I say this as a longstanding iPhone user, and up until recently, Mac user.
Not a legal obligation but a support obligation. Documenting implies stability of an API. It says, use this thing we intend for you to use. Usually, you mark an API as deprecated, and often provide an alternative, before removing it.
Sometimes backwards compatibility is preserved even to the point of preserving bugs (especially if the companies/apps depending on it are large):
This is what Intel/AMD have done for multiple generations of their GPU hardware now for a decade or more. Hasn't stopped them from innovating. Nvidia has PTX with a proprietary steam assembler underneath which can retarget any hardware changes. Either way, Apple can offer more documentation than it currently does.
> that would put a lot of obligation on the vendor to honor some kind of contract they don't need to do today. They can change anything they want with zero cost today.
So why can't we just allow them to keep making those changes, but still have to document them? I'm sure they document them internally anyway.
Except it won't - companies which are fully open source won't have any additional costs, and their products can be priced the same as normal.
It's only companies who have fully closed tech will have to pay the tax, and really that tax is compensating the rest of the country for the work and knowledge that company wants to keep secret.
No, this applies only to APIs, which are documented as such. The users of such APIs might have a certain expectation of long-term support. This is talking about documentation of the device which is sold, the software equivalent of providing schematics to eletrical devices. Which for a long time was quite common. You could buy stereo amplifiers with complete schematics. They don't create an obligation that future products have the same schematics, their purpose is solely for the repair of the device sold.
Then you'll probably get a link to a zip on the very bottom of the "legal >> open source" section of their website with badly auto-generated API docs without any comments or context, knowing big closed-source software orgs.
Right to repair. Hasn't happened because it's not a right yet.
Alternatively maybe anti trust, since using your monopoly on hardware to get a monopoly on software which is the essence of anti trust anyways. Hasn't happened because anti trust enforcement is really weak. Probably also doesn't force documentation.
Alternatively copyright and patent misuse, which is using your government granted monopoly on creating the exact hardware (copyright), or some of the features in the hardware (patents) to get a monopoly in an adjacent area (running software on that hardware) voiding the copyrights and patents. Hasn't happened because while the law exists (in common law) the courts apply it very conservatively. Also probably doesn't get documentation, just the right to run things on it.
Alternatively an interpretation of the quid quo pro of intellectual property (i.e. you disclose something in exchange for a temporary monopoly) being interpreted more strongly, such that you have to disclose the details of the internals to get intellectual property rights. Hasn't happened yet because today the quid quo pro isn't interpreted that strongly.
The interactions between a silicon chip and software drivers has nothing to do with right to repair. Never has been.
> Alternatively maybe anti trust, since using your monopoly on hardware to get a monopoly on software
Apple doesn't have a monopoly on any hardware, except insofar as any company has a natural monopoly on their own products, as made explicitly legal by copyright and patent laws.
Furthermore, one has to remember that there's a world outside of commodity PC hardware. The notion of hardware and software being separate is the rare exception, not the rule. Other than commodity PC computer hardware, nearly every product sold is both software and hardware bundled as a unit, with no marketplace expectation of end users replacing the software with an alternative. Whether you're talking about a car, washing machine, television, digital camera, microwave oven, garage door opener, CD player, indoor-outdoor thermometer, label printer, or an air conditioner, the software that comes with it is seen as part of the product.
In fact, this is even true for many computer components—companies like Nvidia aren't being any more helpful about their GPUs as Apple is with theirs.
Apple's computers straddle an interesting boundary between consumer devices and commodity PCs. But make no mistake, Apple isn't obligated to do anything here. You're not entitled to something because you want it.
> using your government granted monopoly on creating the exact hardware (copyright), or some of the features in the hardware (patents) to get a monopoly in an adjacent area (running software on that hardware)
Obviously legal. See above.
> Alternatively an interpretation of the quid quo pro of intellectual property
> The interactions between a silicon chip and software drivers has nothing to do with right to repair. Never has been.
Well, that's perhaps because that interaction's importance for the functioning of ubuquitous things in life is a relatively recent thing. I don't understand why there's supposed to be some fundamental reason why we can't change our laws to encompass also the right to repair software, or to the right to repair the interactions between hardware and software. Sure, these things aren't rights today – but who's to say we can't make it so?
I didn’t say that new rights couldn’t be established in the future, only that Right to Repair does not now and has not in the past ever claimed to encompass a right to the source code of proprietary commercial software.
> The interactions between a silicon chip and software drivers has nothing to do with right to repair. Never has been.
Software bugs... you could reasonably end up with a right to fix them given the current direction of right to repair lobbying. And that right might include the right to documentation.
> Apple doesn't have a monopoly on any hardware, except insofar as any company has a natural monopoly on their own products, as made explicitly legal by copyright and patent laws.
Which is to say they have a monopoly...
Anti trust never makes having a monopoly illegal, it makes exploiting that monopoly to gain further monopolies illegal. It doesn't care about where the monopoly came from.
It does care about the kind of monopoly, current anti trust rules probably don't consider the monopoly Apple has from copyright and patents on hardware to be of the right category (to cover an entire market)... but that could easily change.
If apple were found to be in violation of Patent misuses the result would not be that apple is forced to open up the internals of how their products work but rather that patens apple has would be make null and void and others could copy them (based on the already public patent filling and nothing more).
Indeed, but if the doctrine started becoming more widely applied I imagine that they would start actively trying to avoid having it apply to them, e.g. by not using their hardware monopolies (patents) in ways that create software monopolies.
Sure, but by that definition every commercial product constructed from multiple parts has a monopoly over all their components. Starbucks has a “monopoly” over what coffee is sold within Starbucks cups. Sorry, but I just can’t take that kind of argument seriously.
> current anti trust rules probably don't consider the monopoly Apple has from copyright and patents on hardware to be of the right category (to cover an entire market)... but that could easily change.
Copyright and patents are the very definition of a legal monopoly. I don't think you're being serious.
> Sure, but by that definition every commercial product constructed from multiple parts has a monopoly over all their components. Starbucks has a “monopoly” over what coffee is sold within Starbucks cups. Sorry, but I just can’t take that kind of argument seriously.
You're right, my reply there was poorly worded, fortunately you seem to agree with the point of the reply anyways since you say
> Copyright and patents are the very definition of a legal monopoly.
Which really is just the point.
However I am being entirely serious that there is more that not all monopolies implicate current anti trust law. Whether or not they do depends on whether or not they're a monopoly over the entirety of a market, not over a certain invention (patent) or copying a certain work of art (copyright).
You can see that at play in the current Epic v Apple case for instance. It's unambiguous that Apple has a monopoly over distributing apps to iPhones, it is ambiguous over whether the relevant market here is iPhone users, and therefore whether or not anti trust law applies.
Until the early 90s probably you could get documentation for every device sold - schematics, calibration procedures, BOMs, technical drawings and so on. That ended when companies from countries with less strict IP laws started copying the products that sell. Governments didn't do much to protect businesses and such secrecy is now the effect of this.
Or to put it less insolently: I've learned my craft by reverse engineering; as a auto-didactic tool it's a primary learning tool, definitely beats reading the manual.
Why would Apple go through the effort of adding support for booting alternative OS's on M1 Macs and then stand in the way of implementing drivers for the hardware? That doesn't make a lot of sense, IMHO. Especially considering Apple could have gone the exact same path as iOS devices, which is a heavily locked-down platform that shares a lot in common.
A platform for amateur XNU kernel research was required, since the only other one besides the Mac is the Security Research iPhone (which is specifically not for amateurs). All of Apple’s documentation (of which there is little) and the boot loader design itself (what with the blessing process for a secondary drive being to install a tiny XNU partition with the bootloader app), point to the process being specifically designed for loading different versions of macOS. Any ability to install Linux (or Windows) is at this point coincidental.
Perhaps that's true. From what I read it shipped in a non-working state (manuals were there, but not some utilities were not), and I recall Apple engineers came out on Twitter saying it was being worked on and included it post-launch in macOS betas, even incorporating feedback. I believe Apple did tease at least Windows, maybe Linux in marketing, but I could be mistaken..
Either way, going after OS developers would be an extremely bad look for Apple, especially when they could just as easily disable the feature, or not have bothered finishing the implementation (or done it completely differently) after news of the Linux porting efforts started to spread (especially the Corellium public demo running Ubuntu).
What are _you_ talking about? Apple has never directly supported both directly through software support or otherwise, support for booting anything else but macOS on bare-metal M1.
Maybe your feeble brain couldn't read what I said. I said M1, not macOS as a whole. This discussion in about M1, think again. I can guarantee you will find nothing pointing in that direction for M1. Go ahead, look.
Maybe this an option that’s in place just in case Apple decides to license the chip/boards to one or more OEM’s.
OEM licensing makes sense for a SOC, plus the more the chip sells the lower the price per unit, so Apple would make money on the license, and lower their costs.
Anyone with enough money for expensive lawyers can sue you into oblivion. Sony being on the wrong end w/Bleem (and eventually losing) didn't stop them from running that company into the ground by outspending them.
You won't win a legal fight against Apple unless you have more money than they're willing to spend.
> You won't win a legal fight against Apple unless you have more money than they're willing to spend.
How does this process work, specifically? Does Apple secretly pay judges so that they favor them or what? Otherwise, wouldn't any judge dismiss Apple's claims as ridiculous?
The problem is the U.S. court system allows those with deep pockets to tie up the proceedings with endless delays over all kinds of arbitrary procedural matters. Those on the receiving end need to keep spending all this money to pay for their lawyers to handle all of the paperwork.
I don’t think it would be a problem in this case though. If Apple tried to do that to Alyssa I think she’d have the community jump to defend her. Perhaps even the EFF would take on her case. Apple would end up damaging their own brand with all the negative press that would generate. All of that on top of the stupidity of preventing people from doing what Apple themselves went out of their way to allow people to do.
> the U.S. court system allows those with deep pockets to tie up the proceedings with endless delays over all kinds of arbitrary procedural matters.
This is horrific, and obviously contrary to the concepts of justice and democracy. Why do people put up with this? Can't these behaviors be voted away?
Case law on IP matters like this is rarely clear enough to make any lawsuit ridiculous on the face of it. Look at the Google/Oracle suit that made it to the Supreme Court: these are complex issues.
Was that in capital bold letters on the product package ?
In the EU, EULAS that are either too long or too hard for normal people to read are not enforceable.
Also if you bought it, its yours and you can do whatever you want with it, like resell it (and Apple is being sued for not allowing users to resell AppStore apps..).
Also, the EU is going to ship a right to repair law that will force companies to make sure their products can be repaired after support ends. And that includes software. So any mac that apple sells will need to be fully usable / repairable / etc. just for the case that apple goes out of business.
That’s an impressive amount of progress already. Congrats on the work. I’m waiting apple’s next silicon to jump to arm, and hopefully by then I’m going to be able to run linux on it.
Pretty much all the things except the GPU are working in Corellium's quick'n'dirty "demo" Linux port. And you see how amazingly quickly the GPU driver is coming along… So not that long of a time after all (I'm surprised too).
Why would a datacenter want a (weird, tiny, embedded) M1 when they can get an 80-core, 8-channel, 128-lane Ampere Altra – which is actually designed to be standards compliant and even has an open source firmware option?
(Even a future "large" Apple SoC is unlikely to be datacenter large…)
try as I have, I can't imagine how Apple wouldn't sell more servers if they bought Ampere than the entire generic ARM server OEM industry can collectively. By generic, I mean to exclude custom silicon per AWS, Azure, et.al., but I'm tempted to think that the only reason why there's been nothing from Apple in the server category, simply because they're quietly waiting for a good candidate for acquisition to emerge. Ampere looks very interesting at the moment, but combine the Ampere chips with proven track record of optimisation and integration with the OS, and fast forward a few years to a time when we're more accommodating of vendor OS control in exchange for getting back some independence from the cloud hegemony players, oh, why not sprinkle over it all some fairy dust from a reincarnated Web Objects offering, and checkout process management provided by Apple, and I can just about see the next two decades of extraordinary growth that's presently challenged by the sheer scale of Apple's business, coming to fruition in ways that we'll be mostly very happy with for giving us all jobs back that are dying out in the white heat of today's oligopolist clouds now gathering and blocking the sun.
And the many times they have tried it either flopped outright or fizzled with little notice. The xServe and xRAID were very cool looking and actually quite functional, but never did integrate well into overall datacenter operations and ultimately that's what did them in. Unless Apple wanted to take it on to eliminate reliance on AWS, Azure and others I don't see them as having much incentive to care about the server space.
Indeed, if you ever see rumblings of them bringing more datacenter operations to be entirely in house then at some future point I could see them leveraging that to sell externally.
Unless they got really ambitious and planned on supplanting AWS entirely and thus their hardware gives them a significant edge.
But Apple has been so bad at software in general for so long, especially on the server side of things, I'm not holding my breath for that. They certainly have the resources to do it if they had the right person to drive it though, so never say never.
Ampere claims this future firmware will be "OSF certified", which doesn't mean much because "OSF does not require vendors to deliver firmware in open source form."
Servers/Datacenters aren't just about being able to run Linux though. How are they going to do firmware updates? Apple can break stuff as there is no contract there like there is with x86 server vendors who test all their updates to make sure Windows and Linux runs. Besides there's the whole issue of configuration/systems management, remote access and bulk chip availability.
I would love to see the shakeup with more efficient chips pressuring Intel to innovate in the datacenter space. Being able to decrease our hosting bill would reflect well on me, and it just seems like the way the space will eventually progress.
However, I run a hackintosh at home. I personally love it; I had access to top of the line hardware years before Apple offered it, with an OS that I understand and work well in, etc. It is absolutely not the way to go for any kind of must-work production. It is brittle. Apple is in the enviable position of being the only consumer of its APIs, and they barely publish documentation on the public stuff, much less internal-only provisions. Unless Apple explicitly supports (read: $$$$) a datacenter application, I can only see burning buildings (from all the hair on fire) where stable datacenters should be.
Yeah Intel and AMD both need competition from power efficient chips that perform equally well and offer the same level of support for Windows/Linux. And as you said, it's not going to be Apple - they have a consumer focus and culture and it's far fetched to imagine they will do all the stuff necessary for enterprise adoption of their ARM chips. In the cloud space Amazon has Graviton but there's not much hype about its performance and you run into compat issues a lot for normal cloud workloads at least in the Enterprise.
Nvidia has a real shot here with ARM purchase to fill the gaps but I doubt that's something they have as a focus.
My guess is that part of their perceived income flow implies that the MacOS is running on it. Music purchases, surveillance marketing, app purchases, dunno.
If they had the extra volume potential, it would be cool to see an extra cost M1 computer that boots and runs Linux with no fuss.
They offer the Mac as a Complete Product™, An Experience™ (with the OS) – basically since the original 80s Macintosh. Apple is a vertically integrated gadget business. They just aren't in the bare metal hardware business and have no reason to be there (probably doing that would only confuse the product customers).
Because of all this, when they decided to transition the Mac to custom chips, they just took the whole iDevice stack and did the absolute bare minimum changes to make it into a "technically a general purpose computer" stack. It runs basically iPhone firmware expanded to allow OS choice. They made zero effort to use any industry standards, because there was no business reason to put any effort into that, unfortunately. So we have this very unusual SoC (fucking custom interrupt controller! Even Broadcom stopped doing that crap!) running very unusual firmware (iBoot, everything is Mach-O and stuff, and the OS choice screen is actually a little macOS app). But hey it's not locked down because the Mac line is supposed to be general purpose computers, so go ahead and port Linux but you're on your own.
It's not the bare minimum, though. They designed an entire boot policy framework that allows you to multi-boot different OSes in different security contexts, so you can have your fully secure and DRM-enabled macOS next to your own Linux install (and even then their design maintains basic evil maid attack security, even for Linux or other custom kernels). That's more than pretty much any other general purpose platform.
Yeah, I know, and I agree that that is kinda cool. But in terms of everything else, especially in terms of standard vs custom stuff it is a very small change from iOS devices. If there was any business reason to adopt standards (say Boot Camp would've been deemed important) – they would've at least used UEFI.
UEFI by itself is not useful; we're going to support UEFI+DeviceTree in our boot chain, but it's not going to run Windows.
What you want is ACPI support if you want the platform to be compatible with higher-level ARM boot standards. Unfortunately, ACPI support assumes stuff like GIC and other hardware details. You probably want EL3 for PSCI too. But that would be a massive change to their silicon design.
So, effectively, there is no reason for them to support UEFI or any other firmware-level stuff if their chips are not compatible with Windows, which they aren't, and re-engineering their silicon to be something that could run Windows (without one-off patches from Microsoft, like they did for the Raspberry Pi which is in the same boat) would've obviously been a huge cost to them and not something they decided made business sense at this point.
Obviously Microsoft could choose to add support for these chips to Windows like we're doing with Linux, but that's on them; it requires core kernel changes that are not something you can do in drivers (last I checked Windows doesn't even support IRQ controller drivers as modules).
Well, going straight to seeing Linux output on the EFI framebuffer instead of having to develop things like m1n1 first would've been useful. Not very useful but still.
Yeah, not using the GIC is what I hate the most. If the SoC was less… custom, we could've even written our own ACPI tables (possibly useful ones depending on e.g. which particular Designware crap they used – the better DW PCIe controllers do support ECAM, etc.) and avoided having to redo all the work in every kernel anyone wanted to run…
but how long before these 160 cores of Ampere variety ARM servers will be entirely affordable prices for at least the average hner?
the most recent NetApp filer I was paid to evaluate for a fairly large business customer, is being sold at a price that I realised isn't actually so ridiculous for my home lab use. The amount of time expended on related work involved with using cloud computing for even very occasionally run jobs has put the likes of these Ampere servers very much inside the bounds of reasonable, even thoroughly sensible, reason for private acquisition. My first thought was "if only I was even ten years younger I'd advertise a house share and load a room with a couple of racks and dump all the interactions involved with setting up what I'm doing in the cloud for higher quality interaction with some housemates who have projects that could turn my practical investment into something much more interesting" I think a ratio of 128 cores per person feels about right?
College students are just as smart as graduates and they tend to have much more time on their hands.
So yeah, this is cool work, kudos and everything, but the fact that a college student is doing it is the least surprising part of it if you really think about it.
I really wished Apple would see, how much benefit this would bring to their platform. Their new hardware is really exciting, the first ARM on the desktop, which doesn't just compete, but in many aspects beat current x86 chips. A lot of the Linux and tech enthusiast crowd would love to jump onto Apple Silicon. And while they might not bring huge profits by themselves, these are the people who do come up with great new technologies. Better give them a home on Apple devices. It doesn't need a complete and formal documentation of every aspect, just supporting those projects with a little bit of information would go a long way. A single engineer who would answer questions by those developers might be sufficient. So come on, Apple, do it! :)