...what? There were FOUR HUNDRED people working on this thing at G? Quite literally the opposite of the anecdote from the "Androids" book where the Sony (?) execs were confused when the Danger, Inc guys told them Brian Swetland wrote all the code for the T-mobile Sidekick by himself (whereas Sony (?) had teams and teams of people for the same stuff in their offerings).
The project seemed super bloated. I remember thay had at least one person who seemed to be working full time on a clone of vim which iirc was considered part of the OS.
You’re referring to Raph Levien’s work on Xi [0]. Not really just a vim clone. In Fuchsia, iirc, it would have been the basis of all text editing services. If nothing else, it seems to have popularized rope data structures [1] for newer text editors.
No doubt the project generated some interesting research and was pushing the boundaries, but its an explanation as to how a smart speaker OS could take 400 developers.
Fuchsia was not meant for just embedded devices. I recall there being a sentence in an old description (which I can no longer find mention of) which explicitly called out PCs and smartphones as targets. That’s likely still the ambition.
The full picture is apparently that after years of full time work by 400-person team Fuchsia is more like "nothing OS" instead of "a smart speaker OS"...
Its build by Google so im not sure it will get mainstream or just killed. But calling it "nothing OS" is big understatement, When was the last time a new OS from scratch was created? or if we comparing it to linux/Windows/Mac Im sure a lot people work on these
There are college classes where you write an OS from scratch in a semester. The basics of a modern OS are not difficult. The vast majority of the effort in any OS is all the different hardware you need to support.
If we're talking about commercial operating systems then Windows NT comes to mind. Here's what they say:
"In 1988, when the project first began, the team comprised about 20 engineers. By the time the first version of Windows NT shipped five years later, the team had expanded to about 150 engineers as it battled constraints and tradeoffs."
But I think comparing these team sizes is not very meaningful without at least a cursory look at what is part of the project and what isn't. Is it just the kernel? Does it include an entire graphics pipeline, a UI toolkit, a network stack, device drivers?
He probably meant "usable OS fit for mass market adoption". Of course one person can develop a bare bones OS, but this will be missing so many things compared to established systems, while providing too few advantages, that any wide adoption is impossible. Even Microsoft, with well over a thousand (IIRC) Windows developers, had to scale back their Longhorn plans substantially.
Far as I remember, all of them engage in some ridiculous wheel handcarving projects. Just because Google does it badly doesn't mean the others are more reasonable in catering to their NIH syndrome.
My knowledge can and probably is very out of date given how many of Google's projects are publicly realized. But my impression was that Fuschia is a general purpose OS and was planned (like, very long term planned) to eventually become the OS of choice for some Android and Chromebook devices. A project that lofty makes sense to have 400 engineers on.
Canonical with all that people is making a very mediocre desktop experience.
So doesn't seem surprising making something actually good would take a lot more.
Desktop experience is generally not the same people as the OS. Desktop experience is a lot more complex than an OS (both are complex in different ways though)
Most of that was when the team was pretty tiny. It was fun starting from when the kernel was just beginning to run userspace code. I'm still very happy with how the syscalls turned out. If I did it again, I'd stick with a (small) monolithic kernel though -- makes a lot of things simpler.
vDSO doesn't provide a security boundary. vDSO basically provides a pure-userspace fastpath for syscalls, only making the real syscall if necessary. It's great for low-overhead read-only calls that cache well and that you're always allowed to do, like clock_gettime(2) -- but not much more. You can't implement all syscalls as vDSO; if it's a vDSO the goal is to not make an actual syscall at all.
Fuchsia might use vDSO-style things more as a way to replace the glibc-style syscall stubs, abstracting away the actual syscall ABI? That doesn't remove the actual syscall.
> why don't linux use vDSO for more things?
vDSO is much more complex to manage than traditional syscalls, can't be used for anything except pure read always allowed things, etc.
As for optimizing syscalls, it seems things are moving more toward io_uring and ringbuffers of messages going in/out of the kernel, with very few syscalls made after setup.
The intent behind the vDSO style interface for syscalls in Fuchsia was primarily to avoid baking specific syscall mechanisms into the ABI, hopefully to allow future changes to the mechanism without breaking binary compatibility -- which was defined as ELF linkage against libzircon.so.
"Need" is a binary concept, that's not how project planning and prioritization work in the real world. There are a lot of things that are not "needed" that are beneficial, and a lot of things that are beneficial that you end up not having resources to implement. So then it is all about tradeoffs.
Software projects can derive massive economies of scale from a large install base, since there is no marginal cost. A larger install base lets you amortize the fixed cost over more users. The more users you have, the more useful but not strictly need optimisations and features you can justify implementing.
That's what I've heard too: some high-up engineer is bored but Google wants to keep their talent on staff, so they hand them a shiny, exciting computer science playground with grand aspirations.
These numbers often get inflated because the people in change count every part-time worker as a full team member (bigger headcount = bigger promotion!). But it's still a crazy number. At every level everyone is incentivized to bloat the headcount as much as possible.
I don't think part time work in SWE is common at all. Especially at Google.
The 400 number is likely including product owners, business analyst, designers, etc into those numbers not strictly being SWEs (happy to be proven wrong).
For a comparison, initial Windows NT 3.1 had 340 devs/testers, NT 3.5 had 530 devs/testers. No idea why product/program managers aren't listed. There must have been some.
That's good to know, honestly surprised to read that NT had that many. I'd figured early versions wouldn't require that many people. Now knowing the Fuchsia numbers, I don't know if that's a signal to how productive the team is or if they dwindling resources.
...what? There were FOUR HUNDRED people working on this thing at G? Quite literally the opposite of the anecdote from the "Androids" book where the Sony (?) execs were confused when the Danger, Inc guys told them Brian Swetland wrote all the code for the T-mobile Sidekick by himself (whereas Sony (?) had teams and teams of people for the same stuff in their offerings).