God bless anime.

If you don't believe me, look at @marcan42's YouTube output since Asahi Lina entered the room. It plummeted. Only a few non-GPU things once in a while. And you'll never catch them streaming simultaneously.

Furthermore, before April, @marcan42 was talking about doing literally everything Asahi Lina is now doing. From writing the GPU driver in Rust, among other things. Asahi Lina's desktop is even KDE with the exact same screen resolution and scaling settings, and even it appears similar usage of keyboard shortcuts, for Goodness' sake.

Also, it is not unfair to ask questions considering people are donating money for this. Anyone who is donating money to both, to discover they may be the same entity, should be rightly upset.

Exactly, that's the point of a AMA (Ask Me Anything). You can literally ask them anything and as I presume you or others have paid / donated money to them and need to know what they are paying for or towards and who is doing it, for transparency purposes. That isn't doxxing, that's transparency (Especially if you paid or donated for this.)

Now, for 'transparency', name please?

[0] https://twitter.com/marcan42

But while you can decide something is in "bad taste" within your clique, you don't get to decide that for the rest of us.

Doxxing is a serious accusation which is not supported here. The account you're replying to was speculating based on public information, there is no revealing private info here at all.

I genuinely don't understand why you think wearing Anime-face makes it beyond the pale to say "oh that's probably so-and-so, here's why", when it's just two Twitter accounts.

I see it as no different than speculating about the owner of a gimmick Twitter account, as distinct from, say, publishing their home address. That latter is doxxing, the former isn't.

Please don't do this here.

Edit: See the following.

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

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

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

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

Dang that video...

This is the future of our profession. We've gone from long-term, long-form documentation, to blog posts, to talks... in the next ten years it'll just be anime pfps squeaking at each other.

You can clearly hear the deeper voice behind high-pitched screeching.

I half-expected this. From what I observe, streamers who are both biologically and sexually female (it's a sign of the times that I have to clarify this, this much) tend to be OK with showing their real selves, but streamers who have some form of gender dysphoria (usually male-to-female) generally have virtual avatars.

This happened less than an hour ago. @dang is it OK to say now?

I see; interesting.

I’ve had many avatars online, some male, others female, many not human. While it can be for others, my decisions were never about my feelings towards my gender or sexuality.

I say this just to let you know these things are orthogonal. Just as you shouldn’t assume anything about a female child playing Peter Pan in the school production, you shouldn’t assume anything about a person’s gender or sexuality based on their “current” avatar (of possibly many current avatars).

You're right. It was a poor judgement call to associate virtual avatars with anyone's sexuality; thanks for pointing it out.

I was wondering if this would be more common as the technology developed but it seems like it hasn't and instead there are specific ideas about what vtubers are supposed to be that have become entrenched.

There are some people like Hikalium who are using vtuber avatars for live programming videos but not particularly doing a character though

I do think it would be weird to hide your voice, though.

(Anyway, the work itself is great!)

[1]: https://twitter.com/alyssarzg/status/1533624133929553922

It's a bit of a shame that the RAM is so limited on all those platforms - I can't imagine it being enough to load many electron apps in a few years time.

I honestly hopoe Electron has to improve it's performance or companies start moving off of it. It's honestly a bit of a joke at this point.

A native app, lets say that wants to play video and is using a cross platform GUI. You've got to load and run that code, and have all the relevant code in the native app's address space. That would be a bunch of code that needs to load over the PWA which is leveraging something you have loaded in RAM anyway. In this case the native is actually worse than the PWA for resource utilization.

Launch CPU cycles can be similar, running a huge swath of GUI code for the native app vs a pre-loaded browser which only needs to run the JS and render the page.

Having your app's runtime already loaded on the system is a huge advantage.

Electron does not benefit from these advantages though. These are PWA exclusive advantages.

Yes, because CORS, a way that HTTP requests are restricted, doesn’t even exist in native. Of course a native app can reach out to any URL it wants. That is the default, and also how CORS functions when disabled or bypassed.

I just don't see how 220MB for Discord is unreasonable in any way, when Firefox with 8 tabs takes 1.2GB. Telegram written in Qt meanwhile takes 200MB, literally no difference to Discord, an electron app.

[0] https://i.imgur.com/cfCRWDS.jpg

Even something completely simple such as snip a portion of your screen and paste it in the chatbox so others can see it immediately, without having to mess around with dodgy image upload sites. This is basic functionality for 2022.

It's like comparing notepad.exe to Microsoft Word

The point is most of what Discord provides is low value for the resources it demands.

> rich embedded media like images and videos

Yes

> live stream games to your friends on it

no (there's WeChat livestream (idk what it's called in English), but it's not discord style stream-your-desktop)

> talk with people

yes

> have profile avatars

yes

> use emotes

yes

> build bots that stream music to you

yes

> Even something completely simple such as snip a portion of your screen and paste it in the chatbox so others can see it immediately, without having to mess around with dodgy image upload sites

yes? you can paste stuff into wechat just fine. Think WhatsApp, not IRC

Idk where GP came up with 18MB tho, it's eating up 100 on my laptop right now.

Higher screen resolution uses more memory too.

I'm sure dependencies / libraries have grown in size too, and yeah, using web for UI takes memory.

Slack was using 1.2 GB. It is in a workspaces but that seems a lot for an app that does nothing.

Postman I think is also Electron often uses 1-2GB for sending API requests.

Atom though was only using 200MB which is fair.

I think it's a bit weird to compare a chat app with a web browser, though, when it comes to memory usage. Maybe a better example: hexchat, a native GTK IRC client, is currently using 60MB of RAM. Telegram's native app using over 200MB is also ridiculous.

Currently sitting at 29GB (on M1 Pro), just for regular web dev environment on MacOS.

Yes, but that's normally what people mean when they talk in broad strokes about "electron apps". Anything beyond that is application data, which is going to be roughly the same regardless of stack, and in nontrivial apps quickly comes to dominate.

> Currently sitting at 29GB (on M1 Pro), just for regular web dev environment on MacOS

I mean, I assume you're using more than just some regular electron apps. macOS itself is currently using 8GB of RAM on my machine, my docker VM is using 4GB (down from a default of 8GB), etc. And that doesn't include my IDE and its code-scanning and type-checking background processes.

Does that include file system cache?

Having a system with lots of RAM, the OS does it's best to use it. Just because you see 29GB used doesn't mean you'd see a noticeable performance dip on a 16GB machine. You might, but it really depends what that RAM is being used for.

For something extremely functional like a VS Code, which is a mini-IDE of sorts, that might be excusable but it's beyond silly for a streaming music player.

VS Code is an example of things gone right, where Microsoft has clearly hired an AAA-class team and funded them well. Within the same company, Teams is an example of the exact opposite and much more representative of the typical web app.

In Spotify's case, if they're aggressively caching album art, metadata, and/or audio I would say that's of questionable value to the user. Art and information on songs/albums/artists/etc are in nearly all cases only going to be seen once or twice by the user per session, and so keeping them sitting in memory doesn't make a whole lot of sense. Caching audio that's not been played is very questionable (to the point that I don't think they're doing this) because many, many people are still on metered connections and Spotify would quickly be blowing past bandwidth limits if it were pre-caching albums left and right.

Disk caching makes a ton of sense for Spotify, given that it's being done in a standarized directory that the OS can clear to free up space when necessary, but on machines with 8GB or especially 4GB of RAM there's a very good chance that by aggressively caching to memory they're evacuating other things that would better serve the user to be sitting in memory.

Using a lot of memory is fine when there's clear user benefit but it should still be done intelligently.

Correlation is not causation

We can debate the specific design choices that Spotify or any other company has made, but my original point was to push back against the tired trope that using web technologies for an app automatically means runaway resource consumption and (apparently) the downfall of civilization

Look, the plural of anecdotes is not data, but you can't argue against the general trend of "applications using web frameworks like Electron tend to consume more RAM" by saying "well in this specific case they made poor design decisions that would bite anyone in the ass"; while that may be true it misses the point, which is the much larger (and well-correlated) & overarching tendency of such apps to absolutely chew RAM.

That it's a "tired trope" doesn't make it untrue; it just means that enough people have accepted what is functionally the new state of the software application world that it's considered passé to call such things out.

There are no dependencies.

Not to say that it should not have more, far from it. But the Electron framework is so wasteful, compared with basically all the alternatives.

I wish the framework developed for Sublime Text were not secret.

Que pedo, wey.

As long as you didn't get one of the single-channel SSD models, it would make plenty of sense to give yourself a 16 gig swapfile (or something of the sort).

It's actually a problem, if you're low on SSD space the filesystem can fill up with swapfiles while the system is still reasonably functional because the SSDs are fast enough. Then because of an APFS design fault, sometimes it isn't possible to delete any files to free up space. It says "out of disk space" when you try to delete a file.

https://csis.pace.edu/~marchese/CS865/Papers/candea_microreb...

https://erlang.org/download/armstrong_thesis_2003.pdf

To put it simply, NVIDIA screwed third-party drivers by requiring a ever-changing encrypted and signed blob, hidden deep within the proprietary driver package, to be sent to the GPU every time it boots. Otherwise, you can't change the clock speed of your NVIDIA GPU from the boot clock speed, which is almost unusably slow.

The message from that is screw NVIDIA - not that third party GPUs necessarily are that horrible to implement.

But almost no users to justify the huge development effort. Many laptops from that era, for example, are completely unusable by now - only high end models had 16GB of RAM, most were limited to 4 or 8GB - and desktop builds of that age simply consume far too much electricity for the performance they offer.

In contrast, investing work into current NVIDIA/AMD drivers or the Apple Mx architecture makes more sense - the crypto boom and bust led to a lot of cheap but current cards which means many will simply stick it out with a used RTX 3090 for a couple years once NVIDIA releases their new generation, and Apple usually keeps their own hardware stacks very similar in design which means work done now will still be a foundation for Apple's chipsets five or ten years in the future.

https://nouveau.freedesktop.org/CodeNames.html https://nouveau.freedesktop.org/FeatureMatrix.html

https://blogs.gnome.org/uraeus/2022/05/11/why-is-the-open-so... https://lwn.net/Articles/894861/

new hardware, arm based apple silicon here, is now challenging the monopoly of x86. after such a long waiting, we finally have a mature alternative platform to choose from - and it is performance is pretty good.

new language, rust here, is getting its way into the linux kernel. this new GPU driver is written in Rust!

the work is based on the GPU hardware analysis of Alyssa Rosenzweig, who is a very talented young lady who started when she was in high school I think. the author of the driver, Asahi Lina, also seem to be very young.

Just amazing!

This happened about an hour ago. Again, @dang, is it OK to say now? I'm not crazy here.

If you have the desire to do so, spread the word about the actually bad things he is doing (I'm sure we're thinking about the same things). People might actually care about that, some day.

https://news.ycombinator.com/item?id=32728315 https://news.ycombinator.com/item?id=32727645

marcan is a common target of harassment from KF users who insist that he's helping a late friend of his fake their death. He has regularly spoken against that community of abusers.

FUD like you're seeing here is part of their modus operandi and it's fairly obvious when you know what to expect.

> The unauthorised reproduction, translation, adaptation or transformation of the form of the code in which a copy of a computer program has been made available constitutes an infringement of the exclusive rights of the author. Nevertheless, circumstances may exist when such a reproduction of the code and translation of its form are indispensable to obtain the necessary information to achieve the interoperability of an independently created program with other programs. It has therefore to be considered that, in these limited circumstances only, performance of the acts of reproduction and translation by or on behalf of a person having a right to use a copy of the program is legitimate and compatible with fair practice and must therefore be deemed not to require the authorisation of the rightholder. An objective of this exception is to make it possible to connect all components of a computer system, including those of different manufacturers, so that they can work together. Such an exception to the author's exclusive rights may not be used in a way which prejudices the legitimate interests of the rightholder or which conflicts with a normal exploitation of the program.

Directive 2009/24/EC

This would allow you to disassemble and modify any parts of OSX and its drivers in order to help write a Linux driver. Does the same apply in the US?

There were a number of court cases, many involving game consoles (incl. Sega v. Accolade, Galoob v. Nintendo, Sony v. Connectix) that establish that as long as you're not distributing verbatim or other infringing copies of another company's work such as software or chip designs (and you haven't signed any contractual agreements otherwise), you're in the clear. To establish that you are in the clear, clean-room reverse engineering is the recommended approach: one party does the reverse engineering yielding a spec; the other implements the software based on the spec.

good to know that. asahi linux should be fine, the reverse engineering and driver development are done by different people.

https://nitter.tiekoetter.com/marcan42/status/15271299617061...

When it comes to going outside that box though by plainly denying identity instead of de-emphasizing/sidestepping the identity I can't shake the uneasiness around "gaslighting for a good cause" not being right. Especially because this gets amplified by every other 3rd party who may just be taking identity claims at face value (which may or may not be what's happened here?).

It's not really important everyone know Lina's identity, especially if they don't want people to know it. At the same time it's not really important to try to convince people that they don't actually know something. Show them the understanding about the matter sure sure, and if they still try to publicize it don't let them doxx someone sure, but I don't think it's good to go further than that with it.

To that end I've tried to write this in a way that it has no relation to any person/identity in particular - just the topic at hand.

Meanwhile for example in Poland (EU member), it's illegal to forbid reverse engineering - any claim in a contract, license or not, that forbids such is null & void. Because the copyright law has a paragraph about how "reverse engineering is a right of everyone." - the only thing is that you can't just recompile reversed code and claim it's yours (that would be copyright violation).

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

> thanks to the tremendous shared code in Mesa, a basic OpenGL driver is doable by a single person. I’m optimistic that we’ll have native OpenGL 2.1 in Asahi Linux by the end of the year.

It's likely that even a bare-bones OpenGL driver will probably run better than llvmpipe, which is especially important in a laptop context due to the resulting power use improvements.

I do this on my workstation and can run anything, it's quite nice:

  $ lscpu | grep Architecture
  Architecture:                    x86_64
  $ GOARCH=arm64 go build main.go
  $ file ./main
  ./main: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, ...
  $ ./main
  Hello, world.

It's an honest question. Even if someone (or a team) could somehow be paid for this work, by the time the results are usable, the hardware will be more or less functionally obsolete.

And that is on top of the fact that ARM64 on MacOS will always be a small slice of the gaming pie, and ARM64 on Linux games and GPU applications virtually nonexistent.

What do I miss?

So eventually the gap between hardware release and fairly complete driver support could close quite a lot.

Also, the Apple GPU has evolved from PowerVR roots dating back to the 1990s. It is fairly safe to assume that the next generation of Apple GPU will share enough with the current generation that in 3 years, supporting whatever new hardware exists will be incremental rather than transformative ground-up work.

This was already the case for M1 into M2.

Hundreds of GPU features the latter doesn't use in normal hw-accelerated rendering of webpages... except maybe in doing WebGL content (and even less much fewer and older features than what AAA games want)

Yes. Compute shaders and geometry shaders are big features. Vulkan, DX12 and Metal also brought a jump in performance at the API level by allowing developers to batch commands sent to the GPU.

Desktop environments can and do leverage those newer APIs to get marginally better battery life. Asahi will miss out on those benefits, but the performance will be insanely better than “no GPU at all”.

Additionally there's a lot of shared code between the different linux graphics drivers through Mesa, the linux userspace graphics driver framework.

https://youtu.be/Of93GBCEbug Shows some native games, but also Skyrim and Metro Last Light working on ARM.

but considering there is a mountain of linux development for people with the expertise to be done for more open platforms. This work pretty much only helps one of the richest companies and Apple shows very little inclination to help by providing documentation or support (they let an alternative OS boot seems to be the extent of it).

The XPS series might have caught up for a while, but until they flip over to ARM, Apple laptops simply blow anything else out of the water. What’s wrong with trying to run Linux on that?

Could Apple improve the documentation a lot? For sure! Bu on the other side, the ARM Macs are a very nice platform, so I can understand the desire to use it. There is no competition at the moment, so it would be wrong too, to not support Linux there.

It’s perfectly possible to build such chips with other designs and instruction sets, for example x86_64 or risc-v, in the same way it’s pretty common to build cheaper slower ARM processors. Plenty of folks at Intel and AMD are doing that right now.

Not in any way that has any relevance.

>Not as big of a problem as on x86, but still a fundamental limitation.

Huge understatement. Instructions being any size 1-16 (x86) vs being either 16bit or 32bit long (RISC-V).

As with everything else in RISC-V, the architects did the weighting, and found that the advantage in code size overwhelms the (negligible by design) added decoding cost, for anything but the tiniest of implementations (no on-die cache + no builtin ROM).

As it turns out, it would be difficult to even find a use for such a core, but in any event it is still possible to make one such very specialized chip, and simply not use the C extension.

Such a use would be deeply embedded, and the vendor would be designing the full stack so there would be no concerns of compatibility with existing binary-only software. They would still get ecosystem benefits; they'd be able to use the open source toolchains, as they support even naked RV32E with no extensions.

This does apply to x86 and m68k, as "variable" there means 1-16 byte, and dealing with that means bruteforcing decode at every possible starting point. Intel and AMD have both thus found 4-wide decode to be a practical limit.

It does not apply to RISC-V, where you get either 32bit or 2x 16bit. The added complexity of using the C extension is negligible, to the point where if a chip has any cache or rom in it, using C becomes a net benefit in area and power.

Therefore, ARMv8 AArch64 made a critical mistake in adopting a fixed 32bit opcode size. A mistake we can see in practice when looking at the L1 cache size that Apple M1 needed to compensate for poor code density.

L1 is never free. It is always *very* costly: Its size dictates area the cache takes, clocks the cache itself can achieve (which in turns caps the speed of the CPU), and power the cache draws.

Sure, there's Ascalon[0], 8-decode 10-issue, by Jim Keller's team at Tenstorrent. It isn't in the market yet, but is bound to be among the first RISC-V chips targeting very high performance.

Note that, at that size (8-decode implies lots of execution units, a relatively large design), the negligible overhead of C extension is invisible.

C extension decode overhead would only apply in the comically impractical scenario of a core that has neither L1 nor any ROM in the chip. Otherwise, it is a new win.

And such a specialized chip would simply not implement C.

0. https://youtu.be/yHrdEcsr9V0?t=346

Also it will be useable for at least some usecases, even if not AAA games, before the hardware is obselete.

> a basic OpenGL driver is doable by a single person. I’m optimistic that we’ll have native OpenGL 2.1 in Asahi Linux by the end of the year.

That should be enough to be very useful to a lot of users.

People do great stuff with computers and programming and I think this is a good example. Passion is what it's all about.

The "why bother" is missing the crucial point, that the most important use of the GPU driver for Asahi would be HW accelerated desktop (and driving external monitors, etc) - it's not like a GPU driver for M1 is useless if no AAA games aren't supported...

Because people want to. Who is anyone to be the arbiter of those desires, no matter the practical applications (which this has a ton of, as alluded to via the other repliers)?

1 - https://eater.net/6502

But you are right -- modern desktops are using a GPU heavily. For worse or best(10-15 years ago everything worked without GPU help and compositors. Was not as fancy looking).

P.S. I like how HN works on mobile. And how lightweight it is. Made by real hacker wizards, of long lost arcane knowledge of the webcraft!

Because most of us looking into Asahi don't care for playing AAA games with it. We want Linux on our Mac laptop, with hw acceleration for the desktop and apps.

You just have to lower the settings and resolution to get that smooth performance - think base model last gen console/nintendo switch levels of visual fidelity rather than up to date gaming pc/current gen console levels of visual fidelity.

It's kinda fun squeezing performance out of woefully underpowered hardware - LowSpecGamer on youtube is a channel dedicated to this kind of stuff.

I think the parent's point is "what AAA games would run on the M1, even if they finish GPU support, given that we're talking about ARM Linux?"

[0] https://box86.org/2022/03/box86-box64-vs-qemu-vs-fex-vs-rose...

Again, why bother?

Why continue to choose user hostile hardware made by a manufacture who seeks to frustrate your precise desire to do this? Wouldn't it be much more logical to purchase from a manufacturer who doesn't care what you use on the hardware--or even better yet, actively supports you in getting the hardware to perform as well as possible with Linux? What is the point in continuing to chase after hardware which doesn't fully work in your chosen operating system with your preferred applications? Why pay full price for hardware that will never be fully supported and work to its full potential?

I had a Macbook Pro 8,1 I ordered specifically for the intel video because at the time Nvidia support was lacking and I got that model with the express purpose and idea that if OSX changed to where I no longer liked it or if the hardware was no longer supported by Apple I could just install Linux and keep going. I had nothing but nightmares trying to get Linux to work on that thing. Consistently things would be fine and then suddenly grub would randomly eat itself. The idea of buying hardware and installing an unsupported operating system seems like insanity to me after that experience.

I'm genuinely trying to understand why people would do this because it seems to make no sense. I doubt any of the people hitting the downvote will see this post in response but I'd really like to hear why anyone would do this. This is supposed to be a commenting and discussion board, I'd like some discussion. Thanks.

Reasons to do it: 1. Enthusiasts are having fun 2. They increase their skill in Linux driver development 3. This can generate patches usable by ARM linux in general, not only viable for Apple hardware.

If she manages to succeed, perhaps with help of others, then we have Linux desktop there. Linux gaming and 3D acceleration wasn't always a thing, and people were still using Linux.

But I agree that apple hardware would still be hostile, and not sure if it is worth it. VM can be used with same success. People who by new macs should be ready to be vendor locked.

But to extend this topic.

Many parts of x86 linux drivers are community developed. Either by individuals, or by companies as RedHat. Yes major hardware vendors, like Intel and AMD makes sure that chipset and CPU are supported, but many motherboard vendors and laptop ones don't give a damn. As far as I know Realtek gigabit ethernet chip was community driven driver.

And most printer drivers are not from vendors.

Now I am curious to search statistics, how much of drivers are made by vendors?

But generally, there is still a problem, that person decide to try linux, and their hardware is unsupported on x86. Laptops especially.

I tend to check linux compatibility first, even if I don't use Linux regularly(actually going to switch soon). I've used linux for a while on my DELL laptop, and experience was great. But my daily driver is windows desktop. Going to try it out. Hope my Wacom tablet would work in Linux, as from my research Wacom is best shot for L.

But people is doing it for free, and getting fun. So that's their choice.

You helped me see what was happening too, so thank you for that too.

I'm not for a second saying that if people want to hack away on the hardware to have fun, to scratch their own itch, etc etc they shouldn't be allowed to do so. They want to do it, they should have as much fun as they can while doing so. I wish them well. No on is served by petty administrator types demanding the whole world act as an offshoot of their corporate needs and abandon what is fun for them to work on the stuff that any one individual needs. Linux grows like it does because so many people are having fun with it and I'd never want to stop that.

The people I don't understand are the ones who buy Apple hardware with the intention of running Linux. They're the ones taking the gamble and buying something which was never intended to work under Linux from a vendor who is actively hostile to them doing so. At these prices, why gamble? Why fight? Do you want a toy for geek cred or are you buying hardware to use?

It's different if they're planning to develop on the hardware alongside the hackers getting Linux to run or are trying to target their code on the ARM type that Apple is using with hopes of future portability. That makes sense and is their business, whether for work or for pleasure. I just don't understand why the average Linux user would want to do this.

Sure Apple's ARM processor is pretty much leading the pack when it comes to ARM hardware set up for daily use. The hardware is very cool and I dearly hope that someone will release something intended for Linux that can compete and give them a run for their money. I just don't think it's a gamble worth pursuing if your goal is to simply use the hardware as opposed to developing or hacking on it.

Thanks again for your response, it helped me understand how I was coming off and I apologize to everyone for the misunderstanding my wording caused.

I guess having another option won't hurt, and would increase applications adoption.

To be honest: supporting such uniform hardware as Apple's is way easier than supporting bunch of different vendors. So this is doable, if won't be one-man project.

But if you're a Linux user, that's the normal state of things. There are options like System76, but they often carry a price premium (which may well be a worthwhile investment), and the Linux ecosystem would be a lot weaker if that was the only non-server hardware you could buy.

I wonder the same thing, but from an ideological perspective.

Why should the free software community promote Apple hardware by making it more accessible to OSS enthusiasts, when Apple only cares about OSS when it directly benefits them? Apple makes great hardware, but they're actively hostile to everything free software stands for. If Apple cared about this user base, they would work on this themselves.

That said, from a technical standpoint, this is nothing short of impressive, so kudos to the team. I can't even imagine the dedication and patience required to work on this project.

Why should you be forced to choose between non-free software and subpar hardware?

Why not liberate the hardware?

I think there are plenty of "good enough" laptops that run Linux just fine, so I'd rather use those than have the relatively "best" hardware, but have to fight it to run the software I want, deal with any incompatibilities, and fear that it might break at any point. Standard Linux on supported hardware has plenty of issues; I can't imagine what the experience is like on completely opaque hardware, as much progress as the Asahi team has made. It's like a reverse Hackintosh project, which has always been a painful experience.

Isn't there anyone inside Apple who wants to have Linux?

Isn't there anyone inside Apple who wants to help?

At this point, trying to expand the user base through sheer hardware improvement or trying to include fringe groups (windows dual boot users, linux user) probably has diminishing returns.

In contrast, service revenue, app revenue and accessories like air pods, the Apple Watch have a much better ROI.

What I'm coming at: they have little incentive to work hard to expand the user base, and a better ROI on expanding revenue from users of their software platform. So I'm not holding my breath on Apple actively helping for windows or linux support anytime soon.

https://twitter.com/marcan42/status/1554395184473190400

They also may be reluctant to release it because of fear of litigation. They may do something that’s patented, similar to a patent, or deemed patented by someone else, and releasing documentation makes it easier for others to find such cases.

Also, in the end, there’s dollars. Even the simplest process to release documentation costs money (and theirs wouldn’t be the simplest for the reasons mentioned above). They may think there’s not enough money or reputation gain in it for them to do this (and for reputation gain, they would have to keep doing it)

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

- https://rosenzweig.io/blog/asahi-gpu-part-4.html, https://rosenzweig.io/blog/asahi-gpu-part-5.html, https://rosenzweig.io/blog/asahi-gpu-part-6.html

And going through the twitter link you can find the homepage for that software is at https://inochi2d.com/ (the other twitter link gets you the homepage for the developer of that software at https://github.com/LunaTheFoxgirl).