sidkshatriya

I think the OP was asking the honest question: why not use Linux if the graphics stack is from Linux anyways. It's a fair question and I ask that myself.

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.

For a rolling release like Arch Linux you just always use pacman -Syu.

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 from 7.9 to 8.0 is still gloriously simple, and exactly the same as it has been for many years

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

The false distinction between the OS packages and user local (/usr/local) packages during upgrade causes much unneeded complexity. FreeBSD is making this go away which is welcome.

> You can just point your LLM at the debugger, and it’ll make its fix and resume the program.

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.

Thanks for sharing the forbes link. From the link:

"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.

Yes I agree and this is what I meant. The cost of electricity, petroleum, transportation, the cost of goods brought in from around the world to feed and clothe the human and so on.

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.

> "After 16 minutes and 41 seconds, it came back" ... "further 47 minutes and 39 seconds" ... "After 13 minutes and 33 seconds" ... "After 9 minutes and 12 seconds" ... "After 31 minutes and 40 seconds" ... plus other computations Anyone spotting the issue here? What did that really cost?

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.

> but the language is still very young and we believe a tight-knit group of engineers with a common vision moves faster than a community-driven effort.

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 dont have analytics you are flying blind

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

> ...our team needs visibility into how features are being used in practice. We use this data to prioritize our work and evaluate whether features are meeting real user needs.

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 ?

> Isn't this pretty much standard in this day and age?

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.

> It seems that things wouldn't work without a BIOS update: PyTorch was unable to find the GPU. This was easily done on the BIOS settings: it was able to connect to my Wifi network and download it automatically.

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.

> It's true that the lack of multithreading in PHP has been a persistent pain.

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.