| ▲ | nsbdhciebsbdhc 2 days ago |
| Wanting stuff to work is a valid reason to not use AI for more sophisticated development projects. Having a computer that kernel panics once every three days is useless to me, even if it works for you. |
|
| ▲ | Kwpolska 2 days ago | parent | next [-] |
| A kernel panic is the least of your worries with this hardware. Asahi had to introduce a custom daemon to avoid frying speakers. Apple doesn't need to care about making the hardware interfaces safe if they control the entire stack, so they don't, and expose dangerous capabilities to the OS. |
| |
| ▲ | jasonvorhe 21 hours ago | parent | next [-] | | Has anyone blown out some component of their Apple Silicon Macs over the years, whether via traditional or AI-run RE? Haven't encountered any reports about it yet. | |
| ▲ | Wowfunhappy 2 days ago | parent | prev | next [-] | | Does this generalize to basically anything outside of speakers though? I think a pretty easy solution is to not use AI for that specifically. | | |
| ▲ | orangea 2 days ago | parent [-] | | thermal management is the first thing that comes to mind. and battery management | | |
| ▲ | getcrunk a day ago | parent [-] | | You would hope both those systems have built in hw failsafes | | |
| ▲ | kortilla a day ago | parent | next [-] | | A blown fuse is a failsafe but that’s not helpful for users. | |
| ▲ | Kwpolska a day ago | parent | prev [-] | | If they removed the hardware failsafes from speakers to save a cent per device, I wouldn't be so sure. | | |
| ▲ | Wowfunhappy a day ago | parent [-] | | In the case of speakers, though, what would a hardware failsafe even look like? It would probably be some sort of secondary chip; Apple's design is to just move that to the main processor, the same way they don't have separate SSD controllers. Monitoring the CPU temperature feels very different to me. I'm pretty sure the CPU can't cook itself. This is probably documented somewhere so we don't need to speculate, but I can't research right now... |
|
|
|
| |
| ▲ | LoganDark 2 days ago | parent | prev | next [-] | | There was a fun period of time where Boot Camp still existed, but Windows could fry the speakers because it didn't have any of macOS's thermal protection. I think this was after the 2016 redesigns, as I had a mid-2015 with no such issue. | |
| ▲ | perching_aix a day ago | parent | prev [-] | | Good thing they only ever write correct code which consistently obeys every invariant in that entire stack ever. Excellent design, meet perfect engineering. |
|
|
| ▲ | gloxkiqcza 2 days ago | parent | prev | next [-] |
| Linux kernel itself is AI development friendly. |
| |
| ▲ | tonyedgecombe 2 days ago | parent | next [-] | | Some of us think that is a mistake. | | |
| ▲ | aeonik 2 days ago | parent | next [-] | | Hmm very vague. "Some of us". Do the massive amount of vulnerabilities not make you think twice? At this point, I trust human code less than llm code. Design and architecture of the code still greatly benefit from a good human touch, but I'm not sure how long that will remain true. https://www.phoronix.com/news/OpenAI-948-Linux-LPE-Bugs | | |
| ▲ | nsbdhciebsbdhc 2 days ago | parent | next [-] | | So validate with an llm and humans. People committing code they haven't read - which will inevitability happen - is dangerous and hard to remotely verify. | | |
| ▲ | zdragnar a day ago | parent | next [-] | | People using LLMs put up much larger changes, and much faster. Depending on the LLM used the quality is often much lower. A lot of projects just stopped accepting any outside contributions rather than deal with the tidal wave of slop they were getting. Choosing to not accept LLM code is IMHO a better compromise. | |
| ▲ | rowanG077 2 days ago | parent | prev [-] | | In the end there is always a separate reviewer. Even if the producer is adversial and not even looking at the code then this process exists to catch it. This is not at all different from people attempting to get backdoors into Linux. |
| |
| ▲ | codedokode 2 days ago | parent | prev [-] | | LLMs will introduce new vulnerabilities. What Linux should have done is stop using non-standard C, or better, stop using C completely in favor of Rust, support code analysers. | | |
| ▲ | palata 2 days ago | parent [-] | | And humans can introduce new vulnerabilities, too. Linux maintainers accept patches from random people over the internet. They already have to just the patch on its technical merit, not on who submitted it. For them I don't think it makes a difference (technically) if the patch was written with the help of an AI. I believe that there may be valid reasons to refuse anything that was touched by an AI, but that's not about security. It's more about the non-technical problems coming from AI (centralising power, increasing inequalities, carbon footprint, ...). |
|
| |
| ▲ | jasonvorhe 2 days ago | parent | prev [-] | | Some people will always disagree with something. That's what's great about free software. There will probably be some Luddite anti AI Linux fork at some point. |
| |
| ▲ | cromka 2 days ago | parent | prev [-] | | That's not what they meant. It's AI friendly, not slop-friendly. There's a reason no Omarchy patch of any kind has made it to the kernel list yet. I did personally look into some of their code and it is certified, hacked-togeter slop. | | |
| ▲ | ffemac 2 days ago | parent | next [-] | | Exactly. As an example, read that Gravity Linux guy's responses here. I will never ever trust him. I will stay away from his code as far as possible. Asahi team: I have my trust in you. | |
| ▲ | ChocolateGod 2 days ago | parent | prev [-] | | How do you define the difference between ai friendly and ai slop? | | |
| ▲ | dj_morocco 2 days ago | parent | next [-] | | I'm pretty sure Asahi devs experiment with LLM tools, but not to Omarchy's extent. LLM ban is purely a filtration filter, so that they wouldn't be spending time overbearingly exhausting number of patches generated with AI, and not someone who cares about this than a shiny tool. Everyone understands that LLM is a mean to an end, but it's clear that Omarchy got two confused and it's showing. | | | |
| ▲ | inejge 2 days ago | parent | prev | next [-] | | My definition, FWIW. AI-friendly: you can use the LLMs however you wish, but you must thoroughly understand every part of submitted code. Slop-friendly: understanding anything is optional. | | |
| ▲ | ChocolateGod 2 days ago | parent [-] | | I also agree with that definition. But for example if I get an LLM to generate 95% of a program, but I understand and have read every line of code, is it still slop? Some would say yes unfortunately. | | |
| ▲ | palata 2 days ago | parent | next [-] | | Not the OP, but I wanted to share my 2 cents: As an open source maintainer, when someone opens a PR, I don't know who they are. But I don't really care. I care about the PR: is it a "good" PR (there are multiple dimensions: is it understandable, does it add maintainable code, was it tested, etc) or not? I think "AI-friendly" says "I don't care if it's written with an AI or not: I want good quality PRs". I would think that "slop-friendly" is the kind of projects where the maintainers don't read the code. Maybe they try the feature (maybe not even?). I think the Omarchy guy was explaining somewhere that he does not read the code anymore, he just lets his AI write Rust. This is slop-friendly IMO. If you are not AI-friendly, it means that you refuse to accept a good PR even if you cannot tell that an AI was involved. The mere fact that an AI was involved disqualifies the PR. | |
| ▲ | shwaj a day ago | parent | prev [-] | | Are you one-shotting then reading/understanding? Then probably slop. Are you iterating to help you understand, prompting to rename/restructure/document until you would have been able to easily understand without AI? Then probably not slop. |
|
| |
| ▲ | flykespice 2 days ago | parent | prev | next [-] | | Ai friendly patch: * Author posts patch with a manageable number of lines so maintainer doesn't gets burned out reviewing it. * Tries to outline on the body what the patch is about and his rationale for the design decisions on the code. * Promptly answers any maintaners questions about the line changes. * Discloses which AI model he used to assist on the patch and how was it used. AI slop patch: * Submits patch with huge lines of code without explanation. * The body is written in a self-patronizing tone with superfluous formatting that helps nothing but annoys who is looking for the actual substance of patch * When questioned by maintainer about some line changes either goes radio silent or reply with the usual AI tone of marketin salesman. * rarely if ever discloses AI usage. | | |
| ▲ | mrheosuper 7 hours ago | parent [-] | | >* Discloses which AI model he used to assist on I don't see why this is necessary ? Does it provide any useful info, or just noise. |
| |
| ▲ | tkel 2 days ago | parent | prev [-] | | experience |
|
|
|
|
| ▲ | BluSyn a day ago | parent | prev | next [-] |
| Human slop is far worse than then AI slop. |
|
| ▲ | orangecat 2 days ago | parent | prev | next [-] |
| It's amusing that people still default to "human-written code is solid and AI code sucks" after the enormous quantity of bugs that AIs are finding in human-written code. |
| |
| ▲ | sashank_1509 17 hours ago | parent | next [-] | | Honestly aesthetically, good human code is always >> Opus 5.5. For example, recently Opus 5.5, in some multithreaded app I was working on at work, used complex timing analysis with hardcoded time values 1.2, 0.95 etc to ensure that some activities only happen in a sequence (A->B->C). I had to tell it to just serialize these activities by putting them in a buffer. Both versions passed all tests (I’m sure it wasted a lot of time tuning the first set of numbers to pass the tests, but no human would do that nonsense). Increasingly, you feel it’s thinking diverging from humans more and more as the labs lean into RL. | |
| ▲ | bigstrat2003 2 days ago | parent | prev [-] | | Nobody has ever said human code is perfect. But it is empirically the case that code written by LLMs is on average lower quality than code written by humans. | | |
| ▲ | habitue a day ago | parent | next [-] | | That's not really true, and it's only even potentially true if we talk about the absolute cream of the crop developers. Most human written code is quite bad actually | | |
| ▲ | saagarjha a day ago | parent [-] | | > absolute cream of the crop developers You’re reading their blog |
| |
| ▲ | BluSyn a day ago | parent | prev [-] | | This has not been true for 6 months. Update your priors. |
|
|
|
| ▲ | kcb a day ago | parent | prev | next [-] |
| Having a computer where half the features don't work isn't particularly great either... |
|
| ▲ | nickysielicki 2 days ago | parent | prev [-] |
| [flagged] |
