Hacker Newsnew | past | comments | ask | show | jobs | submit | KerrAvon's commentslogin

There are pictures, dude. What is wrong with you?

Haiku should rethink that AI rule. Put very high code quality gates in place, sure, but Haiku in particular is a very low-velocity project and AI could help them so much. There is no reason you can't produce high-quality code with AI conformant to your style guidelines and structural preferences, it just takes a lot more effort than the slop.

I'm curious why velocity is sooooo important. Every single AI discussion that I've read always always always mentions velocity or development speed as though that somehow is the ultimate goal. Why does it matter if your velocity isn't as fast as everyone else? Maybe taking things slowly might actually be a good thing.

I'm not at all trying to be overly critical or pissy; I'm genuinely curious as to why this is always the gain that AI brings as though it matters (or, rather, this is how it's always stated in one way or another). So I come from a place of confusion when asking this. Why should I care if you can write 100000 or 1000000 lines of code and push out 10 billion commits per minute? (Yes, I am intentionally exaggerating here to prove a point.) If anything, I would argue that increased velocity just brings about recklessness and unnecessary churn instead of accomplishing anything useful.


Velocity is important because we all eventually die.

I've been following Haiku since it was announced. In that time a couple of personal friends have passed on, and a number of family members. In that time children have been born, gone to school, grown into adults, and had children of their own.

Projects that drag on forever make for an interesting artistic statement, but if their goals in any way include utility then velocity is important because time is important.


Not everything has to happen in your or my lifetime. Not everything will happen in our lifetimes. If time is so important, Haiku was never going to work for you anyways on account of it being niche, which adds friction, which adds time. Velocity isn’t going to fix this either

As I mentioned, projects that take a long time make for interesting artistic statements. But if the goal isn't performance art but is utility, then alacrity matters.

Many other niche projects have enjoyed enough velocity to have meaningful utility, in my lifetime. Linux was still niche when I started using it in '94.


I think that's a false dichotomy.

Some people enjoy building things. It's not performance art, it's a hobby. Can Haiku not be a hobby for people who enjoy hacking away at BeOS? (You might think I'm splitting hairs here, but performance art is precisely the wrong analogy to use, since performance art is for the benefit of others. Performance art is inherently public and assessable in terms of how it reaches others, unlike hobbies. Performance art is env=PROD.)

Was the purpose of Haiku ever utility? What do you define as utility? If I spend a day building a shelf, does that have more or less utility than buying a shelf from IKEA? What if I like making shelves? What if I like making OSes? Does the shelf (/OS) that I build have less utility than the one from IKEA (/MS)?

In economics, utility is a measure of individual satisfaction. The person who likes tinkering with Haiku is deriving cold hard economic utility from Haiku right now. What should it matter to this person whether you find Haiku web scale and production ready? John Q Public is never going to run Haiku, no matter how much polish you throw at it. Why rush to some goal line that doesn't exist in the first place?


If its purpose is to be the output of a hobby then it is art; if it is shared with the world, then it is performance art.

Art has utility, of course; but we're discussing primary goals.


Velocity of LoC isn't important. Velocity of user visible improvements can matter if a project feeds off of usage and popularity. Or at least that velocity matters until the OS is capable enough to satisfy the user base.

I... Don't agree with this. If your users have followed your projects developments even remotely reasonably, you taking a few months to implement something or to figure something out is not a sign that the project is dead. It would be one thing if your project was completely inactive for like 2-3 years.

Haiku OS has gone up to 6y between releases. While not entirely inactive in that time, lurkers who aren't as motivated to dig for signs of life could reasonably conclude the project is inactive.

For example, I'm a big fan of DOSBox. And while the core project still has some code check-in's from time to time, its last release was 7ya. Now I use and follow forks because they're consistently releasing useful features and fixes.


Haiku feeds off the interest and fun it brings to its developers. If you put AI in the mix you can poison what they do for fun and sink the project.

I imagine that their issue is reviewer bandwidth.

If all submissions were high-quality, it would probably work. But that is probably unlikely.

Maybe the project could host a searchable directory of AI contributions hosted at external GitHub repos or something.


My understanding is that the AI policy is more to do with issues of copyright and code provenance. They want to make sure that all of their code is cleared with no risk of accidentally using 'stolen' code or GPL code repeated by an AI. I can at least understand the policy.

I think there's other opinions around AI use there as well, but I'll back off from that. I didn't mean for my post to become top voted, when we should be celebrating Haiku reaching Beta 6. I'm just disappointed that for me, R1/b6 has been a very big regression, right at a time when I've been using AI to make all the software I write cross-compatible with Haiku via Go & SDL, and even use AI to write drivers so more of my hardware works on Haiku... and instead, now I can barely even boot the system.


OpenAI at least provides legal indemnification against those claims

> I imagine that their issue is reviewer bandwidth.

This feels to me as the real bottleneck in general. Maybe along with thinking through what to code/prompt.

I don't need more tokens or automated generation of PRs, I'm already at capacity for the care and understanding I want to have for code I own.


I have no qualitative opinion as to whether the Haiku team should reconsider the AI rule or not, but you select about just one possible advantage. There may be disadvantages using AI. One that keeps on happening is that real humans use AI slop spam to pester other humans with it.

> There is no reason you can't produce high-quality code with AI conformant to your style guidelines and structural preferences, it just takes a lot more effort than the slop.

It's not just code though. There are humans who deliberately and actively use AI slop to spam people. I saw this first on gobolinux, then on prawn, then on the ffmpeg mailing list. There are really good reasons why many humans dislike the proliferation of AI slop spam.

> Haiku in particular is a very low-velocity project and AI could help them so much

I am not entirely certain about that. If AI were to work so well, Haiku-AI could have already been insta-spawned and auto-fixed everything. Clearly this does not work, so I am unconvinced that AI is the final solution to everything - at the least right now.

What is also unfortunate about Haiku is that things such as ruby do not work by default. Ruby even works on windows, though on Linux it is much more convenient to use.


No one is trying to get rich from working on Haiku. They are doing it for fun, as a passion project. Sure AI would help with velocity but velocity is not the only goal. Journey before destination.

Also: Open source is about relationships.

Reviewing code sucks. However at least reviewing code from humans allows you connect and learn from each other. You get to mentor someone. Build a relationship and trust. They learn and grow and maybe someday can also review other people's code.

Nowadays with lots of low effort merge requests and spam it is already easy to burn out. Now add AI. Yeah, no. Why should anyone review AI slop for free. Why? It is the prefect solution to burn your contributors out.


What is a high code quality gate?

Besides telling the AI it's an expert and to build perfect code?


I think the most productive thing is:

1. Read rules about not using AI

2. Reflect upon and understand why they exist

3. Develop software however the f*ck you want

4. Ensure it is high quality

5. Open a PR

6. Don’t tell anyone (i.e. don’t do the things people hate about AI-assisted code)

People are going to get made at this take but come on, we’re trying to build things. Use the hacker spirit. Make things that solve problems.


I think it'll need a compelling DAW to make that a reality.

IMHO, it's not just DAWs keeping people on main OSes, but plugins. On the Linux side, Reaper, arguably one of the most popular options on Windows/macOS, has been available since 2018, BitWig is a good Ableton-like experience, and Ardour is also decent. But on the side of plugins - in my case drum VSTis and amp sims - the selection is still quite limited.

Not entirely sure what point you're trying to make, so maybe this is not relevant to it, but, in 2026, satellite emergency support makes it seem irresponsible to not take your iPhone if you value your life or have other people in your life who would miss you if you were gone.

well, iphone dies of battery discharge.

in 2023 I had a pretty nice night ~4km from a town in Montenegro. I could even see it from the mountain I was at and still had to sleep under a bush because I was not prepared enough. Thanks to thousands years of history they have ancient outlets for mountain springs so you can have drinkable water in most unexpected places while walking down from a misadventure.

Imagine that happening ~20km off civilization. Unprepared one will just die, iphone+satellites or no.


100%. LGs work perfectly well in this role.

Yup. Samsung & Sonys too. Dumb mode, no internet, Apple TV.

Doesn't solve the malware on Windows PCs installed by LG monitors problem. My only solution to that remains to not buy Lucky Goldstar ever since their 14" 640x480 VGA monitor died inside of warranty but they refused to fix it.


FWIW, I'd bet you'd never have noticed the difference.

it is once again time to balance out paulg sycophancy https://idlewords.com/2005/04/dabblers_and_blowhards.htm


top comment right now on this very page: "But actual results inside phone with smartphone cooling and wattage requirement became close to 3300"


No lmao, top comment is saying MediaTek's variant of an ARM C1 Ultra dropped to 3300, attempting to link it to this CPU through vibes and magic


What's amazing is that all of these are true at once. If you allow for some significant slack in what "superintelligence" means.


> the 24GB card that's been sitting in gaming PCs since 2022.

I'd wager most people have less. In 2022 a 3080 might have 12 GB if you were lucky, 10 if you weren't -- and you paid for the privilege. A current RTX 5080 is only 16GB.


The most recent Steam Hardware Survey[0] lists the most popular VRAM at 16GB in 25.9% of users. Second most popular build is 8GB in 25.3%. >=24GB is ~7%, which is quite a bit higher than I expected.

[0] https://store.steampowered.com/hwsurvey/En


As RAM prices are so nuts, I picked up a used gaming laptop early this year with an RTX 3070 (i.e. 8GB) to match the specs for my gaming tower that's run everything I'm interested in just fine. That includes recent Unreal 5.x games (Satisfactory, Fortnite, etc.) with high graphics settings on a 4k TV (60hz). There aren't a ton of games that require more than 8GB of GPU ram.


In 2021 I was considering getting a then-old K80 card because it had the highest VRAM on the market at 24GB and all newer cards had 8 or 12GB.

(Apparently this is because the K80 is two separate GPUs on one card, but I still think it counts if you only have one slot to put it in)


I'm still getting by mostly fine with a 4GB 1650 Super. (2020 vintage.)


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

Search: