> Improving FreeBSD will make it easier to run BSD on non-apple hardware which will eat into their bottom line.
The number of people who want to run FreeBSD on their laptops probably numbers in the hundreds. Not exactly a threat to Apple's bottom line.
On the other hand, some of those people are FreeBSD developers who create and maintain code that Apple would like to have the option of using. That relationship is worth something to Apple.
>On the other hand, some of those people are FreeBSD developers who create and maintain code that Apple would like to have the option of using. That relationship is worth something to Apple.
It wasn't that long ago that we used to have to endure HN commenters spamming the same copypasta every time BSD was mentioned: "did you know BSD runs your playstation and netflix and <...>. You should donate money!"
Evidently it's not worth more than the cost of assigning engineers to this, otherwise Apple would already be doing it.
There's no GPL in the BSD sources used by Apple or Sony. They are free to release their operating systems as closed source; Sony does this. Apple releases Darwin sources "out of the goodness of their hearts", meaning, back in the 2000s they wanted to capture mindshare amongst the tech community for whom Linux was the strongest contender. Now that the future has refused to change, the year of the Linux desktop never materialized, and macOS has become the default developer's workstation OS, Apple has been much more sparing with Darwin source drops and may cease them altogether.
GPL where applicable. If it's MIT or just "as is" then no, they won't but they definitely publish the sources to what they are required to. Since FreeBSD is "as is" 4.4BSD licensed, they aren't required to publish the sources of Orbis.
> I'm curious why you think Apple making their hardware work with more operating systems does not benefit their bottom line.
Because they sell and advertise MacOS. Not "compatible with a wide range of OSes" (like say raspberry pis).
People buying a laptop due to goodwill and openness does happen (I bought my framework 13 due to that), but that's not a game Apple has played since Woz left - and for the worse, I think.
Apple's attitude towards other OSes running on their hardware is less "supportive" and more "barely tolerates". Also as a general rule Apple doesn't contribute much to open source outside of some high profile projects like Swift and Webkit.
MacOS was never based on BSD. Apple developed the USB drivers for BSP so they could copy it into their OS, but that very different from based on BSD. (It is likely some other parts are copied as well)
> MacOS was absolutely derived from BSD through NeXTSTEP.
The OS-X (now branded as "macOS") kernel was not, and is not, a derivative of the FreeBSD kernel, or any other BSD, even though macOS/OS-X has a FreeBSD kernel component due to its Mach heritage. The userland tools are however BSD. OS-X's kernel is XNU and from the XNU GitHub repo[0]:
XNU kernel is part of the Darwin operating system for use
in macOS and iOS operating systems. XNU is an acronym for X
is Not Unix. XNU is a hybrid kernel combining the Mach
kernel developed at Carnegie Mellon University with
components from FreeBSD and a C++ API for writing drivers
called IOKit. XNU runs on x86_64 and ARM64 for both single
processor and multi-processor configurations.
I recommend the book "Mac OS X Internals"[1] for a detailed analysis of same.
EDIT:
In theory, XNU could simultaneously run the existing FreeBSD subsystem alongside Linux and/or MS-Windows ones. In practice, this would be a herculean effort fraught with difficulty.
See QNX[2] for another example of a micro-kernel OS architecture.
>Darwin is based on proven technology from many sources. A large portion of this technology is derived from FreeBSD, a version of 4.4BSD that offers advanced networking, performance, security, and compatibility features. Other parts of the system software, such as Mach, are based on technology previously used in Apple’s MkLinux project, in OS X Server, and in technology acquired from NeXT.
>>Darwin is based on proven technology from many sources. A large portion of this technology is derived from FreeBSD, a version of 4.4BSD that offers advanced networking, performance, security, and compatibility features. Other parts of the system software, such as Mach, are based on technology previously used in Apple’s MkLinux project, in OS X Server, and in technology acquired from NeXT.
> Exactly.
Darwin != XNU
userland tools != Darwin
Also, Mach[0] was created by CMU 40 years ago and is not "based on technology previously used in Apple’s ..." no matter what Apple claims.
Since you quoted from the provided archive, so shall I.
The fundamental services and primitives of the OS X kernel
are based on Mach 3.0. Apple has modified and extended Mach
to better meet OS X functional and performance goals.[1]
Apple named the above "XNU". Since Mach[0] is a micro-kernel architecture, which FreeBSD is not and never has been, there must exist:
The BSD portion of the OS X kernel is derived primarily
from FreeBSD[2] ...
What I originally stated was:
The OS-X (now branded as "macOS") kernel was not, and is
not, a derivative of the FreeBSD kernel, or any other BSD,
even though macOS/OS-X has a FreeBSD kernel component due
to its Mach heritage.
In response to your assertion of:
MacOS was absolutely derived from BSD through NeXTSTEP.
Note my identification of the FreeBSD kernel component being a component, not the kernel itself.
I think you’re getting hung up on semantics and you’re hyper focused on the kernel.
Nothing you said contradicts my point and in fact, corroborates it. So I’m not sure what your point is.
Yes, Darwin is a mix of Mach, xnu, and BSD code. No where did I say macOS is the FreeBSD kernel. No where do I mention kernel. So while you argument for why I’m wrong is lengthy, it still says it was derived from BSD. Which is exactly what I said. There are parts of FreeBSD in macOS kernel. There are parts of XNU and Mach. There are parts OpenBSD and NetBSD. Majority of the base OS (including userland) is BSD.
The first version of MacOS X Server was based on an unreleased version of NEXTSTEP which in turn used 4.4BSD and Mach 2.5. Around BBB 1997-1998 a lot of userland was synced with bits from not just FreeBSD but the other BSD distributions, if my memory serves me correctly. MacOS X moved to Mach 3. That’s a very very long time ago though, and Apple obviously did a _lot_ of their own CoreOS engineering, things like launchd and XPC don’t have FreeBSD equivalents.
But hey, Darwin is open source so if someone wants to do go on a provenance archeological dig, it could be done!
That may be true but a large core of it is still BSD. In fact, it’s so BSD that one could create a BSD distro based off FreeBSD and achieve binary compatibility on x86. Which is exactly what RavynOS [0] has done. There’s a lot of BSD under the hood of macOS still today in Darwin. A mix of FreeBSD, NetBSD, and OpenBSD.
Any is a bit too strong. Apple has does (and still does) some useful work with clang/llvm, and a few other tools that BSDs use. However this is indirect at best.
Weird to see this downvoted, because it's totally true. Apple imports FreeBSD's userland periodically but not its kernel/drivers, and thus has nothing to do with how well FreeBSD works on PC hardware: https://wiki.freebsd.org/Myths#FreeBSD_is_Just_macOS_Without...
> Apple imports FreeBSD's userland periodically but not its kernel/drivers ...
OS-X/macOS runs an entirely different kernel called XNU[0][1], which is why userland tools can be imported whereas FreeBSD kernel and device driver code cannot.
I would expect if anyone even considered it, they’d immediately reject the idea, as they clearly believe that Apple retains ownership of the computers they “sell” and should control the software you could run on them.
HEIC is a container; HEIF is a container format. I don't know why images from my iPhone get saved with a HEIC extension... seems like it should be HEIF.
That said, when I move photos from my phone to by desktop via Signal; somewhere along the way it gets converted to JPEG so it's not a concern.
Any time law-makers claim that a law is meant to protect children you can guarantee that the safety of children had almost nothing to do with it. This is all a push to normalize digital ID (to protect the children!); once normalized it will become mandatory.
I always ask myself who wins with these laws (well, any law really). so far, the only winner seems to be the government and data collectors. It seems these laws are intended to collect leverage in the long run.
I'd argue that this is negligible for data collectors and governments. Governments already know who you are and what sites you vist for 99.99% of the population. Data collectors already know who you are and have a pretty good idea of the sites you vist.
What unique information is this going to give the government and data collectors to abuse? Lets establish one case that both affects average people and is "bad" and not waste time discussing things that only affect a tiny minority of privacy minded people.
Keep in mind the law states a platform must provide multiple ways to reasonably verify a user is older than 16. No mention of giving the specific user age or requiring govt id
I think the Cloudflare outage came down to a bad SQL query more than calling `.unwrap()` in production code... but a few less-than-ideal circumstances were revealed.
Yes, pretty basic looking mistakes that, from the outside, make many wonder how this got through. Though analyzing the post-mortem makes me think of the MV Dali crashing into the Francis Scott Key bridge in Baltimore: the whole thing started with a single loose wire which set off a cascading failure. CF's situation was similar in a few ways though finding a bad query (and .unwrap() in production code rather than test code) should have been a lot easier to spot.
Have any of the post-mortems addressed if any of the code that led to CloudFlare's outage was generated by AI?
> And CF doesn't have the "...or people will die" safety criticality.
I disagree with that. Just because you can't point to people falling off a bridge into the water doesn't mean that outages of the web at this scale will not lead to fatalities.
OTOH...whether you describe it as regulations, an SLA, or otherwise - "150,000 ton freighter destroys a major bridge and kills people" is a far worse violation of expected behavior than "lots of web sites went down".
I see where people use CF and I actually think that 'lots of websites went down' has the potential these days to in aggregate kill far more people than were killed by the Dali losing control over their helm. The Dali accident could also have been avoided by simply requiring ships with the gross tonnage to do damage to the bridge to have mandatory tugs, and I'm not so sure there is a clean and effective solution for the kind of issues that CF can create.
They're more like 'the shipping industry' than they are like 'a single out of control vessel'. Keep in mind that half of the health care industry or more uses CF to protect their assets.
The webserver was fast but PHP in the days before fast CGI didn't take all that much load to bring the server to its knees. And we didn't have cloud hosting at the time either so dynamic scaling behind a network load balancer wasn't a thing (and running multiple servers behind a reverse proxy was uncommon and expensive).
Based on metrics designed by Lockheed Martin? The Fat Amy[1] can be a good plane and clearly superior for certain tasks but unless Canada plans to be in a hot war where air power is paramount it would make more sense to get the Gripen and save a ton of money.
reply