sidkshatriya

Presumably because the other features of OpenBSD bring in some benefits to OpenBSD fans. Also you can always develop on your OpenBSD desktop (with the Linux shim) and then deploy to the server without the Linux shim.

But yes you are correct, if you want to upgrade a Ubuntu distribution like 26.04 you do need to issue a command like `sudo apt dist-upgrade` which is admittedly an additional command. But then you could run 26.04 for many years. In OpenBSD anytime the base system/kernel is upgraded for a security fix or point release you need to do a slightly more complex dance.

The upgrade mechanism on a typical Linux distribution is _even more_ gloriously simple, and exactly the same as it has been for many years.

  # Fedora/RHEL
  $ sudo dnf upgrade -y

  # Debian/Ubuntu
  $ sudo apt update && sudo apt upgrade -y

  # Arch Linux
  $ sudo pacman -Syu

I'd rather my language surface problems at compile time (via type errors) for all possible code paths rather than a particular codepath at runtime.

That said, nothing prevents an LLM from controlling gdb/lldb either.

Also this is actually not such a big win: resuming the program after making the change aka hot reload is often a very hard problem even in highly dynamic languages like erlang and common lisp. What if the schema changes etc. ?

> To my knowledge Common Lisp is the only mainstream language that does all of this.

You should also mention racket, chicken scheme, guile scheme, MIT scheme, erlang/elixir, even Python via the repl and so on ...

> This is what makes macros possible. A macro is a function that takes your code and returns new code in its place, that means you can add new constructs to the language itself.

Macros + untyped code means the code cannot scale beyond a few thousand lines easily. Only a few programmers may understand the program fully and it’s often in their head rather than documented. Types implicitly document the code and allow hundreds of programmers to work on it. Lack of typing hinders code refactors too.

> Common Lisp is an ANSI standard and it hasn't been updated since 1994. I like this feature.

I like stable languages but not ossified languages. The internet was in its primitive infancy in 1994. This means Common Lisp may not be as web friendly as, say, golang without external libraries. Moreover, there has been a lot of progress in programming languages since 1994. OCaml/Haskell/Rust/Python/Ruby etc. incorporate some of that.

> But I don't think that's a problem anymore. Most programs today depend on millions of lines of code from packages that keep getting compromised. You don’t want that in yours. Also, with an LLM you could just write the part you need yourself or port the whole library — and LLMs seem to be really good at porting code.

You claimed earlier in the article that since Common Lisp was very concise you needed to spend fewer tokens via LLMs. But now that libraries for common tasks are not available you need to spend extra money on tokens to generate that functionality from scratch ! There goes your token budget !

Which is better ? A from-scratch LLM implementation of something with security holes or a library downloaded from the internet ? If you can restrict your dependencies to stable and popular packages from npm/cargo/pip you will probably be better off.

Spent too many hours reading these:

https://www.more-magic.net/posts/internals-gc.html

https://www.more-magic.net/posts/weak-references.html

(Not read yet but also looks amazing)

https://www.more-magic.net/posts/internals-data-representati...

"De Raadt says BSD could have become the world's most popular open source operating system, except that a lawsuit over BSD scared away developers, who went off to work on Linux and stayed there even after BSD was deemed legal."

There is some truth to that. And who knows where BSDs might have been if the lawsuit never happened.

However, I think Linux has always has and till today has better leadership, and management compared to OpenBSD.

I also think GPLv2 was another good that happened to Linux. It just creates an irresistible force to contribute back. With *BSD, a company might contribute back or it may not.

The real power required to support a human life in a developed country is a lot. Wattage for the human brain is definitely miniscule in comparison.

Whatever the Joules... (convert to $ using your preferred benchmark price) it is a fraction to what it might take a human Ph. D. weeks to feed and sustain themselves when working on the same problem. The economics on LLMs is just unbeatable (sadly) when compared to us humans.

This is a false dichotomy.

For years Golang was developed in the open but strictly moved on the vision of its creators rather than being "community-driven". Many other venerable open source projects don't involve the community in serious strategy discussions. The community mainly acts as a bug finder/fixer. Mojo could do the same: be open source but choose its own priorities internally.

I'm guessing that Mojo is still looking for a monetization strategy. Keeping important things proprietary in Mojo at this stage helps I'm sure (nothing wrong with that).

But I feel the era of proprietary programming language play is over. Unless you create some hardware (which the Mojo guys don't) it's going to be tough.

If you have too much emphasis on (invasive) analytics you might end up flying empty i.e. without customers.

You should be able to see what features are being used by seeing what server endpoints are being hit and how often. Don't need intrusive telemetry. Yes, it's not perfect. Many features could use the same endpoint. You could totally anonymise this and you could still get a great understanding what features users are using by looking at endpoint stats.

Companies need to decide whether they want customer goodwill or very detailed insight into what they are doing. By having invasive telemetry you may have less customers (people leaving for github competitors). Is it worth it ?

If something is "standard" nowadays does it mean it is the right way to go ?

One of my main issues is that this means your BIOS has to have a WiFi software stack in it, have a TLS stack in it etc. Basically millions of lines of extra code. Most of it in a blob never to be seen by more than a few engineers.

Though in another a way allowing BIOS to perform self updates is good because it doesn't matter if you've installed FreeBSD, OpenBSD, Linux, Windows, <any other os> you will be able to update your BIOS.

Call me traditional but I find it a bit scary for my BIOS to be connecting to WiFi and doing the downloading. Makes me wonder if the new BIOS blob would be secure i.e. did the BIOS connect over securely over https ? Did it check for the appropriate hash/signature etc. ? I would suppose all this is more difficult to do in the BIOS. I would expect better security if this was done in user space in the OS.

I'm much prefer if the OS did the actual downloading followed by the BIOS just doing the installation of the update.

No actually it's a joy to have no multithreading. It keeps the complexity budget lower. You can do multithreading through a custom PHP module if you had a very specific need. Maybe my requirements were too simple but I've never really felt the need. The shared nothing PHP architecture really helps you get away with this.

Anyways as the parent comment said:

> but if you're building microservices where parallelization is handled by an external orchestrator, then you can design around that pretty effectively.

See also https://wiki.php.net/rfc/php_license_update

The funny non-standard license of PHP has hurt it over the years. This is finally fixed !

But this approach may not work in other areas: e.g. building electric batteries, wireless modems, electric cars, solar cell technology, quantum computing etc.

Essentially Apple got lucky with AI but it needs to keep investing in cutting edge technology in the various broad areas it operates in and not let others get too far ahead !

Fair.

> old games that use bus locks

Yes the bus locks here are unintentional since LOCK on cache line is not sufficient, the CPU falls back to locking the bus.

- You have faulty software (e.g. games) that happen to have split locks

AND

- You have DISABLED split lock detection and "mitigation" which would have hugely penalised the thread in question (so the lock becomes painfully evident to that program and forced to be fixed).

AND

- You want to see which CPU does best in this scenario

In other words you just assume the CPU will take the bus lock penalty and continue WITHOUT culprit thread being actively throttled by the OS.

In the normal case, IIUC Linux should helpfully throttle the thread so the rest of the system is not affected by the bus lock. In this benchmark here the assumption is the thread will NOT be throttled by Linux via appropriate setting.

So to be honest I don't see the merit of this study. This study is essentially how fast is your interconnect so it can survive bad software that is allowed to run untrammelled.

On aarch64 the thread would simply be killed. It's possible to do the same on modern AMD / Intel also OR simply throttle the thread so that it does not cause problems via bus locks that affect other threads -- none of these are done in this benchmark.

Good:

- Small, comprehensible system

- Emphasis on simplicity

- Developers good about getting OpenBSD working on newer architectures e.g. Apple M1/M2

- pf

Bad:

- Very security forward but userspace and kernel almost exclusively in C

- Many security mitigations have questionable value but most certainly make the system a bit less flexible e.g. raw syscalls only via libc

- No journaled filesystem in 2026

- Still uses CVS in 2026

- System feels a bit slow and not yet fully tuned for multicore (improving gradually though)

- Community a bit insular and does not feel very welcoming (you may disagree)

TL;DR - I'm not a fan. Linux for maximum features and performance. FreeBSD when you want to use a BSD. Why FreeBSD ? See https://news.ycombinator.com/item?id=47322710

See my comment here: https://news.ycombinator.com/item?id=47704816

You can run Linux in a VM and PCI passthrough your WiFi Adapter. Linux drivers will be able to connect to your wifi card and you can then supply internet to FreeBSD.

Doing this manually is complicated but the whole process has been automated on FreeBSD by "Wifibox"

https://freebsdfoundation.org/our-work/journal/browser-based...

I tried it myself and it worked pretty well for a wifi card not supported by FreeBSD.

So, no need to get a new laptop :-)

Understanding the VT state machine and all its quirks and inconsistencies is not high up in my list of code I'd like to learn. It is good it is packaged up in a library and emacs is just a consumer of it.

libghostty will have excellent compatibility and features rather than an elisp implementation that maybe half baked.

I stopped living in the world of turtles all the way down. Now I'm more like, hey is this is good library ? Is it integrated well ? It does not matter if it is in zig, rust, c++, lisp, scheme, ...

Cool project... However, the terminal is where you enter passwords, ssh, set API keys etc. Something so sensitive should not be "Fully vibe coded".

For a project like this, I would expect to see a clarification which might read something like this: "Fully vibe coded, but I audited each and every line of generated code and I am already a domain expert in vt sequences and emacs so I know this program should be OK." But given that I did NOT see a clarification or statement like this, it becomes very difficult to trust a project like this.

Again, it is a cool idea.

Have you used bhyve ? What has your experience been with it ? Have you used KVM+QEMU -- can you compare your experience between both of them ?

It is not possible to come to a conclusion about everything in the world yourself "from scratch". No one has the time to try out everything themselves. Some filteration process needs to be applied to prevent wasting your finite time.

That is why you ask for recommendations of hotels, restaurants, travel destinations, good computer brands, software and so on from friends, relatives or other trusted parties/groups. This does not mean your don't form your opinions. You use the opinions of others as a sort of bootstrap or prior which you can always refine.

HN is actually the perfect place to ask for opinions. Someone just said bhyve does not support nested virtualization (useful input !). Someone else might chime in and say they have run bhyve for a long time and they trust it (and so on...)

So I can't agree with your viewpoint.

In the space of language design, everything "more powerful" is not necessary good. Sometimes less power is better because it leads to more optimisable code, less implementation complexity, less abstraction, better LSP support. TL;DR More flexibility and complexity is not always good.

Though I would also challenge the fact that Rust's metaprogramming model is "not powerful enough". I think it can be.

This is actually a good point. Yes, LLMs have saturated the conversation everywhere but contracts help clarify the pre-post conditions of methods well. I don't know how good the implementation in C++ will be but LLMs should be able to really exploit them well.

Not a very fair assumption. However, even if your not so friendly point was even true, I'd like people who have invented popular languages to "self-promote" more (here dlang). It is great to get comments on HN from people who have actually achieved something nice !