While I was disappointed that NetApp sued, the ZFS team literally referenced NetApp and WAFL multiple times in their presenations IIRC. They were kind of begging to be sued.
No, the ZFS team did not "literally reference NetApp and WAFL" in their presentations and no, Sun did not "start it" -- NetApp initiated the litigation (though Sun absolutely countersued), and NetApp were well on their way to losing not only their case but also their WAFL patents when Oracle acquired Sun. Despite having inherited a winning case, Oracle chose to allow the suit to be dismissed[0]; terms of the settlement were undisclosed.
Your own link states that Sun approached NetApp about patents 18 months prior to the lawsuit being filed (to be clear that was Storagetek before Sun acquired them):
>The suit was filed in September 2007, in Texas, three years ago, but the spat between the two started 18 months before that, according to NetApp, when Sun's lawyers contacted NetApp saying its products violated Sun patents, and requesting licensing agreements and royalties for the technologies concerned.
And there was a copy of the original email from the lawyer which I sadly did not save a copy of, as referenced here:
As for the presentation, I can't find it at the moment but will keep looking because I do remember it. That being said, a blog post from Val at the time specifically mentions NetApp, WAFL, how the team thought it was cool and decided to build your own:
And the original paper on ZFS that appears to have been scrubbed from the internet mentions WAFL repeatedly (and you were a co-author so I'm not sure why you're saying you didn't reference NetApp or WAFL):
>The file system that has come closest to our design
principles, other than ZFS itself,is WAFL[8],the file
system used internally by Network Appliance’s NFS server
appliances.
> The file system that has come closest to our design principles, other than ZFS itself,is WAFL[8],the file system used internally by Network Appliance’s NFS server appliances.
That was unnecessary, but that does not betray even the slightest risk of violating NetApp's patents. It just brings attention.
Also, it's not true! The BSD 4.4 log-structured filesystem is such a close analog to ZFS that I think it's clear that it "has come closest to our design principles". I guess Bonwick et. al. were not really aware of LFS. Sad.
LFS had:
- "write anywhere"
- "inode file"
- copy on write
LFS did not have:
- checksumming
- snapshots and cloning
- volume management
And the free space management story on LFS was incomplete.
So ZFS can be seen as adding to LFS these things:
- checksumming
- birth transaction IDs
- snapshots, cloning, and later dedup
- proper free space management
- volume management, vdevs, raidz
I'm not familiar enough with WAFL to say how much overlap there is with WAFL, but I know that LFS long predates WAFL and ZFS. LFS was prior art! Plus there was lots of literature on copy-on-write b-trees and such in the 80s, so there was lots of prior art in that space.
Even content-addressed storage (CAS) (which ZFS isn't quite) had prior art.
Seems specious. Patents don't preclude one from overtly trying to compete; they protect specific mechanisms. In this case either ZFS didn't use the same mechanisms or the mechanisms themselves were found to have prior art.
Whether the claims were valid or not I guess we'll never know given Oracle and NetApp decided to settle.
What I DO knows is that if the non-infringement were as open and shut as you and Bryan are suggesting, Apple probably wouldn't have scrapped years of effort and likely millions in R&D for no reason. It's not like they couldn't afford some lawyers to defend a frivelous lawsuit...
Maybe! Bryan and I were pretty close to the case and to the implementation of ZFS. But maybe Apple did detect some smoking gun of which somehow we were unaware. I (still) think Jonathan’s preannouncement was the catalyst for Apple changing direction.
There was lots of prior art from the 80s for "write anywhere", which is a generally a consequence of copy-on-write on-disk formats. The write-anywhere thing is not really what's interesting, but, rather, not having to commit to some number of inodes at newfs time. Sun talking about NetApp makes sense given that they were the competition.
We don't know exactly what happened with Apple and Sun, but there were lots of indicia that Apple wanted indemnification and Sun was unwilling to go there. Why Apple really insisted on that, I don't know -- I think they should have been able to do the prior art search and know that NetApp probably wouldn't win their lawsuits, but hey, lawsuits are a somewhat random function and I guess Apple didn't want NetApp holding them by the short ones. DTrace they could remove, but removing ZFS once they were reliant on it would be much much harder.
>2) all the other US manufacturers treated electric as a premium product, resulting in the overpowered electric Hummer 2 and F-150 pickups with high price tags
They had to in order to build the manufacturing capacity without literally bankrupting themselves. As GM has shown, once they had the expertise and manufacturing capabilities, they could quickly move downmarket. By all accounts GM's entry into the space has been a raging success, moving downmarket with the Equinox being available for as low as $27,500.
They obviously aren't to Tesla level sales numbers yet, but they're growing rapidly and I would not count them out of the fight.
> A decade replacement cycle for network-connected computing devices is not crazy.
Sure it is, and it’s why we desperately need consumer protection laws mandating lifetime security updates for IOT devices.
My grandparents had a 100 year old home - some of their light switches were well over 30 years old. Why should I be forced to replace a smart light switch before its useful life is over? Because some company wanted built in obsolescence so they could sell more product?
Edit: and to be clear, I’m potentially fine if the vendor takes the approach of open sourcing all firmware as a way to allow lifetime updates if they need to get out of the product for some reason and can’t maintain it themselves. “Reasonable accommodation”?
You’re missing the point. Enterprise customers where they would presumably see the bulk of their profits is what they’re losing to wasabi. Commercial “unlimited backups” is not a wildly profitable business which is why basically every other competitor in the space either failed or intentionally exited the market segment.
>heavily protected and faces virtually no competition
Huh? Out of the top 25 vehicles sold in the US in 2024, 16 of them are non-US automakers. Just because the US is actively blocking China from dumping heavily subsidized vehicles into the north american market, doesn't mean they "face no competition". Kia and Hyundai alone show that it's VERY possible to break into the US market if you have even a little bit of interest playing fair.
The only real way to break into the US market is to have factories in the US. Trucks in particular are protected by the notorious 25% "chicken tax", which has been in place since the 1960s.
> they're trying to retain some semblance of manufacturing in the US, which I'm fully in support of.
>
> Both because those are well-paying jobs and because it's a matter of national security.
Why should manufacturing jobs be well-paying? Human productivity has not kept up with business improvements at all. A contemporary robot can assemble car modules much faster than a robot from, say, the 60s. A human now works at the same speed as a human from the 60s.
I don't think this is true. Yes robot capabilities have increased but those business processes also make people more productive. I recently toured the F-150 assembly line and it is clear a lot has been done to improve worker productivity.
"Manufacturing jobs" doesn't mean doing the same job as in the 60s. Human productivity improves by offloading more to machines/tools/processes while having the humans manage other things. A human making cars now is not moving their limbs twice as fast as humans in the 60s, they're using tools that get the job done 3x faster than the person in the 60s. The jobs are actually quite different across time, but we colloquially call both "manufacturing jobs".
> They aren't protecting US automakers, they're trying to retain some semblance of manufacturing in the US, which I'm fully in support of.
"The US can't make anything" is an absurd delusion. We are the second most productive economy in the world.
> Both because those are well-paying jobs and because it's a matter of national security.
We are fully capable of meeting our defense needs already. If you really care about reinforcing our military-industrial capability the best way to do it is to arm Ukraine.
>Noooooooooo! No apps, please! Finally a car not tethered to and dependent on your phone, and we already have our first request to app-ify it!
What car is tied to your phone? A mustang mach-e, for instance, does not require your phone at all. It has a FOB for opening the doors and starting it, you can program the charging times from the in-car screen.
The app is optional, exactly as it should be. This car DESPERATELY is going to need an app when it comes to charging whether you know it or not. With no in-car screen you'll have absolutely no way to control charging which WILL come back to bite you.
>Yes to a simple battery system!
"simple" in this case will add cost. Nearly every EV has the battery as a part of the structural frame of the vehicle for a reason (there are some niche exceptions in China). Nothing is impossible, but I don't see them making the battery easily swappable, while also being structurally sound, and keeping the low price point.
In addition to the sibling comment, you want to be able to check if the vehicle is charging and everything is fine remotely. EVs randomly stopping charging for various reasons is not rare at all. You want to get a notification.
You want to know when the vehicle finishes charging so you can vacate the public charger.
You want to be able to reduce the current when the charging is tripping breakers wherever you are.
Again, why do you consider those things as better done via a smartphone and an app, versus using the already built-in screen (the one behind the wheel)?
Pretty much every fortune 500 that's been around for more than 30 years. Batch processing primarily - from closing their books to order processing, differs by company. But if you ask the right person, they'll tell you where it's at.
Fortune 500? More like Fortune 50000 (ok, exaggeration). But there are so many banks in the world, and their automation can run back to the 1950s. They are only slowly moving away from mainframes, if only because a rewrite of a complex system that nobody understands is tough, and possibly very costly if it is the key to billions of euros/dollars/...
IBM prices processors differently for running COBOL and Java - if you run mostly Java code, your monthly licensing fees will be vastly different. On boot, the service elements (their BMCs - on modern machines they are x86 boxes running Linux) loads microcode in accordance to a saved configuration - some CPUs will run z/OS, some will run z/OS and COBOL apps, some will run Java, some will run z/VM, some will run Linux. This is all configured on the computer whose job is to bring up the big metal (first the power, then the cooling, and only then, the compute). Under everything on the mainframe side is the PR/SM hypervisor, which is, IIRC, what manages LPARS (logical partitions, completely isolated environments sharing the same hardware). The cheapest licensing is Linux under a custom z/VM (they aren't called z but LinuxONE), and the most expensive is the ability to run z/OS and COBOL code. Running Java under z/OS is somewhat cheaper. Last time I saw it, it was very complicated.
What we really need is the European Union to fund a global competitor.
reply