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.
> ...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.
Will this strategy work every time ? Maybe for AI it will work (market is competitive and Apple just purchases the best model for its consumers).
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 !
This article seems relevant to me for the following scenario:
- 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.
> I would get a new laptop because a laptop without WiFi is useless.
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"
I am partial to your sentiment but I don't think writing all the terminal handling code in elisp gives us code that might be too interesting to read (to me at least).
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, ...
> Status: Early prototype. Fully vibe coded. [...]
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.
Ok you have a problem with the way I framed my questions and my (unintentional) tonality. Fair enough. Let's move from critique of the way I asked my questions to what your experience with bhyve has been, if you're willing to share that.
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 ?
"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.