The ongoing genAI debate, vol. 1

Software Proprietary & Other
64

For initial port it is easier to bypass built-in firmware and implement its own one what will load Haiku kernel like I did with haiku_loader.riscv. Porting haiku_loader to virtual bare metal is not that hard and it is what I did before porting Haiku kernel to RISC-V. U-Boot is indeed messy thing and it worth to avoid to not waste time.

Just choose some single target for initial port and ignore everything else. Do not waste time on combinatorial explosion that in result become obsolete before Haiku ARM port become functional. QEMU should support some timer hardware, use that.

You exactly explained incompetence problem. Consistently wrong decisions that you explained extended ARM port from several months to decades. Again, effort is meaningless if it is done in wrong direction.

66

I’m sure you can time travel to 15 years ago and tell it to the people back then. It’s easy to say this now. It wasn’t back then. You can’t expect people to be prescient on what would happen 15 years later…

2 Likes
67

When I worked on RISC-V port, I almost not used or referenced Haiku ARM port efforts. The only useful thing was FDT support. So nothing fundamentally changed if ARM port was started 15 years ago with the same approach. FDT is not that game changer, MMIO addresses and IRQ numbers can be hardcoded to values used in QEMU in initial port. First step to solving problem is admitting it, not make excuses on how hard problem is or how times changed. If that 15 years Haiku ARM port effort will be interpreted as success story, not as failure, it will harm future Haiku development and let the same mistakes to repeat.

70

That is not what I wrote. It is a failure indeed. But if you blame it on “the developers are incompetent” what is the solution? Replace the developers? Fine, but then I can’t do anything about that, except stop touching the ARM port maybe (not that I do any work on it at the moment anyway).

So, we need to understand the context (which I tried to provide) and understand what went wrong. I don’t think your analysis putting that on incompetence is right. People made decisions that made sense at the time, depending on the available tools, hardware and information, as well as what they found interesting to work on.

And it was. Then that code was removed because people were working on various hardware and it made more sense to use FDT than have hardcoded definitions for each system.

As far as I know the big problems that have held up the ARM port are:

  • Toolchain issues: with the support for ARMv6 (pressured by high demand for Raspberry Pi support), with hard vs soft float ABI and even EABI vs OABI initially (fortunately that is behind us now). As well as linker relocation problems (“recompile with -fPIC” style of errors). PowerPC is going through similar toolchain problems, with the GOT and PLT things.
  • Support for the MMU and vrtual memory which is still not completely stable even today for ARM32. Anyway, it’s not like someone has been working on this for 15 years.

The main reason for lack of progress is lack of interest. If no one works on it, no progress is made. These issues are not particularly complex and a few hours or at most a few days of debugging will resolve them. And as we see here and also in your RISC-V port and in smrobtzz’s ARM64 port, when someone actually works on it, things will happen.

ARM32 is just not that interesting to target at this point, like 68K and SPARC. Unless someone really wants to, and then, I’m sure it will happen as well.

2 Likes
72

Unfortunately there are no good solution here because it is hard to collect highly skilled developers with enough hardware platform knowledge to quite small scale non-profit project such as Haiku. But at least we can learn from mistakes and success story, document it and tell it to new Haiku contributors who want to work on new hardware platforms.

It is very known problem even for x86. Haiku do not support ELF executable ABI, only ELF shared library ABI. So even executables should be compiled as shared libraries, but with non NULL entry point. Things like -fPIE or -static will produce incompatible broken ELF executables on any architecture. This information should be delivered to every new Haiku contributor who plan to work with toolchains. So it is largely documentation problem.

That -fPIE problem is sometimes happening even today on HaikuPorts. Maybe support of compiling ELF executables with unsupported ABI should be disabled on compiler/linker side.

73

I really appreciate you! I do see this differently though. Forking Tabby was the obvious and logical mechanism, and I’m grateful that the Haiku team not only allow for this, but even provide some nice documentation on how a fork or “distro” should look.

So, I’m able to pursue and share my experimental software, Haiku maintains its famous quality, and everyone is happy :slight_smile:

We actually have a really good starting point here for a sane but conservative AI policy in Haiku in my opinion. It would be sad if Haiku’s policy was just “F you and your AI crap” but that’s not the case - there is a very reasonable policy and even extra accommodation for us like this forum.

tl;dr I’m grateful for this community and all of you in it.

9 Likes
75

I still believe I am a highly skilled developer in that area. Around 2011- 2014, it was my paid job, even. When I worked full time for Haiku in 2014, we decided that I should rather work on WebPositive and not the ARM port. Otherwise, I’m fairly sure we would have a fully working ARM port much earlier. But I still think working on WebPositive was the right choice at the time It would certainly be different today, with a good selection of ported browsers now available. But at the time, all we had was a very outdated version of Firefox 2, a slightly less outdated âersion of WebKit, and that’s it.

I think you are also underestimating how the work on PowerPC and to some extent ARM helped your RISC-V port, by preparing Haiku for multiplatform support. I have no doubt that you would have managed to port Haiku regardless, but not in a form that would be upstreamable in any way, because that would require way too much refactoring, and you’re more interested in straight-to-the-point work. Nothing wrong with that, in some projects it’s what’s needed, and certainly Haiku does, in a way, benefit from having rore people like that. However, that’s not me. I rather like to take the long way, fully understand things, and do the boring refactoring tasks to set things up for the long term. But as a result I tend to get in the way of new features.

My paid job nowadays does not include low level hardware bringup, but does involve occasionally debugging Linux drivers (and a lot of userspace software oevelopment).

By calling the devs who are already here and know a few things incompetent, I don’t think you’re helping the case of attracting highly skilled people.

9 Likes
76

What are you talking about? A person tackling a tedious, routine task over the course of a week will consume just as much - if not more - electricity than an LLM solving the same task in minutes. It’s all just sophistry. And what about someone running local models that consume exactly the same amount of electricity as a 3D shooter player?

Should all gamers also be ostracized for being unethical (after all, they kill people in the game!) and for polluting the environment with their RTX 5090s - which consume three times less power than a kettle? Any electric kettle or air conditioner consumes significantly more electricity than I do when running a local model for log analysis on my 250-watt Tesla V100.

6 Likes
The great genAI moderation debate, vol. 1
77

It even makes things worse. When I worked on Haiku RISC-V port, I experienced it first time in my life. Haiku is basically where I got operating system architecture knowledge, I find Linux is too obscure and broken as learning material. I have never been involved in embedded development before and had no boards like Raspberry Pi. I am mostly software person, not hardware. My RISC-V Haiku port project first targeted TinyEMU only and there are no significant thoughts about real hardware. Port to HiFive Unmatched come later and it was not so difficult.

I still don’t understand why you calling it “attacking”. Maybe language or cultural differences. I absolutely have no intent to attack you or ARM/PPC Haiku port attempters. I am just analyzing state of affairs and historical background how it become that PPC or ARM Haiku port did not become functional even on virtual machine for 15+ years. I claim that it is not a port difficulty, but lack of proper skills and wrong decisions. If some right person had come to Haiku 15 years before, maybe ARM port was already complete for a long time.

1 Like
78

I generally have to agree with @memsom and @dcbeckman, but I also want to address waddlesplash here.

I disagree with the notion that you can find a clean divide between work done to make Haiku “cool”, and then to make Haiku “useful”. The entire project as I see it, will always draw people in the sense of fun. I doubt that there’s many people who are drawn to this project purely to use it as a daily driver. That’s not to say it can’t be a daily driver, or never will, but you could only consider it such the same way you could consider AmigaOS or Windows XP a daily driver. Impressive with work the community has done, but not a serious contender for the things we actually do with our computers (graphic design, MS Office, gaming). Most people here are computing hobbyists who think Haiku is fun and cool, with the possibility of being useful here and there. Most of the progress we’ve seen in making Haiku more usable in a “useful” sense was done in the sense of fun.

I do agree that senselessly throwing LLM code into the codebase is a horrible idea for so many reasons, however permanently shunning all LLM assisted work and code on the project is a similiarly horrible idea. With what LLMs have done for relatively esoteric work that would’ve depended on someone willing to waste time and hours on obscure topics (PowerPC port), they can do far more for work like the Intel processor core situaton with @rainygirl’s VAIO laptop.

I think the developers and users need to realize that extremes on either side are going to get us nowhere, we need to admit that LLM assistance can seriously accelerate Haiku in many ways and should do so for the best future of the project, but also acknowledge that it needs guardrails. This X post has a useful take, which is in line with how I personally feel LLM code needs to have human involvement.

Good moment today to remind everyone to stay frosty with AI. I was working on making a server stoppable via the CLI, and Codex decided the best path forward was to implement an unauthenticated network API to every server to shut itself down. Excellent work.

I responded with “I don’t know about that.” (I usually give more direct feedback but this was so absurd) and it thought for like 20 seconds and responded “Server stopping should not be part of an unauthenticated network API.” Yes. lol.

By the way, the result I was looking for was that we automatically start a locally discovery Unix-socket bound server so I wanted it to discover that (using prior mechanisms already made) and gracefully stop that.

The driver is absolutely accountable here (me). My lazy prompting led AI to think I wanted to be able to stop ANY configured server I was talking to. Shame on me for thinking it was obvious here. But, I also reviewed it and found this idiocy, so, that’s where good AI drivers come in. Also me.

It’s true that LLM code is always going to have suprising blind spots, that does not mean that the solution is to be a complete luddite. I’m going to agree with what X512 said here, and maybe go a little further to say LLM assistance in FOSS is here to stay unless you’re willing to put in the manpower for a hard-fork anti-LLM crusade. The only sensible option is to make sure we’re being rational in our LLM use, and to not blindly copy-paste LLM generated code into work or PRs, just as it’s expected not to blindly copy code from Linux or BSD into Haiku with no knowledge of what it does.

We should be catious; users and developers, to not let this disrupt or split the project or it’s community. Bad attitudes and extremes on either side, again, will get us nowhere and lead to that.

7 Likes
79

I, not surprisingly, disagree with you pretty much completely.

LLMs are probabilistic text generators; they do not and can not understand what that text will be used for. As such, nothing they produce should ever be considered fit for any purpose beyond play.

They are toys, not tools.

To make the whole situation even more fun, the likely results of treating these things like tools are, in order of desirability:

  • the “AI” companies collapse because not enough people will pay what running these things actually costs; tech industries have 3-5 years of non-deterministic coding to mitigate
  • the gradual drag of non-deterministic coding leads to large-scale collapse of tech industry infrastucture; the surviving pieces have 10-20 years of non-deterministic coding to mitigate
  • the “AI” industry joins the petroleum industry to bake the planet in an oven made of carbon dioxide and drown the coastlines in rising seas; subsistence agriculture makes a large-scale comeback; no one cares about whether anyone can get a chatbot to output compilable Python

Better, in my opinion, to be a Luddite.

(Generally, I don’t go full-on with my opinion of this stuff here since it’s not usually relevant; but this is the “argue the merits” thread, so booyah.)

3 Likes
80

Well, so do I! I noted in my original message: “these tensions exist within people and not just between people”.

And here’s where we’re going to disagree considerably. Haiku is far, far more usable as a daily driver already than those OSes are at this point. We’re not on par with Linux, sure. But we’re leagues ahead of AmigaOS and Windows XP, for the average user, since you can’t really interact with the modern internet on those…

I don’t know if that’s true but I also don’t know how you’d quantify it. Even before I was employed to work on Haiku, there was all sorts of work I did on the system that wasn’t particularly “fun” but it was definitely necessary (and obviously since I’m employed to work on Haiku, there’s been quite a lot more of that.) I am sure the other developers can say the same at one time or another. So what does that count as?

Why are you calling this “waste”? If we’re about having fun here, and there are people who shun AI and who enjoy working on the PowerPC port. So what’s the “waste” exactly?

Have you looked at any of that code? Do you understand how it works? If not, then how can you say that what’s done there was useful, rather than just saying that you like the particular outcome?

Or rather the “vibes” of the outcome, as I don’t suppose you have that hardware yourself (indeed how is such old hardware not an “obscure topic” by your standards?); so what value does that code provide to you, besides “feeling good” about Haiku running on another piece of hardware?

And why’s that? Whoever said that taking an “extreme” position doesn’t work? Maybe it’s the morally wrong thing to do for some reason, risks alienating people, etc. But none of that says that “extreme positions” somehow “don’t work”. We can look at history and find many examples of people with “extreme positions”, many of them abhorrent, who in fact were quite “successful”, by various metrics, and some for quite a long time…

The question then isn’t whether the “extreme position” is going to get us nowhere. Because even that by itself means that we’re asking the question of “what works?” before the question of “what are good things to do?”. We’re not trying to make money here, so we don’t need to ask the pragmatic question before the quality/values question.

Haiku has been around for 25 years and is still in beta. If that isn’t a sign that we’ve chosen “cheap” and “good” to the exclusion of “fast”, I don’t know what is.

If we wanted to “seriously accelerate” Haiku development (as you suggest), why wouldn’t we have adopted the Linux or a BSD kernel years ago? But we didn’t do that, and we still don’t want to do that. So why would we use an LLM, either?

The development team has already decided against the use of AI and that isn’t going to be changing anytime soon. The GNU project, from where we get a lot of our base system dependencies (GCC, coreutils, etc.), has also adopted some pretty severe restrictions on LLM use. I expect it is going to become more possible, not less, to avoid LLM-generated code and software as time goes on.

We don’t need to wage a “crusade”. We can just keep doing what we’ve been doing, only a bit more judiciously than before, and that’s enough.

4 Likes
81

Exactly right. Let everyone have fun however they please. But it follows from this that we shouldn’t preach or tell others how to spend their time. LLMs proponents simply want to be taken seriously, rather than being categorically and uncompromisingly dismissed. They don’t want to convert you to their cause - which is more than can be said for the other side. Every opponent of LLMs considers it their duty and obligation to lecture others. For the most part, that is precisely the reason for all the arguments on this subject

7 Likes
82

You’re pretty seriously over-stating the case here.

There are several extremely vehement anti-genAI folks here (even among the moderators), who just ignore the genAI posts rather than argue about it where it wouldn’t be appropriate to do so.

1 Like
83

That’s the problem. It doesn’t fit typical open-source projects. Expanding the rule beyond main-code LLM use feels like an adversarial stance against anyone relying on LLMs. I appreciate your hard work, but I was disappointed.

3 Likes
84

A collaborative project of necessity has to agree on common practices and standards in order to collaborate at all. So we can’t coerce people to do anything, but we also can very much establish standards and say that anyone who isn’t following them isn’t welcome to collaborate. We have done this for code quality and all sorts of other metrics going back to the beginning, as has every other open source project. Some people disagreed about those standards, and left.

Now we have added one more thing to that set of standards, which wasn’t necessary before because it didn’t exist then. Perhaps some people will leave over this, too, or already have. But it doesn’t follow from what you are saying here that we can’t establish such standards, because we have always done so.

4 Likes
85

To begin with, we need to distinguish between two things, because people discussing a ban on LLMs here often have different things in mind. Some are talking about the Haiku project itself and its codebase, while others are including ports and third-party software in the conversation. I agree that implementing code acceptance policies for the core project is reasonable - at least at this stage. But the majority of opponents simply shout things like Ban it!, No way!, Neuroslop!, You don’t understand anything!, Your code is crap!, and so on. I don’t think that’s the best strategy for such a small community. Above all, we shouldn’t descend into paranoia or act like cultists. You have to understand: I’ve said many times that I am not advocating for pushing unverified code into Haiku; I have simply always opposed - and will continue to oppose - foolish bans that extend beyond the scope of the project itself

6 Likes
86

I agree with some of your points. What I meant by that work being a “waste” of time, is the sense that it’s unforgiving esoteric work meant mostly for hobbyist use, most people will see it as a waste. Though it was not the best framing. I personally love that kind of stuff, but someone is going to have to spend a lot of time to get it working. If you’re laser focused on usefulness, it’s a waste.

While your point on the VAIO example with seperating the outcome with correct, maintainable code is valid, you’re dismissing it a bit too quickly as pure feel-good. Even if you don’t own the hardware, a working patch to fix multicore support is a solid data point on what LLM assisted reverse engineering and work can achieve. The right question would be, is the resulting code understandable and maintanble by humans who were not the original prompters, did the original prompter let the LLM go completely off the rails and make new security vulnurabilities. That actually brings me to my next point.

The claim that avoiding LLM generated code entirely will become “more possible” is a bit overly optimistic. The broader FOSS ecosystem is just not going that way, and I’d point towards the GNU project which you mentioned. GNU hasn’t adopted a complete LLM policy, but GCC itself requires any legally significant work by LLMs be rejected, and that legally insignificant contributions can be accepted if they meet normal standards and are clearly marked, as well as the human contributor being required to understand the change and answer questions about it. This is a well thought-out policy based on the potential copyright and maintenance questions that LLM work has raised, but is not a luddite policy. It is a very pragmatic policy that should be considered here as well. I think it’s a little more narrow and pragmatic than you suggested, it doesn’t really fit the approach that was pushed.

2 Likes
87

In your view, you mean. Why should we assume your view is the objectively correct one?

I have heard views like this one advocated for before, and we’ve decided against it for various reasons.

… which they give a rule of thumb for: “about 15 lines of code”. By that standard, 99% or more of the LLM-generated patches that people have tried to submit to Haiku, or have posted elsewhere without asking they be included (these VAIO patches obviously among them) are totally excluded. So the GNU project policy is actually extremely strict even if it isn’t a complete and total ban.

2 Likes
88

After these statements, and after my proposal was hidden for being inappropriate, I am re-applying to be a moderator for this forum, in direct opposition to these ideas. I wonder what Stippi thinks about these words, given the work he is currently doing with LLMs.

4 Likes