> Ugly state is exactly what Rust was made for. It forces you to tame the ugly state instead of hacking at it and hoping it works.
I'm not an expert on GUIs, but my understanding of them is that the ugly state is sort of inherent to GUI applications and you can't tame it. Ie, everything interconnects with everything else and there's not much you can do about that. This sort of inherently pushes you to a big runtime that manages a lot of stuff for you, which is in line with GUIs being rather expensive generally (ultimately you have to render everything to the screen).
Maybe I can understand better with an actual example? I might just be biased by React's mindset, but I've always considered two-way binding (and any non-unidirectional data flow) a mistake, and it has only brought me pain and sorrow.
In other words: the patterns I use outside of Rust are also Rust's happy paths (on paper, maybe I'm just missing something?)
(For clarity: I'm talking of userland here. I assume that's what OP meant by "UX" -- I agree with your "big runtime" point, but that's why my RAM is filled by Electron apps.)
I saw that's there is an Omarchy for Mac "team" consisting mostly of one guy who is active on Twitter (and quickly amassed many followers) and seems to have no prior experience of working on Linux kernel. They do not mention Asahi anywhere which isn't surprising to me given the reputation of DHH and Omarchy. This hijacking of open source by bad faith actors is very concerning.
> Omarchy on...
> Apple M1/M2 chips#
> Asahi Alarm is a version of Arch for Apple M1/M2 computers built on top of Asahi Linux. You can get Omarchy running on top of that with some effort. See the user-driven guide.
Spoiler: We have Vulkan 1.4 working, all of M4 and most of M5 working, are making significant progress towards full suspend to ram (no version of Asahi supports this) and this will all be shipped to users very soon!
Gravity Linux and Asahi Linux are two independent projects working towards the shared goal of a strong, open OS ecosystem on Apple Silicon devices. Gravity Linux was initially forked from Asahi Linux over differences in policy, namely regarding LLM use. We have tremendous respect for the Asahi Linux project and emphasize our shared goal of running Linux on Apple Silicon.
Hasn't been shipped yet, integration is being done now, we're shipping a new installer, from scratch graphics driver, and new kernel so there's a lot of moving parts we want to get right.
You want longterm support, not a set of pit of tree patches for 7.3 kernel that will stop working or misbehave in 7.4 or 7.10, with no one understanding why.
Besides not wanting hallucinations on my OS level code?
Or not feeling good for the intellectual theft involved in the training of AI to begin with?
Or not caring for the de-skilling of of human brains who are delegating coding to AI, and increasingly even the architectural and decision part?
Or the training material being AI degradation that awaits most code being written by AI?
Or the baragge of slop PRs that overwhelms my favorite FOSS projects?
Or deeping of big AI dependency, in times of climate and economic crisis that it worsens, but that it also risks not having the luxury of it forever?
Or the ease with which any stupid direction can be followed via AI, and the resulting always changing projects, already a problem with short attention span project leads even for big projects like Gnome?
Or the lack of deeper understanding to control all this in future generations of programmers reduced to "AI operators"?
>Are you saying "vibe-coded slop" because of the quality of the end result? Who cares if it gives you the features with good-enough performance?
There are a few significant reasons worth considering when getting down to the level of OS and hardware drivers. Long term maintainability is one. But another big one is that such software is capable of physically and permanently destroying the hardware it's operating on, with the textbook example for Macs being the speakers found in Macbooks. The only way to get the kind of performance they offer out of that physically light/thin package is to give them the power to destroy themselves if run at full force continuously but then run it from software so that they aren't run at full force continuously, but rather take advantage of the headroom that offers for very brief audio spikes whose overall integrated power still falls below safe limits. This all needs to be done from software since response of real world analog isn't instant. That enables much more range then if they were hardware capped at the maximum level they could run constantly, but it also means that if they're driven wrong, poof. The drivers have to never go to certain bad states, purely from software.
LLMs can't offer those kinds of guarantees, they don't really "know" how things work and then produce something deterministic off of that. It's even worse if, as-is the case with this sort of vibecoding effort, the LLM operator is in fact depending on the LLM for that part because they don't know how it really works either (vs someone who is just using it for boiler plate and knows exactly where the critical paths are).
Obviously everyone is welcome to roll the dice with their own hardware as they wish, and it may be ok. Or if using really old hardware one might just not care. And not all hardware is as sensitive as modern notebooks of course. Just be aware the analog world can be messy and you might not actually have the guardrails to screw up that you're used to in a higher level software environment.
>Otherwise one can also say Asahi is compiler-generated slop compared to hand written assembler code.
No, one cannot say that. Or at least not without looking really stupid.
If that issue with the speakers is documented, the LLMs of today would handle it correctly. That wasn’t true very recently. Also, assuming documentation exists is a big crutch that helps them more than us.
I prefer reliable software for the Operating System. Like, I can tolerate slop for a game or a one-time-thing of converting a doc or something. But for running the base software (your OS), I think you need better standards.
Just remember that for however bad our code is (and I have no issues saying that most of our linux driver code is absolutely horrific, for now) it's better than Asahi code, because our code exists, and their code doesn't.
Wow man, "horrific code" can be worse than no code. Bad code can damage hardware, destroy data, allow exploits, etc. all manner of bad things.
Unless your meaning is that you already have work-in-progress code that you are working on to make much better whereas they have not even started, I don't see how your point makes sense.
But even then it debatable whether making bad code good is better than creating good code from the start.
Yes, being able to buy a hacked-together microwave that can explode in your face and one that is tested and certified is amazing! Especially if you’re clueless about how they’re made and you just want a microwave.
Mainline Linux doesn't run on the M4. So in your metaphor, it's more like being able to choose between a microwave of uncertain quality and not having a microwave.
Even good code is a liability. Admittedly "horrific" code is a 10x or 50x liability. Sometimes you accept that kind of technical debt because "it's really important" — e.g. the company will go bankrupt, or whatever.
(Historically, btw, this is why proprietary corporate code is often so much worse than even fairly incompetent open-source code. Because it's just not really that important to ship horrific slop when nobody's income depends on it.)
The idea that shipping "horrific" code now is somehow better than not shipping it until it is fit for human consumption works in some narrow business life-cycle scenarios, but not in any kind of user-facing scenario, and certainly absolutely fucking not any kind of user-facing OS implementation scenario... (T_T)
"Code is a liability" - is one of the fundamental tenets of programming.
So, "it's better because our code exists, and their code doesn't" isn't the brag you think it is. Yes, a quick thrown together utility is better than having to manually do something. But that's not the same for an OS, or god forbid, a filesystem.
Especially since the only reason your code exists in the first place is that they did the hard work and your project forked.
Unironically yes. I think it's great that you don't have to be as extraordinarily skilled as the Asahi developers in order to get Linux running on new hardware.
> however bad our code is (and I have no issues saying that most of our linux driver code is absolutely horrific
It's the operating system, mate. People don't just use operating systems to take screenshots and then post on social media.
> it's better than Asahi code, because our code exists, and their code doesn't
This is an especially horrific comment if you are really related to the project and this also adds to the perspective on why Asahi team might have wanted to have no nothing to do with this project and related people and their thought process. Anyway, good luck.
If I could run linux on apple hardware without compromise, my life would meaningfully be improved.
It's not well understood how important it is that humans feel in control of their environment. I feel like it's a fundamental to human happiness. Software that takes that away contributes to the general malaise and hopelessness that many are feeling today. It's just water to them at this point. They don't even see it. But it's the primary means of interaction.
Making that a true option to millions of people could do a lot of good for the world.
I wholeheartedly agree. If I think about it, I must have thought "god I wish this ran Linux" at least once every single time I opened my MacBook - likely for the last several years.
I have run Asahi and while I love the project, it's not ready for that type of use.
Recently, I got a new MacBook and repurposed my old M1 MacBook Pro for local inference. The unbelievable number of compromises and hacks you need to do to run daemonized always-on software on MacOS was another reminder.
I know it goes completely against Apple's business model, but I'd love to be an Apple customer if I could buy their hardware and use it with software of my own choice. Holding an iPhone or a MacBook feels great, they're all easily among the best consumer electronics ever as far as the physical part goes. But Apple's software is completely different from how I want to use my devices so I just don't end up considering them when buying.
Would love for Asahi or similar projects to be fully usable but it also doesn't seem very likely. Apple is arguably not hostile to other OSes on MacBooks, they're designed to freely boot non-Apple operating systems, but by not publishing any hardware manuals Apple ensures that an Asahi-style project is always going to be well behind, likely years behind, in hardware support.
Oh, they’re definitely hostile, by the way, Darwin is still open source, but no one’s bothered in 26 years market inertia? Just like no one’s bothered to take a license out with SoftBank to design something from the ground up (like those three ex Apple engineers) using Linux, the easiest and fastest way to get something working from the ground up.
Wouldn’t the time be better spent taking a license out? With SoftBank to design? Arm chips that work from the ground up running Linux instead of this time-wasting exercise? Apple is one year away from M7 two years away from M8 processors Asahi are just chasing smoke…
> I feel like it's a fundamental to human happiness. Software that takes that away contributes to the general malaise and hopelessness that many are feeling today.
I would like to see a full-featured Linux on Apple hardware too, but I think over 99% of people don't feel anywhere near this strongly. Do you feel this strongly about being able to replace the engine in your car with one you made yourself? I don't, and I think most people view computers the same way.
> Do you feel this strongly about being able to replace the engine in your car with one you made yourself?
I am not one of those people, as I do not do cars, but I would hazard a guess that most car people over a certain age do in fact feel very strongly about what modern cars have become. The ones who grew up without knowing what ownership feels like less so, which reflects the exact same dynamic with younger generations who are growing up without ever knowing what it feels like to own the hardware they use.
I think it would be disingenuous not to point out that this was also true of new cars 20 years ago - which is much more pertinent to the point of the people you're replying to.
Considering how easy it was to replace engines of most cars before the integration of electronics I'd say it used to be quite common. Just as most hardware vendors used to ship full specs for their components up until the 80s or even 90s.
So, yeah, yes, definitely. I wouldn't be working with computers on a daily basis if I had to use Windows.
I'm not gonna overly generalize this though. I don't think it'll be the same for most people but I tend to not care about what most people do 99% of the time anyways.
If it was as cheap and easy to install a new engine as it is for an OS, I imagine swapping engines would be even more popular than new OSs. (And I think far fewer would clamor to replace their OS if it cost $x,xxx for each OS swap and took many hours of manual labor - I.e. I think whether someone wants something can be heavily influenced by whether it is ~free vs cost $x,xxx, etc.)
Cool, I'm glad someone is taking a more aggressive and LLM friendly approach to doing Linux on Mac. Too bad there's no M3 since that's what I have :P
Not sure if it would be useful for you, but I did get an M3 GPU driver kinda working (it boots KDE, runs Quake and GLXGears, etc) but isn't quite usable yet. But feel free to yank the code if it's helpful: https://github.com/SuperDisk/asahi-plus-slop
> Cool, I'm glad someone is taking a more aggressive and LLM friendly approach to doing Linux on Mac
Same. I've been waiting 6 years to run no-compromises Linux on my MacBook. At this point, I don't care if someone uses LLM decompiled firmware ported to Linux.
Omarchy has no chance upstreaming any of their work, the code is abysmal.
Asahi at least guarantees the quality of their stuff because they upstream everything, sooner or later. Gravity apparently also intends to be upstream-first.
Omarchy is not something I'm comfortable trusting long term, and comes with a lot of cruft.
I'd be very interested in seeing the parent post's project get M3/M3 Pro support; have it working in my system with a patchset on top of Asahi but suspend is leaving a lot to be desired. Unlike Omarchy, the parent post's diff would also be much more reviewable due to it's more limited scope.
I just did a search for gravity linux from the search at the bottom of the HN page. HN is a fickle place as it seems you get more traction by hijacking Asahi posts that when you make your own posts.
Any plans for supporting M3 Ultra? I understand it's a small percentage of the Apple Silicon Macs out there, but I'd love running Linux on my Mac Studio?
I disagree with this also, but the latter was so obviously wrong that I figured I should leave a reply. We are separate projects and what Asahi does is their business, our interactions will be in upstream projects and follow upstream guidelines.
It's kinda sad that this cool project is mired in controversy. On one hand it is kinda radioactive for a former Apple engineer to work on this, even if you worked on something else entirely while at Apple. On the other hand I really, really want proper Linux support with full GPU support on modern Macs and I feel like AI is an incredibly useful tool towards that effort.
Oh well, if this doesn't pan out, hopefully someone else will vibe code for a week and get it working in the near future.
Let’s take the kind view? If Apple has a problem in a former engineer possibly using insider knowledge that is first and foremost a problem between Apple and said engineer. Reasonably if that first round kicks off, in the second round of problems an OSS project is possible in scope.
The engineer and the project have discussed these risks and decided to continue in a fork from Asahi. So I would say that this is (nearly) how it is supposed to go. Asahi stays clean from contagion and Gravity Linux has taken a, hopefully well considered, risk.
Claude Design, the only Anthropic product I genuinely like. I spent a LOT of time on those, so I'm glad you enjoyed them! I'm about the least artistic person you ever met in your life (everything in my life is very functional and very unaesthetic) so I'm a rather big AI design tool enjoyer.
Right now I'm focusing specifically on the M4 Mac Mini and Neo, I just don't own any M4 Pro or Max hardware. My guess is that most of the drivers will just work on the other platforms, but we'll have to test.
> concealing that he is a former Apple engineer with direct contacts to the people involved in Apple Silicon development
This is false. I am a former Apple engineer. I did not conceal it (it's the top item of my resume and my LinkedIn and I made my PR from my public Github with my name attached, as opposed to a pseudonym which is expressly allowed by Asahi policy). I also had no exposure, at all, to any internal information or code about macOS, SPTM, or Apple Silicon during my time there.
I also don't have connections to people involved in Apple Silicon development (and I'd add that this does not mean someone cannot contribute, the question is were they exposed to tainted information, which is absolutely not true in my case). I have many friends who work for Apple (I'm a Stanford alum) but none in Apple Silicon directly.
I disagree with the phrasing of this entire thing, but this statement is demonstrably false.
Would you consider taking all of your learnings and translate them into a concrete specification and publish it on your website, so that we can all do our own clean-room from-spec-only implementation?
The friend I am referring to I met at Stanford around April of 2026 in a dorm event. We've spoken in person exactly once (I use "friend" loosely to describe anyone I've spoken to who I'm not on bad terms with) and at no point did we discuss anything detailed about Apple Silicon. For further context, I left Apple in June of 2025.
Spend enough time in tech and you'll know lots of people who know both technical and business secrets and are under various levels of NDAs. The message you link to explicitly mentions only public info was exchanged. Just talking to someone is not an indication of infringement in any way.
I think this comment is missing the forest for the trees. Obviously, ephemeral interaction is going to happen.
The author’s blogpost is sloppy and has some signs of being AI written. This kind of bleeds into the main point I’m going to make.
Asahi Linux folks are clearly more conservative and erring on the side of caution, so, this means that the glibness with which the author is treating any of this is probably sufficient cause to refuse his entries. It is unclear if LLMs should be considered a toxic waste dump in terms of trying to maintain a clean room. We have not established a standard. It is clear the author doesn’t think this is a big deal, so that’s one conflict. The other conflict is that it is not clear what their exact interactions with Apple Silicon folks is and their glibness of it doesn’t clarify anything.
If you take a group that is trying to be very careful about the potential legal landmines a still nascent technology has and you get someone that espouses a general glibness about those concerns wanting to merge code…why on earth would you expect that group to accept them as a contributor?
This is not to say this isn’t really cool and a neat use of LLMs, but it is totally understandable why Asahi Linux won’t accept the fruits of this kind of development. If it turns out that Apple can identify its non-OSS code in this, it’ll be a mess.
> Asahi Linux folks are clearly more conservative and erring on the side of caution
I mean they are working around and on hardware controlled by a nearly 5 trillion market cap behemoth who has resources on the level of some nation states.
I'd be erring on the side of caution as well if they could hire that many lawyers.
> <StanfordAppliedCyber[m]> one of my friends is a very senior engineer who lead a lot of the sptm work and controls a lot of boot, may talk to him about it (obviously he hasn't told me anything that isn't public)
You are accusing someone by twisting their own words about their own self disclosed identity against them from a throwaway account created 5 hours ago.
And they say irony is dead.
I say this from an anonymous account but at least it isn't a throwaway. And at least I have the good taste to feel a little shame for my hypocrisy.
CA v. Altai (where the abstraction-filteration-comparison principle comes from) and SAS v. World provide pretty strong positive evidence that clean room is a valuable technique in both the US and Europe.
I do agree with you that the term is misused (it’s almost completely irrelevant here, anyway) and over-applied, but “not having ever been in a position to see or access the source code” is proven, especially in SAS v World, to be a pretty strong defense that’s worth pursuing in some re-implementation scenarios.
Absence of evidence isn't evidence of absence. "Not getting sued" doesn't validate a legal theory - legal theories are validated in court where they become case law. Until then, they are plainly speculative.
This "clean room RE" fabrication is also not something so obviously compelling that nobody would ever attempt to challenge it - it's just that nobody has cared to put dollars behind it. IP provenance cases are enormously difficult to prove and are almost always settled ahead of trial. This concept is software engineer folklore more than anything.
Saying you won't believe it's effective at all until someone sues and loses isn't the most compelling argument. If nobody sues then yes that is some evidence of effectiveness. It's not an absence of evidence, you're misusing that line.
>No statute defines "clean room RE" and there's basically no relevant litigation establishing case law.
You seem confused here? "Clean Room RE" is simply a descriptive result of copyright law in the US, and is well established. In the US there is no "sweat of the brow doctrine", pure facts simply cannot be copyrighted at all, nor underlying methods/ideas (that's patents). And as a direct result of the latter, again unlike patents, if two people truly independently write the same thing, both get separate copyright.
"Clean room reverse engineering" is just applying that to make any legal fight much cheaper or discourage it from every being bothered with in the first place. You have an RE "dirty" team that goes through copyrighted software and makes a specification that is purely factual, ie, "function 1 takes (int16)X input and does equation ABC on it, function 2 takes (long)X & (long)Y inputs and does LMN" etc. A factual/math spec like that cannot be copyrighted, so it breaks any derivation chain. They then give that, and only that with no other communications, to the clean team. If someone with no other exposure to the software being RE'd uses that spec to write a new piece of software themselves, then by definition the result cannot have any copyright of the original. It's a brand new work based off a list of uncopyrightable facts & math/ideas (though worth noting it could still get tripped up by abomination that is software patents).
There are other ways to argue against copyright infringement successfully, but they're much more subjective, which legally speaking reads "expensive, uncertain". CRRE simply trades that for two clear binary questions: was the spec copyrightable, and did the people writing a new piece of software from that spec have any previous exposure to the original? If the answers to that are no, then all arguments about function names being similar or whatever are no longer relevant.
On the subject of LLMs, one curious twist is that proprietary software might have less effective protection then open source depending on how it all goes. A coding LLM almost certain trained on all open source software available on the web. So there's at least some argument it's tainted. But proprietary software is proprietary. If the LLM has never had any of the source code in its training input, then isn't it clean in terms of producing anything derivative of that? That'll be kinda interesting, and might leave some companies with a bit of a conundrum (or I guess pushing the patent side even harder, but that has a much more sane 20 year expiration date vs copyright).
It's a defense. It's like having a moat around your castle. You don't need a moat to repel invaders since you also have a wall, and you might not get invaded anyway.
There's no law saying you have to do clean room RE. It's legal for me to look at a decompiled driver and write my own driver from scratch. It's not legal for me to just copy the decompilation, and a clean room environment is solid proof that it wasn't copied, but it's not the only way to not copy it, since I could also just not copy it.
But there are plenty of successful projects which would probably have been taken down if it wasn't for clean room RE. I mean just look at the clean room IBM BIOS clones from "IBM compatibles" in the early days of the personal computer.
The background level of software copyright legal actions is significant enough. If plane attacks happened that much then it would give us solid evidence of TSA effectiveness even if they never caught anyone directly.
Nintendo doesn't care. There's been proprietary Nintendo SDK code in libogc (open source library for making GameCube homebrew) for years. And more recently the various decompilation process have made recreations of linked code from the SDK that compile match byte for byte. In practice the legal risk of being sued into oblivion for this is not there. If anything there would be a DMCA takedown / cease and desist.
Right, but they are one of the biggest DMCA abusers. They killed many fan projects. They killed game renting in Japan as a concept. They killed Yuzu (a Switch emulator). And they could change their mind at any time.
> For the record Yuzu included code for circumventing Nintendo's DRM they had on game carts. It violated the DMCA.
It doesn't, this is what Nintendo claimed but it's false. The community learned their lessons from the Wii emulation era and you are supposed to bring your own keys, nothing is included in the emulator.
And yes, they also wrote this lie on their DMCA takedown against Suyu (which also doesn't have any keys), so they officially lied on a DMCA takedown.
There's no "circumvention mesure" in there, the emulator can only read unencrypted games by default. You won't find anything in the source code, if the game is encrypted, it cannot read it.
I disagree, this doesn't break anything, even the comments tell you so. This code does nothing by default.
Also I may mention that the support of external keys is there for you to get games for your own switch, pirates can just share decrypted games anyways.
Do you not see the references to decryption and decryption keys? This code is explicitly written to break the DRM of switch carts. If you mean by default you mean they don't provide a key, that doesn't matter in regards to it being considered corcumvention.
No that matters. As is, the emulator cannot be used to circumvent nor break any protection. Feel free to try it yourself, boot up the emulator, give it an encrypted game and see what it does.
Nintendo didn't want to get in court and also had to basically lie in a DMCA, I think that tells it all on their legal standpoint, they were afraid of creating a precedent.
Don't worry that if they were so sure to win, they would be in court already like they did with the R4 cartridge.
There's also been Wii games rereleased on PC with all debug symbols that cover the Wii parts that were still compiled in. You'd get mostly type names, enums, object layouts and function signatures that way.
there isn't ?? I sorta thought we figured all this out decades ago when SMB and DeCSS were being reversed? I think dosemu or something as well ?
I seem to recall DeCSS being the 'hot button' as it was RE'd in a 'non clean' way, the code released, and then a 'clean room' RE could be made from the 'public' info ??
edit: actually, at the time I think there was German law allowing RE for 'interoperablity' or some such. But that was a long time ago so my memory might be off.
> No statute defines "clean room RE" and there's basically no relevant litigation establishing case law.
It doesn't really make sense for it to be in a statute or in case law.
When you are a copyright infringement defendant the plaintiff has the burden of proving two things: (1) that they have valid and enforceable copyright rights, and (2) that you infringed those rights.
Direct proof of the later is rare, so they usually prove infringement by showing you had access to the work and that your alleged infringing work is substantially similar.
There are some defenses in the statute, such as fair use. With these defenses you are basically saying "Even if they prove everything that normally would prove they case, there is this exception that says in these circumstances I'm allowed to do that". (That's called an affirmative defense).
There are also affirmative defenses that were developed in case law. First sale doctrine was originally a case law developed affirmative defense, but was later incorporated in the statute. Copyright misuse is another case law affirmative defense. That one has not been incorporated into statute.
There are also non-affirmative defenses, often called negative defenses or failure-of-proof defenses. With these your defense it "They can't prove I did this thing that is necessary for them to win".
Clean room implementations are not technically a defense. They are a development methodology designed to provide rebuttal evidence to support a future failure-of-proof defense if you are accused of infringement.
How would you even put that in a statute? As far as case law goes all the case law you'd expect to see is around the particular evidence offered to show the implementers really did not have access to copyrighted elements of plaintiff's work, like record keeping and proof of authenticity and things like that.
An analogy would be like not having alcohol at an event you are hosting that is open to families because you want to make sure you don't violate laws against serving alcohol to minors. You aren't going to find a statute that says "Not having served alcohol to children is a defense to a charge violating the not serving alcohol to children statute". It is implicit in the not serving alcohol to children statute.
Any case law you find on this will not be about whether not serving alcohol to children is a valid way to avoid violating the not serving alcohol to children law. It will be about whether or not some kid that had alcohol got it from you or snuck it in from outside or about whether you took care to make sure your caterer adhered to you no alcohol policy or things like that.
"We don't want to take on the risk of working with a former Apple employee, who could potentially leak trade secrets and expose us to unwanted liability" is a very different statement than asserting that they were banned for deception. The post you're replying to is responding to accusations against their character and behaviour. Clearing those up is an entirely different matter than saying anything about whether former employees should be allowed to contribute to the project.
I'm sure Omarchy will appreciate the effort, even if you're snubbed by Asahi -- being able to run Linux flawlessly on Apple Silicon is going to be awesome.
I wouldn't expect "flawless" support for those chips in the next decade, even with AI. The earliest-supported Asahi chips still have missing power management and dark silicon.
The only way to get flawless Linux support is to buy hardware from an OEM that supports Linux well.
If using the OpenAI models to develop this taints you with Apple insider knowledge, then so is developing any macOS, iOS, Android or Windows apps around that are using any LLM.
You can't claim that some work is necessarily tainted by existing, you also have to prove which knowledge was retrieved, used and that there was no other reasonable way to know it. But unless it is actually tried in a court in all major jurisdictions, it's just speculation from all parties (including line).
One person could also claim that someone someday might leak information to them, and even though they'll ignore it, since they'll be exposed, they are tainted and can't contribute anymore. It'd be absurd.
A project is free to chose who can contribute, but they can't necessarily gatekeep others from doing their own project with different rules.
Yeah I see developers constantly saying they RE stuff using LLM in a clean room way and it’s definitely an opinion, not a fact. Just look at the most recent post here: https://x.com/ewninjaofficial
I'm not an expert on GUIs, but my understanding of them is that the ugly state is sort of inherent to GUI applications and you can't tame it. Ie, everything interconnects with everything else and there's not much you can do about that. This sort of inherently pushes you to a big runtime that manages a lot of stuff for you, which is in line with GUIs being rather expensive generally (ultimately you have to render everything to the screen).
reply