Not only in Europe, but in Canada too. Think of the union as a corpo offering bargaining and administrative services. Unions compete with each other for workforces. The typical case would be for a newly unionizing workforce needing to choose which union to join.
It is rare, but a workforce can even choose to move to a different union.
In countries where meta-strikes are legal, the unions cooperate on basic rights, and strike together when needed. Such coordination is explicitly illegal in the US, and has been since the '30s (IIRC).
It is usually like 2 or 3 and they will strike together. Having multiple keeps the unions in check and arguing for a pay raise for 60% of workers and nothing for 40%. I that case, the 40 would form their own union
The problem is really behavioural, not the tooling. People that do not understand, test and document their decision making in their PRs should not be submitting them, regardless of what tooling (AI or otherwise) they used to create them.
This problem existed before AI, but it is now just worse due to the spamming nature of these "contributors". It's another form of endless September where people unfamiliar with the norms of team software development are overwhelming existing project maintainers faster than maintainers can teach them the norms of behaviour.
In the end, some sort of gatekeeping mechanism is needed to avoid overwhelming maintainers, whether it's a reputation system, membership in an in-group, or something else.
If hammer companies were suddenly the most valuable international companies, and spent millions on ad campaigns and lobbying about trusting the hammer interface, then you can assume a large amount of people might trust the hammer interface
Even if your tool learns to talk and to make decisions, it's still a tool, not a person. You're the person and the one responsible for the decisions you make based on your tools.
Going back from the analogy, the problem is that we conflated software <engineers> with "coders".
A lot of people thought their job was to create code, we gave them a tool to generate a lot of code fast, and they truly think that "more code" = "more good"
Literally saw a video ad the other day which went like "I've always been cautious using Google's AI because it sometimes gets things wrong, but this time, it got it right!"
> I thought it had potential but I don't know how you'd fund it.
The same way we fund other social services here in Europe. If an individual is incapable of caring for themselves, the state is expected to care for them.
If I had a hammer robot that I told to go hammer some nails in a birdhouse and it goes "Sure, I'm on it!" then it nails a cat to the wall and says "Here's you new complete birdhouse, it's perfect in everyway and will make everyone jealous", then yes, that is a tooling issue.
That's not a good analogy then. What benefit is provided by a hammer that just tells the operator (who has eyes and can see) that there is a nail under it (and I assume to swing)?
If software engineering wants to progress past being an "art" and be considered an engineering discipline, then it should adopt methods and practices from engineering. First and foremost, one of the universal methodologies is analysis of root cause in faults, and redundancies to avoid that. e.g. the FAA has two pilots for planes, and each system is built in redundantly so if an engineer misses a bolt or rivet, the plane won't crash. intersections are designed such that there is a forcing function[0] on the behaviour of the motorists to prevent fault. Or, to take your tool analogy, nail guns are designed to be pressed against something with a decent amount of pressure before you can fire them.
All of these systems are designed around the core idea of "a human acting irrationally or improperly is not at fault" and, furthermore, that a human can have a bad day and still avoid a mistake. They all steer someone around a possible fault. Hell, the reason why we divide the road into lanes is itself a forcing function to avoid traffic collisions!
So, where is the forcing function in large language models? What part of a large language model prevents gross misuse by laymen?
I can think of examples here and there, maybe. OpenAI had to add guard rails to stop people from poisoning themselves with botulism and boron, etc. But the problem here is that the LLM is probabilistic, so there's really no guarantee that those guard rails will hold. I seem to remember there being a paper from a few months back, posted here, that show AI guardrails cannot be proven to work consistently. In that context, LLMs cannot be considered "safe" or "reliable" enough for use. Eddie Burback has a very, very good video showing an absolute worst case result of this[1], that was posted here last year. Even then, off the top of my head Angela Collier has a really, really good video demonstrating that there's an absolute plethora of people who have succumbed, in large ways or small, to the bullshit AI can spew[2].
I feel like if most developers were actually serious about being an engineering discipline, like we claim, then we wouldn't have all jumped on the LLM bandwagon until they'd been properly tested and had a certain level of reliability. Instead there are a sizable chunk of people saying they've stopped coding by hand entirely, and aren't even reviewing the code! i.e. They've thrown out a forcing function that existed to prevent errorenous PRs being committed! And for some bizzare reason, after about 2 decades of people talking about type safety and how we need formal verification to reduce error, everyone seems to be throwing "reduction of error" out the window!
> I feel like if most developers were actually serious about being an engineering discipline, like we claim, then we wouldn't have all jumped on the LLM bandwagon until they'd been properly tested and had a certain level of reliability
Development can’t be a “serious” engineering discipline because the economics of tech companies doesn’t allow for it. But this has a lot less to do about developers, and significantly more to do with the severe pressure company executives are putting on everyone to use AI, no matter what.
But let’s be honest, many companies have adopted things like root cause analysis and blameless postmortems to deal with infrastructure reliability and reducing incidents. Making systems resilient to human mistakes, making it impossible for the typo to blow up a database, etc. are considered best practices at most places I’ve worked. On the product side, I think it’s absolutely normal to make it hard for a user to take an action that would seriously mess up their account.
The core problem happens when your product idea (say, social media) has vast negative externalities which the company isn’t forced to deal with economically. Whereas in other engineering disciplines, many things are actually safety related and you could get sued over. I’m imagining pretty much anything a structural engineer or electrical engineer works on could seriously hurt or kill someone if a bad enough mistake was made.
That just doesn’t apply to software. There is a lot of “life & death” software, but it’s more niche. The reality is that 90% of what the tech industry works on is not capable of physically harming humans, and it’s not really possible to sue over the potential negative consequences of… a dev tooling startup? It’s a very, very different industry than those other engineering disciplines work in.
But, software engineering has actually been extremely successful at minimizing risk from software defects. The most likely worst software level mistake I could make could… crash my own program. It likely wouldn’t even crash the operating system since it’s isolated. That lack of trust in what other people might do is codified everywhere in software. On an iPhone, I’m downloading apps edited by tens of thousands of other engineers, at essentially no risk to myself at all.
When their precision mismatches their accuracy (or your expectations as driven by their design), just like with any other metrology tool.
Now you might say: "but the datasheet will give you the tolerances, and the manual will tell you to mind it!"
And yes, that's true. Just like how LLM providers also do: they tell you that outputs may be arbitrarily wrong, and that you should always check for mistakes.
Is this bullshit? Yes. So are metrology tools that have a mismatching precision and accuracy, need calibration, and have designs that fail to make you mind either of these, sending you to reading duty instead. Which just so happens to be a whole lot of them.
It is also absolutely not bullshit of course, because it is a fundamental limitation, just like those properties are for metrology devices. LLMs produce arbitrary natural language. Short of becoming able to perfectly read and predict the users' mind, they'll never be able to make any hard assurances, ever.
Defective devices also exist, and so do incorrect / incomplete documentation.
If investors invest heavily in lemon juice, then go around hyping it and selling it with the promise it makes you invisible to cameras (which it doesn't), it doesn't matter how stupid and gullible the rubes who fall for that are, the investors bear the responsibility for giving them that idea, when people start attempting to rob banks with lemon juice on their faces.
Hype is bad. Unwarranted hype is worse. Enabling people who can't do a thing to do what they think the thing is, but isn't, because they don't know any better, is inflicting a pox upon the world.
Why do you think this analogy is even remotely correct? It’s well-known that LLMs produce non-deterministic results. It’s also well-known that they hallucinate. To make it even clearer, all the top LLM players make sure to remind everyone of that behavior. If calculators had similar effects and warnings, it would have been a valid analogy. Instead, you're comparing apples and oranges.
I think it's a valid analogy in some contexts. Like when talking to a person that is not aware of non-determinism and hallucinations. Which happens on this website very frequently.
Many people here tell you to use AI like you use a calculator. With minimal or no oversight, with full access to production systems, etc.
To let a non deterministic tool communicate on your behalf, or give it access to critical systems is evidence enough that a good number of people are not aware of these facts.
Isn't part of the problem that these tools are advertised as allowing non-coders to code? How are you gonna recognise that the code is wrong when you don't know how to code and the product is telling you that you don't even need to?
Technical analysis tells you that a stock is in its upwards trend. You invest all your money on it without thinking twice. The price goes down and you lose thousands of dollars. Is it a tool problem?
LLMs spit out a sequence of tokens that is the most probable continuation of the input. LLMs don't lie any more than technical analysis does when it predicts the most likely trend of stock prices. It's up to you how to use this information.
The tooling shouldn't be more clever than the user, otherwise the user is incredibly gullible. IMO the problem is that AI is filling an psychological need, not an intellectual one.
You wouldn't hold that opinion it you did maintain a popular open-source repo or interact with AI "PR review" tools at a serious level. Even the most SOTA models are willing to accept/merge absolutely trash PRs so long at the summitter can convince it that is addressed it's review comments.
In my mind, the Baochip-1x’s key differentiating feature is the inclusion of a Memory Management Unit (MMU). No other microcontroller in this performance/integration class has this feature, to the best of my knowledge. For those not versed in OS-nerd speak, the MMU is what sets the software that runs on your phone or desktop apart from the software that runs in your toaster oven. It facilitates secure, loadable apps by sticking every application in its own virtual memory space.
Baochip is a license-free RISCV implementation with MMU. It is custom CPU logic hitchhiked on another company's SOC. The SOC is dual CPU like the rp2340, but with the other CPU fused off.
Xous is a an operating system that runs on the Baochip and an FPGA version of it.
Precursor is a prototype mobile hardware secrets device. It has an FPGA that runs Xous and costs around $600. One of the core goals of the project is to make inspectable hardware.
This baochip is the next step is to make prototype devices cheaper by running xous on the baochip instead of FPGA. The baochip is inspectable using a technique called IRIS.
Almost. SoC is a 1+4 design, with a vexriscv main core (350MHz), and 4 tiny "Baochip IO" PicoRV cores (700MHz) (somewhat akin to the ultra-puny Programmable IO/PIO cores on rp2350). The crowdsupply for this board just opened. For on vexriscv, which has been around: https://hn.algolia.com/?q=vexrisc
This is an embedded chip, not a full on application core like an arm cortex A78. No GPU, 2mb+256k onboard ram + psram external. But like a rp2350 there are graphics drivers. It has a ridiculously fast for its class internal execute-in-place flash. A rather featureful MMU for a device of its small size, to support it's rust based borrow-checked memory OS. Tons of security & encryption features such as sha256/512, blake2/3, ECC ram, TRNG, etc. 22nm doesn't sound impressive by modern standards but is pretty good for a small embedded chip; rp2350 is 40nm.
The BIO is going to be ridiculous. Fully cross barred to output and just ridiculously fast.
I want Oxide to start an RFD for evaluate changing their base processor to this ("Gimlet"). Much higher security than anything else available. Switching off Hubris is probably a non-starter, it probably lacks some nice/necessary peripherals, and major supply chain risk, but also, an incredible open source chip you could go deeper on.
I don't think so, because the Baochip is just the chip itself. Cases are more likely to be implemented as part of the application products, not the chip. The chip itself would never come with a case.
I am not interested in nominal new highs.
reply