I get that we wouldn't want to single out specific nations over others on the designs.
But I kinda wish we would national designs like we do for the coins, one side's standardized and the other gets a custom design depending on the nation. I think we'd get a lot very neat variety, but I understand that it makes things a lot more complicated and expensive.
e.V. members get to send in proposals which are voted on in the (yearly) general assembly, this was one such vote.
So everyone who voted is known by their full name and address (a legal requirement for an e.V. in Germany). There is no sabotage here.
Yes it's community run and you have to be member to get a vote. Paying fees as member is one of the most common ways how similar structures work outside software. Even politcal parties work this way.
An e.V. (eingetragener Verein) is a legal structure in Germany, the tldr is (I'm not a lawyer this isn't legal advice):
• there has to be an annual assembly where all members get invited to
• members may send in proposals, which get voted on during the assembly (in codebergs case the voting is done asynchronously, you get like 14 days to fill in your votes)
• members elect the people on the board
• the e.V. also needs to have formal bylaws for which any change has to be voted on and it's a bunch of paperwork to change them (see https://codeberg.org/Codeberg/org/src/branch/main/en/bylaws....)
A member is someone that signs up and pays a membership fee (currently that's at least 24€/year, see https://join.codeberg.org/).
So yes, the people that pay get to vote. But we're also the ones sending money in to pay for the servers (which is the main source of income for Codeberg), since the e.V. is considered charitable I'm pretty sure this is legally a donation but im not gonna pretend to know things about our tax system.
I get that this sounds strange to people outside of Germany but it's a very common thing here, your local football club is an e.V. for example.
It's also not that rare within the foss/software/nerd space, KDE and the CCC are both Vereine as well.
There has been a long discussion and "conflict" of opinions regarding the use of AI in kernel dev.
Linus is pro-AI as a tool ( and I mostly agree, there are consequences however that at least need to be talked about ). That's why I was talking about firing up those AI machines and fix those CVEs ( "make no mistakes" ).
But it seems every Linux topic related to security or languages is the ultimate mine field for knee-jerk reactions. :)
That's the neat part: the money doesn't have to exist at all.
And once you go through enough hops and convince the world that this thing which your company happens to be pioneering will forever change the world and everyone will use it the money circle isn't even relevant because the entire goal was to make your stock prices skyrocket and now you're valued at ridiculous levels!
Just make sure to get out of it all before any Investor actually wants to see real profit being made.
For instance, the TypeScript rewrite in Go was done mostly by humans and took a year before it was released. That is how you rewrite software that people can trust.
`mostly` is doing a lot lifting here. The Go rewrite uses plenty of copilot. The reason you trust it is because you trust the people doing the rewrite.
I mean, yes? Every engineer on my team produces better code than Claude. There are plenty of examples of excellent human produced code, so this argument always falls flat for me.
AI is a great use for this kind of boring, rote translation where precision is important. Humans are quite bad at it and tend to make mistakes. In either case the focus should be on improving testing, not trying to manually verify if the translation was correct by eye.
I really wonder where all of these people who believe that tests perfectly encapsulate the behaviour of software come from. Maybe it's because LLMs happen to work better when you give them acceptance criteria and people struggle to distinguish between "better" and "good"?
The real test is years in production. Over time your test suite grows when bugs are found and fixed, but not every bugfix necessarily gets a test, and it's very rare that a bugfix is exhaustively tested. Relying on the test suite as a directional indicator that your vibecoded rewrite functions something like the original is probably sensible. But it isn't "done" until you've run it in production for at least as long as the original. And that's where it all falls apart, because maintenance will be a nightmare. Nobody knows how the new thing works.
Ladybird's Rust port of the JS engine was a good example. Compare the output byte-for-byte, run both in production (with the new code disabled but checked) before releasing. It was LLM-translated but done carefully.
Not sure it’s so simple. I think close to 100% of new ambitious projects are going to leverage AI at least to some degree. I know a couple that have strict no-AI policies (e.g. Zig), but it’s a tiny minority i think.
So how much AI usage does it make it an “AI rewrite”?
Dunno. I got rather the impression that it's ambitious single-developer projects with no intention of maintenance which leverage those 'AI' code generators the most.
Who wants to contribute to an unmaintainable code base?
I agree but I think from Bun we learned that a project with really good tests and enough tokens can be converted from one language to another quite good!
It is more and more the future. No human would want to rewrite one technology to another because it is too marginal a gain. AI on the other hand does not give a shit.
I dont think Opus 4.8 is an average coder, with my own experience (I have coded 20 + years before even llms existed) it is anything but average. I don't think training data alone determines the success of these models, there are lots of reinforncement learning principles and fine tuning takes place, a crappy code in the dataset doesnt hold those llms scoring high in benchmarks, I dont think an average programmer can score 70% (opus 4.8) in SWE Bench Pro, which is a good one.
I would say it's an average coder when it comes to writing functions because it keeps using regex. It might pass a benchmark but doesn't pass the smell test.
Well, it’s up to the user or post-trainer of the LLM what they believe to be above average. Then they can design around that.
In the case of real world LLMs and post-training, what is above average is defined roughly as: labeled good by expert humans, and scoring high on RL environments related to coding like debugging, passing tests, or running efficiently and verifiably correctly.
Is there any measurable difference in quality between the two, or are you just going on "vibes"? Is there a correlation between the quality of the manually written code and AI generated code driven by the same dev?
Such crude takes only cause unnecessary friction. If you have a black box that spits out code, and you are unable to distinguish the quality between a top tier dev and an AI inside the black box, then the distinction is unnecessary. Most of the code on the internet is already a black box to you. What percentage of code running on your machines have you vetted by who wrote it and code quality?
AI coding isn't going anywhere and will likely end up generating most code going forward so instead of rejecting it outright or arbitrarily categorizing it we need to focus on solid quantitative and qualitative measures of code and functionality regardless of who wrote it.
I have read up on it again, and while it was entirely dysfunctional at the very early stages, it quickly came up to par or beyond, with the LLM especially helped by the huge test suite written in Typescript, different from both Zig and Rust.
However, Jarred still describes a lot of unsafe, and usage of Miri in continuous integration.
Funnily enough, RAII is cited as a major benefit of rewriting from Zig to Rust, while C++ already has RAII. I wonder if C++ and Rust are more suited to larger programs than Zig, unless the architecture in Zig is handled carefully.
> Is there a correlation between the quality of the manually written code and AI generated code driven by the same dev?
If the dev doesn't vet the code, it doesn't matter how good quality a dev they would be if they wrote the code - they didn't. Sure, the dev would probably drive the initial architecture discussion better and some people are using AI in small batches with tests and vetting everything, but some previously great devs are throwing in PRs that touch hundreds of files at once with one commit.
A lot of people I previously considered great developers have become people I would not recommend for a job in the past 2-3 years.
> If you have a black box that spits out code, and you are unable to distinguish the quality between a top tier dev and an AI inside the black box, then the distinction is unnecessary.
Sure, but this is just begging the question. If nobody could tell, the term 'slop' wouldn't have become so popular.
You must be replying to a different comment. Seems completely unrelated to what I wrote. I never claimed that there wasn't AI slop. My point is that there are different levels of code coming out of AI, both due to the quality of the model and harness, and the quality of the engineer that is driving it. Thus you can't just bucket all AI developed code the same.
100% there is slop created by humans and really solid code bases generated by AI driven by a meticulous developer. You are making the exact error I was addressing, which is bucketing all AI code as the same.
I quote-replied to your comment, so I doubt it was unrelated.
> I never claimed that there wasn't AI slop
No, but you implied that a top tier dev doesn't produce slop when using AI.
> If you have a black box that spits out code, and you are unable to distinguish the quality between a top tier dev and an AI inside the black box
My point was that "if" is doing a lot of heavy lifting here and you're coming very close to begging the question.
> bucketing all AI code as the same.
Most people are not "top tier devs" and over time this will probably become more true. Even if I accepted your premise that "top tier devs" only generate solid code bases with AI, the ease of entry and the ease of spitting out thousands of lines of code means the ratio of bad AI to good AI will not go in a good direction unless it becomes too expensive for non "top tier devs" to use. Given this, I think it's fair to assume AI code is low quality until proven otherwise.
Yes most people are not top tier devs and most code is slop whether written by AI or not. I've probably dug through tens of thousands of code bases in my over 30 year career as a software engineer and most are slop.
I also did not claim that all "top tier devs" would always produce better code with AI, but the qualification for a "top tier dev" in this case would be someone who verifies code multiple ways to make sure it is correct. I've seen amazing code come from bad interns that was reviewed mercilessly by season devs, and there's absolutely no reason it would not be the same with AI generated code.
You do realize that you can review the entire architecture and code line for line even if it's AI generated right? My black box comment did not mean you couldn't see the code, it meant you don't know whether a machine wrote it or not.
You've dug through tens of thousands of code bases? 30 years would give you ~10,950 days, so you'd have to be digging into 2 code bases per day, every single day without any breaks for 30 years straight, to get to "tens of thousands".
When I read things like this it makes it very hard to give any credence to the rest of your pro-AI arguments, because it just seems incredibly likely that you're a bullshitter.
Yes, roughly. I try out open source projects as a hobby and a vocation. I've looked at dozens in a day sometimes. It doesn't take more than a few minutes to figure out if the code is slop.
> Is there a correlation between the quality of the manually written code and AI generated code driven by the same dev?
Aren't you making a strawman argument ? AFAIK this project is not made by an official PostgreSQL core developer, so the entire premise of your argument is invalid.
I phrased that improperly which made you and probably others misunderstand. What I meant is, is the quality of AI generated code correlated with the developer? The answer is yes, a bad dev will absolutely produce worse code using AI than a good developer - the point being that there isn't just one level of quality of code coming out of AI, even with the same model and harness.
I had a similar experience with Google Maps, I used to live in a place where the house on Google maps was located on the wrong street, like one parallel street off.
I put in a few requests from time to time because deliveries were a huge pain, to no avail.
I opened a thread on some Google forum or support place and then it was mentioned that I actually can't change that because only the city is allowed to... why I get the option in the app I don't fully understand.
At some point it got fixed but I have no idea why. Of course it was a few months before I moved out
> Contempt of court is a legal offense that occurs when an individual or organization interferes with the administration of justice or willfully disrespects a court's authority, dignity, or orders.
> In France at least, you cannot disagree with a judgement.
This feels like it can't possibly be true as written. Given that France has a court of appeals, that rather suggests that you can disagree with a judgement.
Your argument would also suggest that continuing to maintain your innocence after being found guilty would mean you're committing a further offence.
Not sure to what extent the ECJ is like this. It operates with a hybrid mix of inquisitorial and adversarial law.
Typically in adversarial systems you can disagree with the judge and jury's findings in public as long as you abide by them; the idea that the judge creates justice and cannot be criticised comes more from inquisitorial traditions, as I understand it.
Pretty sure this is wrong. Code pénal, art. 434-25, translated with deepl.
"Any attempt to publicly discredit a judicial act or decision—through actions, words, writings, or images of any kind—under circumstances likely to undermine the authority or independence of the judiciary is punishable by six months’ imprisonment and a fine of 7,500 euros.
The provisions of the preceding paragraph do not apply to technical comments or to acts, statements, writings, or images of any kind intended to seek the reversal, annulment, or review of a decision."
You are free to disagree with the ruling, but you cannot say that the trial is a parody of justice, the judge biased and the whole thing a conspiracy (cough cough Sarkozy)
Yeah I always disliked that there's this idea that you can't put a body on a GET request.
Iirc openapi generators goes out of its way to not support that which has lead to me writing a small rant into an API specification before to explain why the get_xyz uses POST...
