This implies that the goal of compensation transparency is to satisfy people's curiosity. I don't think that's the case. Regardless of how it's denominated, I think the goal of compensation transparency is ... uh... equity... no pun intended.
Sun or otherwise it’s not the beginning of his career. I don’t mean they are billionaires but I’m willing to bet they don’t need to collect cash to pay downpayment like an average Google L4 on their first starter townhouse in Sunnyvale which will get more expensive while they receive their 200ks, so yeah I know exactly what I’m talking about. He knows very well too.
Are you... actually willing to bet? Because I would take the other side of that bet. But please, let's make it meaningful: I still have a mortgage to pay and college-aged kids!
I guess you've basically proven my point, although it appears I may have been poorly communicating it as if I meant you can afford a yacht or not, which I would certainly think would be deserved, but none of my business to comment on: you have a house/mortgage and your kids are now grown to college aged, but for someone who's not had as long of a career, the low-variance compensation means they have fewer opportunities to get ahead by trying harder and totally bound by equity performance [which actually does vary quite a lot, I'd suspect] so the risk-reward of a flat-comp startup generally favors the more established players in the labor market, unless the amount is somewhat above the range of the base salary they'd command elsewhere (which is the case with cash-rich players like OpenAI).
Frankly, when you look around and everyone around you is focused first and foremost on getting rich, that's a good indication that the rich veins have already been mined.
Wealth is built on creating something of value. There is gamesmanship played to acquire that value once it is created, but without the thing itself they are all just picking each others' pockets.
I don't work at Oxide but I have done an Emeryville <-> Sunnyvale commute, so I can confirm that Oxide employees almost certainly do not want to deal with that
> Some will say that we should be talking about equity, not cash compensation. While it’s true that startup equity is important, it’s also true that startup equity doesn’t pay the orthodontist’s bill or get the basement repainted. We believe that every employee should have equity to give them a stake in the company’s future (and that an outsized return for investors should also be an outsized return for employees), but we also believe that the presence of equity can’t be used as an excuse for unsustainably low cash compensation. As for how equity is determined, it really deserves its own in-depth treatment, but in short, equity compensates for risk – and in a startup, risk reduces over time: the first employee takes much more risk than the hundredth.
Yeah, but equity is very standard in SF startups, Oxide actually goes in the opposite direction, by reducing weight from equity and placing it on salary.
Oh I didn't notice I was talking to a primary source.
Below I have tried to make clear what the original statement was (root comment), the implicit presumption in it that I adressed (that flat salaries make a company more co-op) instead of addressing the actual now invalidated question (why not 'make it this other thing), why I think it's wrong and what I think is the case (the opposite).
None of this is necessarily worthy of such deep elucidation, mind you, but I quite enjoy the nerdy depth-first nitpickiness that only internet threads can afford. So here goes nothing:
The root comment asks "why not make it an employee owned co-op at this point." implying that Oxide's salary policy difference, (diff between the Oxide fork and the SF Startup base) brings it too close to employee-owned status.
What I say is, au contraire mon amie, the delta that Oxide's bylaws/RFP apply on top of the base Corp Structure
refer to the fixed compensation, where equity/ownership remains largely unchanged (unchanged from the base, not inexistent or unchanged compared to the base of the base, the commodity non-sf Corp.). So to the extent that it is employee-owned, it is a property of the immediate base and not of the fork.
One could even argue that since total compensation a limited resource, an increase in fixed compensation means a decrease in equity compensation and viceversa (more salary less profits, less salary more profits), therefore the flat salary difference of Oxide pulls them AWAY from employee-ownership (albeit only slightly admittedly), by making fixed compensation a stronger component of compensation than equity, (at least compensation-wise, as there are non comp. properties of ownership)
If I may mathematically summarize in oversimplified 1D political terms. Consider the Political Alignment 'PA' of company structures as reals [-1;+1], where right = (0;1], left = [-1;0) and center = [-ε;+ε]. Then:
I guess what I'm saying big picture is that Oxide is a political-center Company and OS. It was born treading the needle between Linux and Oracle, which are already quite centered Orgs/OS when compared to the extremes like GNU and Apple.
Thank you for coming to my TED talk and yes, before someone asks, I have kissed a girl before.
> Synadia CEO Derek Collison told Runtime Tuesday that the company intends to transfer the NATS trademark to the CNCF at some point in the future "because we just feel that the damage to the ecosystem and the ugliness is not worth it for anyone." While nothing will be official until the lawyers sort it out, Collison said "my hope is that [this dispute] forces some open dialog outside of the CNCF and outside of NATS about the state of open source. I think open source for companies like Synadia is at a crossroads."
The NetApp lawsuit. Apple wanted indemnification, and Sun/Oracle did not want to indemnify Apple.
At the time that NetApp filed its lawsuit I blogged about how ZFS was a straightforward evolution of BSD 4.4's log structured filesystem. I didn't know that to be the case historically, that is, I didn't know if Bonwick was inspired by LFS, but I showed how almost in every way ZFS was a simple evolution of LFS. I showed my blog to Jeff to see how he felt about it, and he didn't say much but he did acknowledge it. The point of that blog was to show that there was prior art and that NetApp's lawsuit was worthless. I pointed it out to Sun's general counsel, too.
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.
> 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):
Cantrill was not involved in ZFS, and was not a co-author. Cantrill was involved with DTrace:
> 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.
> I guess Bonwick et. al. were not really aware of LFS. Sad.
They were:
> [16] Mendel Rosenblum and John K. Ousterhout. The design and implementation of a log-structured file system. ACM Transactions on Computer Systems, 10(1):26–52, 1992.
> [17] Margo Seltzer, Keith Bostic, Marshall K. McKusick, and Carl Staelin. An implementation of a log-structured file system for UNIX. In Proceedings of the 1993 USENIX Winter Technical Conference, 1993.
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.
I will just say I can’t thank both of you enough. I cut my teeth on zfs and it was a pillar of the rest of my career.
It’s a constant reminder to me of the value of giving that college kid free access to your code so they can become the next expert doing something creative you never thought of.
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.
The argument advanced in the piece isn't without merit -- that ripping out DTrace, if subsequent legal developments demanded it, would be a heck of a lot easier than removing a filesystem that would by then contain massive amounts of customer data.
And given what a litigious jackass Larry Ellison / Oracle is, I can't fault Apple for being nervous.
There's always two sides to one story. And Jobs was not the kind of person to take no for an answer. I've known other narcissists and they've always seen friends as more of a resource than someone to care about.
I think the truth is somewhere in the middle.
Another rumour was that Schwartz spilling the beans pissed Jobs off, which I wouldn't really put past him. Though I don't think it would have been enough to kill this.
I think all these little things added up and the end result was just "better not then".
Certainly one would build something different starting in 2025 rather than 2001, but do you have specific examples of how ZFS’s design holds it back? I think it has been adapted extremely well for the changing ecosystem.
I didn't watch it in its entirety, but I'm familiar with Allan's work. There doesn't seem to be anything fundamental to the design of ZFS that his talk highlights as limiting, but there are many areas that have benefitted from optimization and tuning.
ZFS was developed in Solaris, and at the time we were mostly selling SPARC systems. That changed rapidly and the biggest commercial push was in the form of the ZFS Storage Appliance that our team (known as Fishworks) built at Sun. Those systems were based on AMD servers that Sun was making at the time such as Thumper [1]. Also in 2016, Ubuntu leaned in to use of ZFS for containers [2]. There was nothing that specific about Solaris that made sense for ZFS, and even less of a connection to the SPARC architecture.
> There was nothing that specific about Solaris that made sense for ZFS, and even less of a connection to the SPARC architecture.
Although it does not change the answer to the original question, I have long been under the impression that part of the design of ZFS had been influenced by the Niagara processor. The heavily threaded ZIO pipeline had been so forward thinking that it is difficult to imagine anyone devising it unless they were thinking of the future that the Niagara processor represented.
Am I correct to think that or did knowledge of the upcoming Niagara processor not shape design decisions at all?
By the way, why did Thumper use an AMD Opteron over the UltraSPARC T1 (Niagara)? That decision seems contrary to idea of putting all of the wood behind one arrow.
Niagara did not shape design decisions at all -- remember that Niagara was really only doing on a single socket what we had already done on large SMP machines (e.g., Starfire/Starcat). What did shape design decisions -- or at least informed thinking -- was a belief that all main memory would be non-volatile within the lifespan of ZFS. (Still possible, of course!) I don't know that there are any true artifacts of that within ZFS, but I would say that it affected thinking much more than Niagara.
As for Thumper using Opteron over Niagara: that was due to many reasons, both technological (Niagara was interesting but not world-beating) and organizational (Thumper was a result of the acquisition of Kealia, which was independently developing on AMD).
I don’t recall that being the case. Bonwick had been thinking about ZFS for at least a couple of years. Matt Ahrens joined Sun (with me) in 2001. The Afara acquisition didn’t close until 2002. Niagara certainly was tantalizing but it wasn’t a primary design consideration. As I recall, AMD was head and shoulders above everything else in terms of IO capacity. Sun was never very good (during my tenure there) at coordination or holistic strategy.
Yeah I think if it hadn’t been for the combination of Oracle and CDDL, Red Hat would have been more interested in for Linux. As it was they basically went with XFS and volume management. Fedora did eventually go with btrfs but dints know if there are are any plans for copy-on-write FS for RHEL at any point.
It’s not like Red Hat had/has no influence over what makes it into mainline. But the options for copy on write were either relatively immature or had license issues in their view.
Their view is that if it is out of tree, they will not support it. This supersedes any discussion of license. Even out of tree GPL drivers are not supported by RedHat.
We had those things at work as fileservers, so no containers or anything fancy.
Sun salespeople tried to sell us the idea of "zfs filesystems are very cheap, you can create many of them, you don't need quota" (which ZFS didn't have at the time), which we tried out. It was abysmally slow. It was even slow with just one filesystem on it. We scrapped the whole idea, just put Linux on them and suddenly fileserver performance doubled. Which is something we weren't used to with older Solaris/Sparc/UFS or /VXFS systems.
We never tried another generation of those, and soon after Sun was bought by Oracle anyways.
I had a combination uh-oh/wow! moment back in those days when the hacked up NFS server I built on a Dell with Linux and XFS absolutely torched the Solaris and UFS system we'd been using for development. Yeah, it wasnt apples to apples. Yes, maybe ZFS would have helped. But XFS was proven at SGI and it was obvious that the business would save thousands overnight by moving to Linux on Dell instead of sticking with Sun E450s. That was the death knell for my time as a Solaris sysadmin, to be honest.
