nanolith

Pragmatic in that it balances the pro- and anti- LLM sentiments. There are plenty of other valid reasons to take a hard stance against LLMs.

I don't use them for open source projects I maintain.

Regardless of how you feel about using LLMs or using products that are developed with LLMs, it is a good idea to have an ecosystem of open source projects with differing levels of LLM involvement, including pristine software written entirely by humans.

The pragmatic argument for hard no-LLM projects: if models are to be useful, they need good input. Hand-written software that has been carefully audited is free from the kinds of feedback errors that will eventually weaken LLM code generation. Otherwise, a bad pattern gets copied. In the next generation, this bad pattern is seen a bit more often as stochastic models converge on it and more open source code adopts it. This is reinforced in the next generation and it becomes a common pattern. Then, in the next generation, this pattern is seen all over. This could be inert "non-coding DNA" like weird naming conventions or pointless comments. Or, it could be bad edge cases that become commonly exploitable.

The best place to go for curated patches is here. You can customize these or roll your own once you have a chance to examine the source code. dwm is very simple.

https://dwm.suckless.org/

That should be the case, but you'd be surprised how many people just run stock dwm. I don't get it.

All of the "suckless" distributions beg to be patched.

By default, OpenBSD uses FFS / FFS2. There is an effort in place to port GeFS (from 9front) to OpenBSD. It's unlikely that ZFS will be ported to OpenBSD, due to licensing incompatibilities. For the same reason, btrfs is also unlikely. That's why I run FreeBSD on my big server, and OpenBSD on my laptop and other edge devices. I don't really have any issues running FFS on a laptop; it seems overkill to run anything more advanced than that.

I'd recommend taking a look on forums to see what other folks are running. If it's a modern Lenovo with integrated graphics or an AMD GPU, it will be supported before others. OpenBSD folks tend to use Lenovos. My best recommendation is to pick a laptop that a core maintainer is using, unless you feel comfortable making your own patches. They have AMD GPU support via DRM from Linux. Intel graphics typically works alright.

OpenBSD works well with relatively recent versions of Chromium and Firefox. That being said, they are on a six month release cycle. The Chromium port can fall behind if you stick to -stable or releases. Building Chromium or Firefox from source is... well, I have a 2012 laptop, so that's not something I am going to do. Regardless, you'd need to be pretty comfortable with applying OpenBSD specific patches to one of these browsers, which isn't always obvious, especially since they are moving targets.

If you're used to being on a rolling release Linux, this will be a bit disorienting. But, in my opinion, it's significantly more stable and better thought out.

I use a custom dwm.

Don't forget: doas syspatch. They tend to find some minor issues rather quickly after release.

Since I maintain my own custom patch set under OpenBSD, this is also usually when I need to vendor in the new release and update all of my patches.

I've used OpenBSD as a laptop daily driver for nearly 20 years. It's small. It remains mostly consistent between updates. In fact, it's so stable that I barely notice changes when I upgrade until I go hunting for them.

The Lenovo laptop I use as my travel laptop and console display is a 2012. It still runs OpenBSD just fine.

I'd say that it is actually fairly easy to poison oneself brewing different kinds of alcohols. It is a risky activity. So is driving. So is making fireworks. So is chemistry. So is making cheese, pickles, sauerkraut, and canned goods. People die of botulism every year because they don't follow basic safety procedures when canning, or they eat canned goods that someone else improperly prepared.

That doesn't mean that one shouldn't be allowed to do these things. It means that we should provide appropriate training and, in some jurisdictions, reasonable / non-discriminatory licensing for those who wish to do these things.

When it comes to distillation, the rules are pretty straight-forward:

Keep a log book. Use quality equipment. Measure temperatures. Learn to discard heads and tails. Use appropriate ventilation and fire safety protocols. Purchase qualitative test equipment to verify that the product does not contain harmful contaminants. Licensing is a great way to ensure that people know about these things and follow them. A blanket ban actually makes it more likely that people who violate this ban to distill alcohol will poison themselves or others.

Clandestine operations for most illicit substances tend to be quite dangerous. There are safe ways to distill alcohol, but given that one can't purchase quality distillation equipment in locations where it is illegal, folks often end up making their own.

I think it's perfectly acceptable if these is a reasonable and non-discriminatory licensing process, like for HAM radio or small game hunting, that covers safety. This doesn't eliminate the possibility of accidents, but it does reduce this possibility.

No. It is not likely that it will be possible to sell homemade liquor. But, it's this experimentation that will lead to more businesses.

Many microbreweries and small breweries started when home brewers went pro. They had recipes that were popular. They decided to go through the fundraising and investment in order to build appropriate facilities and get licensed.

It's this permission to experiment and play that has inspired many of the popular ales available today.

This would do to spirits what homebrewing has done to beer in this country. So many varieties were rediscovered and popularized when homebrewing and microbrewing were legalized during the Carter Administration.

Liquor has become consolidated among a half dozen global conglomerates. Varieties have been streamlined. Folks who are into making historical cocktails tend to hit roadblocks or make modern "almost" substitutions.

I'm in favor of this ban being struck down, even though I can't really take advantage of it. I brewed beer and wine when I was younger, but for health reasons, I can't drink alcohol anymore.

OpenBSD has a strict "no GPL" policy. It does not incorporate GPL code in the kernel, and it has slowly weeded out GPL code from userland. This is one reason why it builds with Clang instead of GCC.

If Linux DRM weren't licensed under more permissive terms, OpenBSD simply wouldn't permit its inclusion.

I saw the movie Friday night. It is a mind job. You'll walk away with more questions than answers.

Without spoiling the movie, it's possible for people to be multiple things at once. That doesn't excuse what Elizabeth Holmes did or explain what others in her circle may be guilty of. The movie is a wild ride.

I'm not missing your point. I'm pointing out that it's an appeal to extremes that doesn't stand up to scrutiny.

Why insulin? Why not have the robot deliver premature babies from a regional hospital to a central hospital, on a battery powered NICU that only has 30 minutes of battery power?

The argument is unlikely.

I'd say that this would bring up a bigger issue: why would Uber Eats be in the business of using robot couriers to deliver vital medications? Sandwiches or non-essential goods? Sure, I can understand this maybe, bracketing societal issues that these machines represent.

Prescription medications are controlled. If this robot is damaged or destroyed, the patient may not get their insulin at all without further authorization from their doctor or their insurance company. Those logistical issues are much thornier than a retired professor blocking a delivery robot.

This is why I've made it a point with my compilers to always include a minimum subset bootstrap compiler written in C, which can compile the compiler to C via transpilation. The only dependencies are a C compiler toolchain and a POSIX compatible libc.

This does make the compiler slightly more annoying to extend, but that makes bootstrapping support for a new system easier. User experience is important.

I have no doubt that SF has its ups and downs. My comment was based on my subjective experience. I'm sure we've all seen the Hollywood accounts of SF in the Dirty Harry movies. It was once bad enough to get such an impression.

I was just sad to see SF in a bust, because I genuinely enjoyed it in 2011. I can only hope that this slump resolves and that the folks who are down and out on the streets get the help they need.

I actually love SF and would love to visit again.

That's based on actually working in these cities and interacting with people. I don't watch Fox News.

I had a contract with a company in the SF Bay Area back in 2011-2012. I spent 50% of my time in the Bay Area, despite living in Florida. I often stayed in a San Francisco hotel and walked to a commuter bus that would take me to corporate headquarters.

I visited SF on other occasions in 2015 and 2022. The contrast between 2011 and these dates was staggering. In 2011, I did not have to step around human feces in the street. There was and is always a significant presence of homeless people -- who don't bother me -- but at least back then, I felt pretty confident walking at night through any part of the city, even the Tenderloin. In 2015? It was pretty bleak. Crime was up, and folks were much more aggressive. In 2022, I had my head on a swivel. I'm used to significantly more, uhh, vigorous urban areas, and SF started pinging my situational awareness in 2022 like it didn't eleven years earlier.

Don't get me wrong: SF is a kitten compared to Chicago, Detroit, or Baltimore. But, it's sad that it has descended so far. It is still a charming city that I'd love to visit again, but some of that charm has been lost.

This risk factor is similar to one I brought up during architectural review of an IoT company I helped to build. It's why the identity certificates our devices used were entirely disconnected from domain names, and why the discovery protocol I put together did not rely on registered domains, but could use these as an untrusted part of discovery.

Domain names are leased. Things that are leased can disappear. The company leasing these assets could go bankrupt. They could weasel their way out of agreements as Verisign has done here. Any identity that is grounded in leased assets is built on shaky ground. It's also why I'm dubious of the way that e-mail addresses have become tied to online identity.

I'm not saying that what Verisign has done is right, but this behavior is expected. Those of us who went through the (dot) bomb era remember just how shaky this infrastructure can be.

I'm sorry that .name people are going through this. Even though it's a risk I expected, that doesn't make this okay.

The difference is that Rust and Java can only verify certain properties. I can build model checks to verify any property that I can discharge with an SMT solver, which is significantly more powerful. For instance, I can build function contracts that verify that if a function succeeds, it performs certain actions, and if it fails, it does not. I can verify that a function properly manages external resources, performs authorization checks, or always follows data structure invariants.

I don't need to build full formal specifications to do this. I can verify just the subset that is important. I can do more than what Rust or Java provides. I can add more rules that must be followed, or in cases where it doesn't matter, I can relax specific rules without reaching for clumsy annotations like "unsafe", or using an FFI.

I think that reading and reviewing software is responsible.

Source code exists for humans to read first, and for computers to read second. Programming languages are unambiguous, and most languages take well to abstraction. Software can be written at a level that is appropriate for human review. Boilerplate can be avoided. It's well written when it is easy for stake holders to understand directly, without translation and without an LLM to summarize it.

Software should be the output artifact of the process, because it exactly describes the behavior of the system. The formal specification explains how the software embodiment must work, and in constructive proofs, it's even possible to extract the software embodiment from this specification. But, from a practical perspective, this is too time consuming. Instead, specification should be written to explain the rules that software must follow, instead of the exact behavior. In this case, the source code is still an important artifact, and it should be reviewed and improved upon as part of the process.

This article comes close to making a fallacious argument about formal methods, which is that formal methods aren't useful unless you can exactly specify how something works.

I use model checking (a form of formal methods) daily. I separate the process into three domains: things that must be fully specified, things that can be fully specified, and things that, with the appropriate mitigation, need only have certain properties verified. Most software fits just fine in the latter category. Spend your time on fully verifying process isolation, cryptography, certain core runtime functions / behaviors, and logic relating to authentication and authorization. Everything else can be partially verified, which is much easier. Verify termination, no UB, memory safety, and that function contracts, data structure invariants, and API boundaries are followed.

A PDF implementation, a web browser, or a random server application fits cleanly into this decomposition. It matters little if the PDF is rendered oddly, or if the web browser can't interpret a page. But, it matters greatly if these errors could result in a vulnerability that could be exploited, or to a lesser extent, if these errors resulted in the software crashing.

Pure formal methods is academic. Apply engineering to this, and you get a real world and practical framework for making software safer.

If you had enough money to convince AMD to sell you the tapeout, and if you could hire a fab using a similar process, you could make a new CPU. Other than that... probably not.

The next best thing would be buying a replacement.

Security researchers do face legal harassment all of the time. They may not be charged with or convicted of felonies, but it is a game that they need a lawyer to navigate all the same. In a just world, the kind of weaponized incompetence that these frontier model builders are definitely guilty of should be felonies of their own.

Building a system that is meant to chain attacks and placing it in insufficient containment -- when any reasonable engineer could point to this containment and show how it is insufficient, both before the act and after -- shows that they were operating a dangerous system without either the knowledge nor the safeguards required to keep it from harming others. Instead, they are allowed to treat their own incompetence as evidence of advanced and existential "cyberthreats".

But, it's pretty clear based on how they one-up each other on these attacks that they are engaging in regulatory theater. Their behavior generates headlines, stirs up fear in the public, and then their lobbyists march on Capitol Hill demanding regulation now. Regulation that conveniently favors them at the expense of any competition. They are trying to use rent seeking as a way to stymie competition and pull up the ladders behind them. It's not just malicious. If it can be proven, it's collusion: antitrust dressed up as public policy.

Personally, I see these language fights as being a bit pointless. They are trying to optimize at the wrong layer. Unless one is working with a dependently typed language, which requires a proof assistant to discharge type checks, then it's all just a question of where you make the trade-off. Don't care about memory leaks or deadlocks as part of your soundness guarantees, but can't have GC? Use Rust. Okay with runtime overhead to verify checks? Consider fil extensions.

If you want to go deeper, skip the language wars entirely. Tooling does what these languages can't do. I have had great success model checking C with CBMC. Not only does this prevent memory safety issues (including memory leaks), but this also prevents deadlocks. Bonus: you can write user contracts and invariants to verify that every execution path of a function fulfills these contracts and invariants.

Kani comes close with Rust. It doesn't yet have decent concurrency support, but there is nothing that prevents this from being added in the future. The ability to write custom contracts and enforce custom invariants more than makes up for its lack of concurrency support. Similar technology could be used or adapted for Zig or C++.

Use whichever language you like. Just, please look into model checking it. The technology scales just fine, once you get over the learning curve and learn how to use compositional verification.

There are plenty of open core alternatives that replicate the architecture and ISA. Many of these are cycle accurate. Some have been tape-out proven. Hobbyist retro-computing enthusiasts who wish to build a Z80 system still have options even once new old stock and recovered CPUs become scarce.

How am I only now seeing that Nedry's SGI monitor had a picture of J. Robert Oppenheimer on it with a scrawled message, "Beginning of Baby Boom"?

What an oddly specific Easter egg.

Wait... wasn't it already understood that relativity influences electron orbits of heavy elements? I clearly remember being taught some of this in physics, in the mid-noughties.

For instance, we know that gold gets its color from relativistic effects.

https://physics.aps.org/articles/v10/s3