Live data from Hacker News

Changing how we develop Ladybird

ladybird.org

581–590 of 602 posts

Re: Changing how we develop Ladybird

#581
post #551

Earlier quoted context omitted.

In the Netherlands anyone may do the wiring of their house themselves but if it is a substantial modification (or an entire installation) a certified electrician has to sign off on it. They are not likely to stick their neck out for any funny business. That said, I've seen plenty of work from experienced certified electricians that was complete garbage. Not just a few things, more than half their work. Things like, t…

You've got romex in conduit? I'm not an electrician, just a DIY enthusiast (and the parent commenter) - but in North American construction, romex in conduit is basically unheard of in residential builds - it's stapled to the framing during construction, so once you cut wire short, you've immediately put yourself in a pickle.

We use rigid 16 mm pvc conduit (bend with heat) with 2.5mm2 wires in brown(+) blue(-) yellow/green stripe(gnd) and 1.5mm2 black for switched wires.

Ideally you bend the pipe as little as possible and make the corners as smooth or as blunt as possible. If done properly you can later add extra wires. If not done properly you only get the illusion you can.

With romex you have to anticipate future changes.

Re: Changing how we develop Ladybird

#582
I develop/maintain several a few small FOSS libraries. I've not received any AI-generated patches/PRs - that I know of, anyway - but I have always had a bias against people coming out of the blue with a PR, as opposed to:

1. Opening an issue. 2. Talking about what they want/need that's not catered to right now. 3. Asking for my thoughts or suggestions - even if they already have a potential PR to submit.

and that is for a small codebase where changes are rarely that big of a deal in terms of amount of effort.

I've gotten a few decent 'cold-submit' PRs as well, but my bias has usually borne out, in that these are usually PRs to reject, and only some of the time get adapted into something useful, following some back-and-forth of course.

So, on the one hand, the measure the LB people are taking seems extreme to me; but the previous state of affairs they allude to seems equally weird. (I mean, unless it's a "here is a two-liner fix for a bug" kind of patches).

Re: Changing how we develop Ladybird

#583

I've been looking a lot at Godot (another big open source project) PRs lately, and there's been kind of a surge of wholy ai-generated PRs (both code and description). This is agains project-policy, so people creating these PRs usually get mildly told off. What's surprising is that while many submitters take that fairly well, some people get really indignant, essentially calling the maintainers ungrateful. It's kinda…

There is certainly a certain... entitlement? (It's not the perfect word, but I fail to find a proper term) from some of the vibe crowd. Like an attachment to the output and refusal to accept that most of the work was not theirs. It is seen in the way they approach contributions but also in regular language. I created X, insistence that their 'curation' was very influencial to the output, difficulty to mention LLM con…

> 'I care about building while others lose time in details'

Them's fightin' words.

A person who says that to me - I ban them from... well, actually, I don't believe in banning people from platforms. Let's say I put them in my basket of deplorables.

Re: Changing how we develop Ladybird

#584

Earlier quoted context omitted.

There is certainly a certain... entitlement? (It's not the perfect word, but I fail to find a proper term) from some of the vibe crowd. Like an attachment to the output and refusal to accept that most of the work was not theirs. It is seen in the way they approach contributions but also in regular language. I created X, insistence that their 'curation' was very influencial to the output, difficulty to mention LLM con…

I've experienced the following sequence more than once at work, and I remain baffled by it each time: - Receive a huge vibecoded PR for complicated new feature. - Complain that this needs some design doc to figure out the right approach first. - Author says no need for design doc, easier to have vibed implementation and discuss the concrete code instead of abstract document. - I disagree (obviously), but review the P…

> They go sulk to their manager that I'm not interested in helping them launch.

But what happens if:

* You're not the only possible reviewer, and they get some patsies / kool-aid drinkers to approve the PR?

* Their manager is also the code repository owner?

:-(

Re: Changing how we develop Ladybird

#585
post #266

Earlier quoted context omitted.

We already have trouble with people maintaining open source projects without getting paid, now you want people to pay for the privilege to participate in free work?

It's a bond not a fee. If the maintainer feels that it's spam, they keep the bond. If they feel like it's not, they leave it.

That doesn't change that E(cost of submitting a patch) is nonzero.

Re: Changing how we develop Ladybird

#586

Earlier quoted context omitted.

> we are not the same kind of engineers as people who build brindges or airplanes. No shit. I'm arguing that we should be held to similar higher standards.

What if the degree doesn't really help with that?

Of course the degree doesn't help with that. What helps is accountability. When a bridge collapses, and it turns out the engineer who drew the plans made a mistake, they can be and often are held criminally liable.

When's the last time you saw a software engineer prosecuted for criminal negligence after a design error took down Cloudflare or whatever? Attitudes in software development will not change until that becomes a viable scenario that people anticipate when making design and implementation decisions.

Re: Changing how we develop Ladybird

#587
post #63

> There will not be a [..] process for submitting patches by [any] means > Outside involvement still matters: clear bug reports So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it. Instead they have to re-figure it out. The team must be thrilled to re-do work they know was already put in by others, repeatedly. As a user-and-eveloper, why would I sink time into a project with such…

> So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it.

Yes, and this has always been the case - see also: XY problem

> Reviewing code fixes is strictly easier than coming up with them yourself.

This wasn't even the case before the slopocalypse.

Re: Changing how we develop Ladybird

#588
post #326

Earlier quoted context omitted.

You can stop at any time. It's an unfortunate reality that many will not pay much mind as long as it's other people who are being harmed, but why support something morally and financially when it's now destroying something you personally care about?

For many, there's a cost involved in stopping, and not all can bear it.

Can't they?

Re: Changing how we develop Ladybird

#589
post #563
post #388

Earlier quoted context omitted.

Every like to an AI-generated work is (literally!) one more data point in support of record labels dropping human artists for AI artists that will do what they want, perform where they want, and give all of their profits back to the label. Movie studios are "signing" AI artists from AI studios for massive dollars; this is happening. Maybe you don't care, but music is beautiful and difficult, and I really enjoy hearin…

I dont think AI music proliferation is in favor of music studios at all, hence why they want to crush it by all means necessary. You should question your stance when you find yourself on the same side as the MPAA/RIAA/etc. I am in favor of being able to find music I like, with the least friction possible, without fueling the legacy music industry that is inflated far beyond reasonability.

> You should question your stance when you find yourself on the same side as the MPAA/RIAA/etc.

This is tribal thinking.

Re: Changing how we develop Ladybird

#590

Reading this leaves a weird taste in my mouth, since the author tends to regularly make nontrivial >1k LOC PRs (sometimes several per day) and merge them on the same day with no reviews at all. This is even ignoring the LLM aspect; I don't know what % of them are assisted, but even if it was 0%, this isn't the pace of development I'd be comfortable with.

Yes, I have lost faith in some open source project maintainers that are doing this. There is an open source platform we've used for years at work (we use the paid Enterprise version of it) that introduced some pretty grotesque security flaws and when I looked into it I realized AI had taken over the project - you can clearly see it in the commit log whether it is attributed or not, just based on volume and frequency.…

It's the open source equivalent of brands dumping quality in order to maximize profits. The end result in both cases is that trust is lost much more quickly than it can be earned.
Post reply on HN