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.
Ha! That’s some rose-colored-glasses view of BSD history.
The lawsuit didn’t help. But the BSD developers shot themselves in the foot when they refused to support x86, referring to it as a “toy”.
It wasn't until Linux came along and started eating up all of BSD's user base that they freaked out and decided x86 support might be a good idea. But by then it was too late.
I don't recall them refusing to support x86, but BSD development was mostly done by academics rewriting and improving AT&T UNIX, which was mostly on big iron systems of the time. They were focused on academic computer science work. The lawsuits stopped a lot of BSD work as the universities were sorting it all out. William and Lynne Jolitz start porting 4.3BSD to the Intel 80386 at Berkeley in 1989 (but the code wasn't released for years due to said lawsuit) before Linux existed. That is the first BSD-on-x86 work; by December 1990 they had contributed a working port to UCB. Most of the code didn't see the light of day until ~1992.
Also, usable and production ready BSDs were running large websites on x86 long before linux became mainstream and well-supported enough to be used. The BSD TCP/IP stack was the reference implementation for ages and BSD was heavily used in the internet's early days as a lot of early companies spun out of Californian universities. Hotmail ran on FreeBSD. Early SunOS variants were based off of BSD, as were some other commercial unixes.
The bigger killer, I think, is that BSD was (and still has) a bit of closed mindset to newcomers and were and are more conservative to new technology, despite some foundations of techbeing started with them. Docker's origins can be directly traced to FreeBSD jails. Sometimes the conservatism is warranted and a benefit (eg OpenSSH).
Was that ever verified? I know that detractors said that, but MS claimed that the copyright notice was only there to cover the utilities like ping.exe and finger.exe (which really were based on BSD).
I think the older NT source code is now available to read, isn't it? Going back and sorting out the truth of some of the claims from the 90s OS wars might actually be quite a fun research project...
I'm not sure if the NT IP stack was ever BSD, but many of the windows 3.11 and early 95 (before Microsoft natively added support) were from the BSD stack, or at the very least re-implemented the BSD socket API (Most famously Trumpet Winsock). This probably fed the rumours. IIRC winsock was also bundled as an "extras" in some pre-native IP supported versions of NT.
GhostBSD DragonflyBSD pf/opn sense even funky hybrid stuff like Chimera Linux, out of curiosity I had a quick search and the list goes on https://github.com/DiscoverBSD/awesome-bsd
Linux has a lot of corporate sponsorship and its own legal hurdles of the past (SCO le sigh.)
386BSD came out about the right time, but as noted, development was slow, and the original author abandoned it pretty quickly while at the same time Linux was actively gaining traction and growing rapidly.
Quotes below:
"No one else saw the 386 as interesting. Berkeley had a myopic attitude toward PCs. They were just toys. No one would support Intel." — Jordan Hubbard [1]
---
Jolitz's project, of course, found many people on the Net who didn't think it was just a toy. Once he put the source code on the Net, a bloom of enthusiasm spread through the universities and waystations of the world. People wanted to experiment with a high-grade OS and most could only afford relatively cheap hardware like the 386. Sure, places like Berkeley could get the government grant money and the big corporate donations, but 2,000-plus other schools were stuck waiting. Jolitz's version of 386BSD struck a chord.
While news traveled quickly to some corners, it didn't reach Finland. Network Release 2 came in June 1991, right around the same time that Linus Torvalds was poking around looking for a high-grade OS to use in experiments. Jolitz's 386BSD came out about six months later as Torvalds began to dig into creating the OS he would later call Linux. Soon afterward, Jolitz lost interest in the project and let it lie, but others came along. In fact, two groups called NetBSD and FreeBSD sprang up to carry the torch.
--- [2]
I heard about 386BSD long before I heard about Linux but I didn't have a 386, or for that matter an easy way to get it.
I did have a 286, but I also didn't have a way to get Minix.
And then round about the time that I got a 386SX-25 with a whopping 4MB of RAM, Linux 0.9 came around on a couple of floppies, and that was kind of that.
I don't know if I still even have that 386, a little small form factor Compaq Deskpro. I know I needed to add a bodge wire to repair a blown comm port at one point. I hope I still do have it, it's probably got some of my terrible early Unix programming on it!
It's hard to blame OpenBSD's management when there are three other BSDs. You didn't have to work with Theo de Raadt to work on BSD. But while the lawsuit may have been the catalyst, the game was really over when GNOME took off. BSD was sort of an equal target under KDE, but GNOME prioritized Linux pretty hard and had a lot of fans. At that point pretty much everyone making interesting desktop stuff went to Linux and never looked back. Which is not solely a license issue; you can definitely release GPL software for FreeBSD, but the "license war" culture (to the extent it really existed) may have been an issue.
And I guess I do think that FreeBSD had a saner organization pattern than the sort of haphazard ecosystem of projects that grew up around GNU and Linux. Maybe the chaos was necessary for growth, but it still seems to be a hurdle for new Linux users in the current day.
i think what the chaos did was enable more individual contributors. you didn't have to join the BSD team to get a core OS tool accepted into the system. anyone could just mix and match the tools and apps they liked. it's not that BSD prevented that but that they just didn't invite it. you can create your own spin of a distribution and if it gets enough users and contributors it gets accepted as an official version. there is even a debian variant using a BSD kernel. try making a official BSD spin using GNU coreutils.
> The development of Debian GNU/kFreeBSD has officially terminated as of July 2023 due to the lack of interest and volunteers. You may find the official announcement here[1]
> BSD was sort of an equal target under KDE, but GNOME prioritized Linux pretty hard and had a lot of fans.
oh boy its' much worse than that: KDE/GNOME were already largely precarious before that.
The whole Xorg thing was really dependant on gpu drivers and the story between linux gpu drivers and *bsd gpu drivers was so much different. Having the BSDs be fairly different didn't really help (eg: only FreeBSD had official nvidia drivers, albeit proprietary).
Gnome did take a lot of backlash and Gnome essentially became a meme at some point ("what's the use case for that?")
Gnome did take a strong dependency on systemd (both gnome and systemd are developed by Red Hat, btw).
And Gnome also did push a lot for wayland (that wasn't implemented on the various BSDs for a long time).
I haven't checked in a while, but I think Gnome is wayland-only nowadays ?
Ultimately, the real issue with KDE/GNOME and the BSDs is that the BSDs are largely irrelevant and essentially only relevant for some specific use-cases where desktop usage is not involved.
I never believe people when they say, we would have been famous if not for one piece of bad luck 35 years ago.
Yeah, i'm sure the lawsuit was crappy and set things back. But if you can't recover after 35 years, then its something deeper than what happened 35 years ago.
> "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.
Compute in science was already subsidized by public funding or by donations. Most supercomputers are financed this way. And that's a good thing. If you have a good science problem that can be computed, apply for compute time. There is nothing wrong to apply that to LLMs as well, like I wrote in my initial post. The human is still required to identity problems that are worth to be computed, to create prompts that the LLM can act on, and to verify results. But, OpenAI providing compute for basically free is still tied to a different incentive: to fuel the hype and to capture the market, while distorting/obfuscating the real costs. That's also the reason for why we cannot claim that 'economics on LLMs is just unbeatable'. It depends on the problem, the reason for a prompt.
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.
> 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 ?
> 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.
I have never seen a BIOS that didn't allow offline updates? However SSL is much less processing then a WPA2 WiFi stack, I would certainly expect this to be fully secure and boycot a manufacturer who failed. Conversely updating your BIOS without worrying if your OS is rooted is nice.
Isn't this pretty much standard in this day and age? HP for example also has this option in BIOS for their laptops (but you still can either download the BIOS blob manually in Linux or use the automatic updater in Windows if you want).
> 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'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.
I feel like I'm on a different planet when I see this kind of comment.
What if you need to call multiple external APIs at once with complex json? Sure you can call them one after another, but if each take (say) 2s to return (not uncommon IME), then you are in real trouble with only one thread - even if it is just for one "request".
I guess I'm spoilt in .NET with Task.WhenAll which makes it trivial to do this kind of stuff.
> What if you need to call multiple external APIs at once with complex json?
A few years ago, I had a PHP project that had grown by accretion from taking a single complex input and triggering 2-3 external endpoints to eventually making calls to about 15 sequentially. Processing a single submission went from taking 5-10 seconds to over five minutes.
This was readily solved by moving to ReactPHP (https://reactphp.org/), which implements async via event loops. I was able to reduce the 15 sequential external API calls to four sequential loops (which was the minimum number due to path dependencies in the sequence of operations). That reduced the five minutes back to an average of 20-30 seconds for the complete process.
It wasn't using true multithreading, but in a situation where most of the time was just waiting for responses from remote servers, an event loop solution is usually more than sufficient.
Yeah, though AFIAK these event loops still suffer from blocking on (eg) complex json parsing or anything CPU driven (where real multithreading shines).
But regardless I agree, I'm just saying that these kind of patterns _are_ needed in any moderately complex system, and taking the view that "it's great not to even have it" in the core framework is really strange to me. Esp given every machine I have these days has >10 CPU threads and it won't be long before 100+ is normal.
> Yeah, though AFIAK these event loops still suffer from blocking on (eg) complex json parsing or anything CPU driven (where real multithreading shines).
This is only a problem if the JSON parsing is being done inside the event loop itself. The idea here is that you'd have a separate JSON-parser service that the code in the event loop passes the JSON into, then continues executing the other operations in the loop while it awaits the response from the JSON parser.
Just translate anything you'd spawn a parallel thread for into something you'd pass to a separate endpoint -- that's what I was referring to when I said that the poor multithreading can be easily worked around if you're achieving parallelization by orchestration of microservices.
> No actually it's a joy to have no multithreading.
To build CPU-bound applications in PHP, you have to install a bunch of packages, rely on Redis, and try to approximate what Python or Go can do in a dozen lines of code. Can that really be enjoyable?
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 !
It works often enough for the company to be wildly successful. They can simply cut their losses and withdraw from industries where it hasn't, such as EVs.
Their focus is investing in areas where they see something being a competitive differentiator, or where the market has failed to create a competitive environment.
They do not make their own screens because they can source screens from multiple sources and work with those manufacturers to create screens with the properties they want. Same thing with them relying on others for electric batteries - there are plenty of manufacturers to provide batteries to Apple's spec.
They created their own wireless modems because there's only one company they were able to purchase modems from, and those modems did not necessarily have the features Apple wanted.
Apple hasn't announced any interest in selling electric cars, solar cell technology, or quantum computing platforms. I wouldn't expect them to do so until they had a consumer product ready for sale. I doubt they are planning to come out with products in any of these categories soon.
I think their M chips are a good example. They ran on intel for so long, then did the impossible of changing architecture on Mac, even without much transition pain.
Obviously that was built upon years of iPhone experience, but it shows they can lag behind, buy from other vendors, and still win when it becomes worth it to them.
How is changing the architecture of a platform that only you make hardware for doing the impossible?
They could change the architecture again tonight, and start releasing new machines with it. The users will adopt because there is literally no other choice.
Every machine they release will be fastest and most capable on the platform, because there is no other option
Exactly this! Rosetta + the whole app developer community who really quickly released builds for M chips (voluntary or forced, but it did happen).
I had the initial m1 air, and it was remarkable how useable it was. You'd expect all sorts of friction and issue but mostly things just worked (very fast). Even with some Rosetta overhead it was still fast compared to intel macs.
Rosetta 1 delivered 50-80% of the performance of native, during the PPC->Intel transition. It turns out, you can deliver not particularly impressive performance and still not ruin your app ecosystem, because developers have to either update to target your new platform, or leave your platform entirely.
You can also voluntarily cut off huge chunks of your own app ecosystem intentionally, by giving up 32bit support and requiring everything to be 64bit capable.
...because users have no other choice when only one vendor controls the both the hardware+software. They can either use the apps still available to them, or they can leave. And the cost of leaving for users is a lot higher.
Yes. Apple put custom hardware support in the M series chips based on the needs of Rosetta 2. The x86_64 performance on Rosetta 2 was often higher at launch than the prior generation of Intel chips running those same binaries natively.
Microsoft and Qualcomm already knew the performance of x86 app emulation on windows was killing the ARM machine lineup, so Qualcomm was working on extensions to their chips and Microsoft on having Windows support them already, but ARM64EC and Prism didn't launch for two years after the M1 shipped.
It's also notably not the first time they switched. They did the Motorola (I think MIPS?) Archictecure, then IBM PowerPC, then Intel x86 (for a single generation, then x86_64) and now Apple M-Series.
They do the things they think they can do very well.
Why would they try to build electric batteries, wireless modems, electric cars, solar cells, or quantum computers, if their R&D hadn't already determined that they would likely be able to do so Very Well?
It's not like any of those are really in their primary lines of business anyway.
They (Apple) bought out intel's wireless modems and are using them instead of Qualcomm's chips. IIRC, they aren't the best in class when it comes to raw throughput, but quite good in terms of throughput vs power consumption.
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.
> 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 allowed to run untrammelled.
It seems like a worthwhile study if you want to know what CPU to buy to play specific old games that use bus locks. Games that will never be fixed.
It seemed to me that the issue with the games was that they did split locks at all, and when Linux detected that and descheduled the process, performance was trash. I didn't think they were doing frequent split locks that resulted in bad performance by itself.
You don't need to be a careful shopper for this; just turn off detection while you're playing these games, or tune the punishment algorithm, or patch the game. Just because the developer won't doesn't mean you can't; there's plenty of 3rd party binary patches for games.
"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.