I think peak OS development was in the 70s and 80s. Every hardware vendor also had their own OS, or several. The System V OSes were just different enough to be annoying.
To name a few: UNICOS, NeXTStep, HP-UX, RSTS, ULTRIX, VMS, AIX, SunOS, Solaris, IRIX, A/UX, MacOS, ProDOS, Amiga OS.
Linux isn't capabilities based, or real time by default. Google likes permissive licenses. Android, while good, was a knee-jerk by Google in reaction to the iPhone. If you've got the resources of Google, why not try to build something in house that scratches some long standing itches and at the same time get ownership over the OS that could power everything from your phones to laptops?
The original version of Android looked like and worked like a Blackberry: small screen with a physical keyboard and a D pad for navigation (no touch control).
When the iPhone was announced in 2007, they realized that on-screen keyboards and multi-touch control were the future, so they did a complete redesign, moving to an interface similar to the iPhone. Here's a quote from one of their engineers talking about the iPhone announcement:
“As a consumer I was blown away. I wanted [an iPhone] immediately. But as a Google engineer I thought ‘We’re going to have to start over’” Chris DeSalvo said. “What we had suddenly looked so… nineties. It’s just one of those things that are obvious when you see it.”
Nothing to do with OP's point of Android being based on Linux even before the iPhone.
[Every time this story is told, I like to remind - note how fast Google were able to pivot / adapt when Microsoft with their crazy resources and Engineering might took way longer. (Even beyond that MS had to change the way apps were developed for WP.) Fact is Google/Danger/Android were in a fundamentally good position mobile OS design wise way before the iPhone. After the iPhone - they looked at the possibilities of multi touch soft keyboard UI and were able to get there and surpass fairly fast.]
To be fair Google knew about the iPhone well before Microsoft did (they worked closely with Apple in the beginning for Maps and search).
But even adjusting for that it took MS 3-4 years after the iPhone to just get Windows Phone 7 out, and that was also clearly a rushed release, because they had to throw everything out for Windows Phone 8.
Correct, Google bought Android in 2005 but went back to the drawing board in 2007 when iPhone came out. Now Google has a chance to take some time and try some new things out.
They didn't totally go back to the drawing board. Comparing with the original demo they mainly just added touch stuff. The first android phones still had the same blackberry-esque selection ball even though they also had added capacitive touch.
I believe after rage from Jobs they left out multitouch zooming at first and did something double tap based, even though MS had done it before Apple (without capacitive) and Minority Report has shown it.
If you look at both devices you'll notice that Android essentially looked and operated the same. The only changes were to add additional support for touch screen devices such as the virtual keyboard. I would hardly call this going back to the drawing board. There was no need as they already had all of the software pieces in place.
Not having to deal with Linux's refusal of maintaining a stable driver API and ABI for a start. The number one reason that stops Android from getting updates on smartphones is that hardware manufacturers don't want the burden of constantly making small changes to their proprietary drivers to follow new linux kernel changes, something that they don't have to worry about when they make drivers for, say, Windows PCs.
Even Google's own phones, like the Nexus and Pixel, are stuck because of this. They receive updates faster than non-Google phones, but they do not receive more than 2 years of feature updates (with an additional year of security updates courtesy of Google backporting fixes from newer android builds to the older kernel).
Fuchsia is not going to be burdened by Linux kernel dev policies of constantly breaking APIs and their requirement for driver developers to open source their stuff, obey the kernel coding preferences (like when they rejected AMD's driver because of the HAL) to get them mainlined so that they can finally be kept in a maintained state.
>Fuchsia is not going to be burdened by Linux kernel dev policies of constantly breaking APIs and their requirement for driver developers to open source their stuff, obey the kernel coding preferences (like when they rejected AMD's driver because of the HAL) to get them mainlined so that they can finally be kept in a maintained state.
And as a result, its drivers will be far lower quality and much less stable, and the system as a whole will pay the complexity cost of working around the awful code that hardware vendors churn out.
> And as a result, its drivers will be far lower quality and much less stable
I don't buy it. Windows provides stable driver ABIs and works just fine. A lot of the changes to the Linux driver API are gratuitous, and isolating driver development from the whims of the core won't actually hurt.
If anything, a stable ABI will help, since a smaller, well-defined boundary between the kernel core and drivers allows for things like Vulkan-like validation layers, better debugging, better sandboxing, and even transparent thunking to userspace.
Will some drivers be shitty? Of course. But many drivers won't be, and drivers will be less shitty overall when they can spend more time on being good drivers and less time dealing with GFP_FOOBAR becoming GFP_BARFOO.
Conventional wisdom is that backward binary compatibility i some huge unreasonable burden. This conventional wisdom is wrong; if anything, maintaining a stable ABI imposes some discipline that focuses development effort and that forces you to modularize your system.
I've personally never had any problem stemming from the lower levels of the system ever since Windows 7. Whenever I've seen major bugs on Windows, it was on user space stuff like the profile corruption that breaks the start menu and metro/UAP apps in Windows 10 after the major updates which can be fixed by deleting the user and creating a new one.
Windows also has a more robust architecture where it matters, like the fact that a GPU driver crash doesn't kill the user session (windows can reload that subsystem while keeping the user session running since Vista), whereas it can either kill Xorg or just outright freeze the system on linux. A very useful way to architect the OS, although I've only experienced it on Vista and had more stable GPU drivers from 7 onward.
Software stability isn't the core point - how is the stability/instability of Windows relevant to the disadvantages of a driver ABI that changes continuously?
> I don't buy it. Windows provides stable driver ABIs and works just fine.
Depends on the driver, but often they are buggy and will never be updated for the life of a device. Once a device has been sold the manufacturer doesn't care about support. Most linux CVE's are in drivers, imagine how many are lurking in the binary blobs of random third parties?
> Most linux CVE's are in drivers, imagine how many are lurking in the binary blobs of random third parties?
That's why we should sandbox drivers as much as possible! I'm a big fan of punting a lot of driver work to userspace. How are we supposed to do that if drivers are allowed to use the entire Linux kernel internal API and do whatever they want? How can we possibly isolate a driver that thinks it has the right to take mmap_sem and twiddle PTE bits?
Sandboxing isn't a substitute for having your drivers be open source. Even if all drivers were written in safe languages, you'd still have CVEs and still want to fix those CVEs.
Closed source Linux drivers exist. Open source Windows drivers exist. An unstable kernel ABI is neither necessary nor sufficient a condition for open sourcing drivers.
The key new "feature" of Fuschia is that its stable ABI makes closed-source drivers easier to write in the short term, relative to Linux. As a result, the vast majority of Fuschia drivers will be closed-source. Don't you agree?
I believe supporting a stable API and closed-source drivers will result in a technically inferior, more complex, less stable kernel. The Linux model of including all the drivers in a single open source codebase, where the drivers can be refactored and improved along with the rest of the kernel, is a genuinely superior way to develop a kernel, which produces a genuinely technically superior product. I just hope Google realizes this before they sink too many millions into Fuschia.
How exactly are you going to sandbox your drivers? Run them in user-mode, perhaps? But then you've constructed a microkernel, and no-one uses your system because it's slow.
Anyway, what I said is that sandboxing isn't a substitute for open-sourcing. They are complements, not substitutes.
I've always thought that one of the things that gives Windows drivers the edge over Linux ones is the fact that Microsoft provides a testing and validation suite for drivers [1].
>I don't buy it. Windows provides stable driver ABIs and works just fine.
I strongly disagree with this statement. Windows is a buggy mess on all levels from GUI down to kernel. It is a consensus of technically enlightened people
I have a hard time thinking that Google will have a better user focused story than Linus. To that end, I have my doubts about them giving a more stable abi.
Just thinking of how painful taking a dependency on guava can be makes me think this claim is satire. :(
Really? Guava has a well defined deprecation policy, they give advanced warning of what's going to be deprecated, and they have consistently stuck to it with no surprises. It's one of the most well designed and carefully curated Java libraries in the entire ecosystem.
It is well documented. It is also ridiculously aggressive.
If it wasn't in the Java ecosystem, it might not feel weird. But the Java community had maintained backwards compatibility for a long long time. Guava promises, what, a year?
And for internal use, that is fine. I have seen some poor sods introduce it as a dependency of theirs, which can lead to frustrating upgrade cycles.
Edit to add: the Jakarta libraries are also fairly well designed. To the point that most things in guava were already there.
If anyone was going to reinvent an OS I’d like google to do it. They’re capable and have the cash to do it. I do think have this in conjunction with buying HTC (rumored) could be them trying to iPhone and their lineup by owning both the software (via fuschia) and the hardware.
Google can't get Gmail to sort mail properly. Amongst a thousand of small grievances I have.
That may seem quite irrelevant, but if I'd like someone to reinvent the OS, I'd like it to be people that have taken a stance in favour of stable, simple, straightforward software (the people behind Pinboard, Tarsnap; djb... just to name a few).
Basically, in some views the sorting is by the first message in the thread, while in other views it is by the last message (that last one makes more sense to me).
Even more surprisingly, Inbox (by Google) sorts everything by last message (last time I checked, which was a long time ago).
It seems like the software you mentioned does well because they are so small. I'm not sure a team similarly small could produce a modern OS that addresses the needs of generic phones (in the sense of they are truly incredibly complex oses, not in the sense of running on arbitrary phones).
Notably, small teams can dictate priorities that don't scale at the level of tens of thousands of engineers.
but, who or what gives Google the capability to write a new OS? (e.g. are they currently employing a group of highly experienced, top-notch OS engineers? have they formed these engineers into an effective, efficient team? etc.)
Google is a NSA/Intelligence agency facade, nothing more nothing less. You only have to look at the PRISM program documents to understand this simple fact.
You could argue they've already reinvented an OS with ChromiumOS. Despite its shortcomings and limitations, I think they actually managed to get a lot of things "right" with its design.
These slides from the Chrome OS Internals [0] talk provide a good overview.
I'd not. Google has a greed that regularly leaves blatant information leaks unfixed for years.
For example, you still cannot safely use any third-party keyboard on Android. Because Google refuses to give users a way to block internet access for individual apps, and third-party keyboards by definition can read out your passwords and everything you type.
Would just as well be helpful for all kinds of other apps. I'd be much less concerned about giving my camera app permission to take pictures at any point in time, if I knew that it can't actually upload those to anywhere. But I can't. I have to blindly trust my camera app for no reason other than Google not wanting to give up potential ad revenue.
When you look at the Fuchsia OS repositories in Github and select these by language the overwhelming bulk are C++. Regarding the languages you cite: there are some non-trivial parts in Go; the Fuchsia package manager, for instance. There are several bindings to certain key parts of the OS provided for Rust, but no actual Rust components that I can see. Python is used for some build and packaging utility type stuff. Kotlin is provided with one binding library with four whole commits.
Regarding two others mentioned in wikipedia; Dart is actually more prominent than Go, Python, Rust and Kotlin combined. C has lots of binding libraries, but only a pair of boot loaders appear to be core components, plus a fortune stub.
You can poke around their github mirror and filter project by language, for example Go[0]. pm, wlan, thinfs, and netstack looks like some decent size components written in Go. Rust and Kotlin looks mainly like bindings at this point (no real core parts yet). Python has 'build' and 'scripts', which look like tools useful when doing dev on Fuschia.
Each time this comes across my feed, there's a brief period of excitement - "oh yeah, we're getting a new not-Unix microkernel backed by a major company!" A few moments later I remember that it's being written in C++ and is basically the evolution of Chrome OS and the mood dampens. I'm still be waiting for the next truly innovative OS to show up and poise itself to become ubiquitous. Unfortunately I don't have much faith in Fuschia, especially after poking around in Chromium.
In the spirit of HN though this comment basically guarantees its success, right?
Just C. Rust has a lot of problems for serious low level work imo and suffers from a lot of the same classes of problems C++ does, and there aren't many other candidates. A simple microkernel should be fairly straightforward to write in C without any big security concerns, especially in the hands of a multi-billion dollar company. You offload most of the security work to the architecture.
> Rust has a lot of problems for serious low level work
Could expand on where it suffers? I've been playing around with Rust in the embedded space (nothing serious at all); I find it to be as elegant in a nonstd situation as it is in standard high level app development.
> and suffers from a lot of the same classes of problems C++ does,
What are those classes of problems? C++ never offered a safe alternative to C, but did offer some eases of use and stronger typing over C.
Rust on the other hand has a huge amount to offer over C. At no point in my Rust work do I ever wish I was working with C, quite the contrary. But I like strongly typed languages, Rust is definitely not for those that dislike types.
>Could expand on where it suffers? I've been playing around with Rust in the embedded space (nothing serious at all); I find it to be as elegant in a nonstd situation as it is in standard high level app development.
By "the embedded space" do you mean "devices running Linux with Rust in userspace?" Because that's much higher level than what I'm talking about, and has very different design concerns from those of a general purpose operating system.
My main beef with Rust for low level development is that Rust is way more complicated than it should be. IMO for serious low level programming Rust should have 1/10th the featureset. It also has issues dealing with the weird data structures that tend to come up in low level contexts in my experience. Rust also has the shiny fad status working against it IMO. If, say, 5% of C hackers understand low level programming and/or kernel hacking, then maybe 0.5% of Rust hackers do (if that).
>What are those classes of problems? C++ never offered a safe alternative to C, but did offer some eases of use and stronger typing over C.
It comes back to complexity and typing. There's nothing wrong with strongly typed languages (of which C is a member), but I strongly dislike object oriented languages and paradigms. Especially in low level contexts it's like forcing a square peg into a round hole. Other features C++ brings to the table like operator overloading and templates are antifeatures, doubly so in a kernel hacking context. Many of the same patterns of unnecessary complexity introduced by C++ are also present in Rust.
C is boring, but it's also transparent and straightforward. Ergonomics takes a backseat to simplicity in C, which is a compromise I'd take any day.
I have been working on writing my own OS in rust for the past few months, and the main thing I have had the most difficulty with is Rust itself. The package management is so much better than C, dependencies are easier, and it was honestly easier to get working compared to C++. The fact that they nicely have separated rust core and std so that I don't have to deal with things randomly breaking because of something I haven't implemented. The abstractions that Rust offers I don't feel suffer the same problems as C++ because they are much more straightforward to use and just make sense from an object oriented programming perspective.
Rust itself is so inherently different from other a language like C that it takes a long time to truly understanding lifetimes and the borrow checker to the point where you are actually making use of the languages features.
The straightforwardness of C is really where it shines, and for me at least Rusts biggest upside is also its biggest downside, because learning to write good Rust is not an easy process.
People often make this statement, but I don't know exactly what it means. The type system is great for writing finite state machines, which I'm finding to be a nice quality for the toy programs I've written on Tock.
> Rust also has the shiny fad status working against it IMO.
Rust is 2 years into it's stable life. It's young, will it ever exceed the number of lines written than C or C++, almost definitely not, but I wouldn't dismiss it off-hand because people like it, there might be a good reason for that.
> If, say, 5% of C hackers understand low level programming and/or kernel hacking, then maybe 0.5% of Rust hackers do (if that).
I wonder about this statement. I've noticed quite a large number of people in the community working with Rust in the embedded space. According to the people who responded to the Rust survey this year, https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Resul..., it was nearly 17%.
> C is boring
I've met more undefined behavior that makes me not agree.
> > Rust is way more complicated than it should be
> People often make this statement, but I don't know exactly what it means.
I can't speak for op, but you're right: people often make this statement. I'll try to explain what I might mean:
C is way more complicated than it should be.
The things we want in a language are tools that allow us to tell the computer what to do, but because people are bad at that, language design is taking us in the direction of telling the computer what we mean so it can tell us whether we're talking gibberish or not.
I don't need a type system. I don't need "warnings" about converting floats to chars: I know what I'm doing and why. I have a good idea what kind of machine code the compiler is producing, and yes: I often objdump to make sure.
If I need a FSM, I'll use erlang. If I need any kind of data processing, I'll probably use K/Q where I can. I can write some fast stuff in C where I need it. If I just need to bosh some stuff together I have perl. Maybe I want to fantasize about a DSL? It'll probably be a lisp or a forth. If I wanted a strong type system for units I want to get from some model nerds, I'll use OCaml.
I don't see the point in Rust when doing these things takes more code and runs slower, and worse:
> Rust is 2 years into it's stable life. It's young.
I got burned by Python when it was" two years into its stable life" sometime around 1.5 and again around 2.2, and so I hesitate even looking at rust unless in a decade it can still run and compile rust programs written today.
This whole "let's rewrite everything in rust" is good practice. I'm watching you guys do it, and I know afterwards you'll try to beat the performance I'm getting in other languages.
Once you're writing programs that are smaller and faster than me, then we'll probably talk.
> C: I've met more undefined behavior that makes me not agree.
I don't write C like most people, so perhaps I don't have trouble with it like most people. My C programs don't leak memory or crash, and I tend to use a belt+braces approach to security that is very difficult in languages without good multiprocess support.
> I don't need a type system. I don't need "warnings" about converting floats to chars: I know what I'm doing and why.
No, you don't.
Regardless of your skills and seniority (I'm guessing pretty junior with this kind of hubris), there will come a time where you will make mistakes that can be caught by a good compiler. You want this compiler at your side, and the more statically typed your language is, the more robust your code will be.
> Once you're writing programs that are smaller and faster than me, then we'll probably talk
What a strange metric. Assembly language would probably meet these requirements but surely, you would not consider it.
I've been programming professionally for almost thirty years at this point.
That's admittedly long enough to get some peculiar ideas about programming, but there's a certain kind of person that thinks "statically typing" is a panacea for programming mistakes -- or even that there's a single solution for anything at all...
I wouldn't trust anyone who thinks a solution is a panacea in the software field, but having type annotations demonstrably leads to not just more correct code but also code that can be understood better by its surrounding tooling, thereby enabling automatic refactorings, auto completion, smart browsing, optimizations, etc...
Static typing is not perfect but it's better in all respects than dynamic typing.
Can you point to these Stac-M3 results and maybe at least mention that language? I wasn't able to find it.
Static languages are universally recognized and demonstrated as faster than dynamically typed languages, even if you claim to have found one rare exception. This is not just an opinion, it's scientific and objective fact.
But please share with us that code that runs more quickly on a dynamic language than a static language for you, I am genuinely curious (and equally curious to find out if you just made this up).
The first item on the list is written in an interpreted language.
> This is not just an opinion, it's scientific and objective fact.
I've just demonstrated two counterexamples, so it's clearly not "scientific and objective fact". Indeed I've never met anyone who even thought Rust would outperform an experienced C programmer in programmer speed, program runtime, and low program size.
>The first item on the list is written in an interpreted language.
Could I see the code? Because I'm pretty sure you can't write a fast numeric code without the knowledge of which type you will get on input. That's why fortran still rocks and we do nat have anything beyond fortran, c and c++ in the field of computation.
> Because I'm pretty sure you can't write a fast numeric code without the knowledge of which type you will get on input. That's why fortran still rocks and we do nat have anything beyond fortran, c and c++ in the field of computation.
You're not far off.
The first trick is that even though `x` can have any type, `x[4]` and `x[5]` must have the same type. This kind of array whilst uncommon in Python is extremely common in array languages. Array languages tend to have a lot of vector operators (and so therefore are very competitive users of the AVS512 instruction set) which tend to be very fast. Programmers of array languages also tend to avoid things like loops and branches -- indeed you might enjoy http://nsl.com/ if you want to expand your mind a bit on that point.
The second trick is that an interpreter can be made very small. If you can get your entire program and the interpreter into L1 then you do not stall the CPU while your program fetches various parts of itself from memory. This is a trick languages like Fortran and C and C++ don't miss per-se, a very experienced programmer can usually identify the hotspots and optimise the hotpath for these things, but it is very time consuming to do this when your entire program is the hotpath!
> That's the first link I found and it says nothing about a benchmark
Except the first paragraph:
The STAC-M3 Benchmark suite is the industry standard for testing solutions that enable high-speed analytics on time series data, such as tick-by-tick market data (aka "tick database" stacks).
I'm not going to bother any further with such an obvious troll.
>I don't need a type system.
I'm not sure how that is supposed to work in C. Are you telling me you're doing everything in raw byte arrays? As soon as you use primitive types or structs in C you're using the typesystem.
Even if you use byte arrays everywhere aren't you still documenting the datatype somewhere? Or are you telling me you have them all in your head? How do you remember that ptr[0x3f] refers to the name field of the struct? At the very least you'd turn those magic numbers into a constant. (#define CUSTOMER_NAME_FIELD 0x3f) and suddenly you've reinvented structs...
Types are statically enforced documentation that is trivial to create. Yet I see people constantly wanting to avoid this small triviality to "be more productive".
In your case you should just use assembly and shut up.
OP is talking about a bare-metal world where you might care about things like:
- how many instructions execute between an interrupt trigger and your vector getting executed
- if some piece of data is getting stored in text, data, or runtime space (harvard v single address spaces can make things weird)
- minimizing or not using a stack to avoid clobbering your puny memory
- other misc. things that even hardware vendors don't make easy (or sometimes possible) to find
Honestly I don't think that even C is great for these things, but I mostly blame hardware vendors/architects for this situation. They all like to roll their own standards for documentation, language interfaces, etc. Sometimes it feels like a competition to see who can come up with the worst.
So more of the "Arduino like" embedded space. That also has little to do with the design constraints of a general purpose operating system.
>People often make this statement, but I don't know exactly what it means. The type system is great for writing finite state machines, which I'm finding to be a nice quality for the toy programs I've written on Tock.
Rust gets new features daily [1]. C gets new features every decade if we're lucky.
>I wonder about this statement. I've noticed quite a large number of people in the community working with Rust in the embedded space. According to the people who responded to the Rust survey this year, https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Resul..., it was nearly 17%.
Embedded space != kernel hacking, as I've already pointed out.
> That also has little to do with the design constraints of a general purpose operating system.
Does it not? It's the same issue around no-stdlib, stricter sense of allocated memory, etc. If it isn't something that I can extrapolate from you'll have to explain better why. It's been a while since my CS courses on operating systems.
> Rust gets new features daily [1]. C gets new features every decade if we're lucky.
Yes, this is an age thing. I'm sure in it's infancy, C was gaining features and changing rapidly. For example, C changed significantly early on it's syntax from K&R to Ansi. C compilers have to support that.
It's reasonable to say that the language isn't ready for your use, but the features that are being gained are all related to areas around ease of use of the language, making it easier to get started and lower the initial learning curve. They seem important. By the way, you linked to the RFC repo instead of the language repo: https://github.com/rust-lang/rust/commits/master. The language does have a lot of features that make it into the nightly branch, but those take a long time to bake until they're promoted to stable.
> Embedded space != kernel hacking, as I've already pointed out.
I thought we were talking about low-level programming, not explicitly Kernel hacking. Yes, Arduino and it's ilk are definitely not full OS'.
All of those projects seem very interesting. For Linux drivers, there was this exploratory project I saw a while back: https://github.com/tsgates/rust.ko (hasn't been touched in a while).
So people are doing it and seem to be enjoying it.
>Does it not? It's the same issue around no-stdlib, stricter sense of allocated memory, etc.
No, because a general purpose OS has to do that and effectively, securely, and performantly manage userspace access to those resources (including hardware resources, which you didn't mention). It also has to facilitate secure and performant interactions between userspace programs. Beyond kernel hacking you also have to do some serious work on userspace design, especially if you have a microkernel. This is an entirely different domain than embedded programming usually deals with.
>Yes, this is an age thing. I'm sure in it's infancy, C was gaining features and changing rapidly. For example, C changed significantly early on it's syntax from K&R to Ansi. C compilers have to support that.
Sure, but that doesn't make my argument less compelling. Rust may follow the same path but that's years out and IMO they've already gone too far.
>The language does have a lot of features that make it into the nightly branch, but those take a long time to bake until they're promoted to stable.
But not before the ecosystem runs with it and ships packages that require you to use a nightly compiler to be productive, in my experience. Not to mention that several projects still build the compiler themselves!
I have some opinions about projects like Redox but I'm out of time.
Chromium is a huge mess of intertwined, overengineered, and opaque code IMO. It's hard to make large-scale projects well, and Google seems to lack the discipline if Chromium is any indication. Given that the Fuschia team is closely related and they have already made questionable choices (C++), I'm not holding my breath.
Not every new OS does. The ones that do are using the GNU stack, at least initially because they are there and it saves time. Even then down the road some purge GNU from their OS in favor of better utils, more liberal licensed code, etc.
I'm pretty excited about Fuchsia. Just the fact that, if successful, it will be the first true production-quality general-purpose microkernel-based OS in the mainstream. (QNX and Minix are of course also successful microkernels, but both are pretty niche at the moment; are there any others?)
The design also seems extremely sensible and modern: Everything is namespaced and sandboxed (there's no default "/"), everything is an "object" (sounds similar to Plan 9's file descriptors), capabilities from the ground up, standard RPC between OS components (FIDL, similar to COM or XPC), built-in package management (looks like apps aren't globally installed by unpacking archives, but rather they're run directly from packages, and the process gets the archive file system mounted in its namespace), etc.
While Google seems to be aiming for phones, I wouldn't surprised if this ends up as an option on Google Cloud Platform in a few years' time.
XNU uses a heavily modified Mach 3.0, which is a microkernel, but it doesn't use it as a microkernel, and never has.
In XNU, things like file systems, graphics and device drivers are all running in kernel mode, in the same address space as the kernel. The Windows kernel has the same design -- it's designed as a microkernel, with separate modules internally that communicate via a form of IPC, but everything is running in one process (as opposed to a real microkernel architecture where file systems etc. are userland processes).
With XNU, Apple forked Mach 3.0 and have been making a lot of changes to it over the years, even though Mach itself has progressed since then. On the other hand, XNU inherited Mach's high syscall overhead (considerably higher than Linux), and to my knowledge Apple has moved a lot of stuff into ordinary syscalls rather than Mach messages to remove this overhead.
Edit: Interestingly, around the time before Leopard, when Darwin was still a thing, there was a research project called Darbat [1] that tried to supplant parts of Mach with L4, a more modern microkernel, and actually run XNU as a userland process on top of it. Unfortunately, nothing came of that project.
Windows has made some effort to split components into user space from Vista onwards, they introduced the User Mode Driver Framework allowing for some drivers to be written in user space [1], it doesn't give access to all of the functionality in the Kernel Mode Driver Framework (KMDF) though [2].
> everything is an "object" (sounds similar to Plan 9's file descriptors)
The nice thing about Plan 9's everything-is-a-file setup is that everything has the same file-like interface. Saying everything is an object does nothing to convey any sort of standard interface.
I can't really find the failures you mention in the links you provided, can you point me to a more definitive source?
Rob Pike replies here[1] that direct framebuffer access and networking are easy to get as new devices, although they need to be made available by the kernel. The "everything is a file" mantra doesn't fail, why would it?
In the second link, Carmack just notices that plan9 is pretty dead, and we all know it is :)
Their main problem is not the kernel. It’s their application APIs. What a clusterfuck that is in Android. And now with tens of billions of LOCs written for it they’re stuck with it forever.
i mostly agree. as a mere mortal android app programmer, i feel a significant amount of pain when i build apps using the android SDK and the standard set of tools. there's a lot of weirdness, confusion, unexpected behavior, anemic documentation and irregularity. (it's getting better, but not fast.)
i guess Google's Fuchsia push is motivated by some other, internal concerns.
This seems good and bad. The prospect of a new, modern operating system is exciting. The system call interface is sensible and it follows modern security best practices (eg. deny-by-default.)
One practical disadvantage compared to Linux is that it's not GPL, so if Google uses it to make a mainstream mobile phone operating system, other vendors won't be compelled to release their kernel sources like they are with Android today, which means a Fuchsia equivalent to LineageOS might not support as many devices.
Also, capability-based security is fine as long as there's some way for the owner of the device to acquire all capabilities. If there is not, it's fundamentally anti-user, since it's treating the user as an adversary. Since most Android devices require aftermarket modifications to get root access, I'm not too hopeful about Fuchsia. If these bullet points are anything to go by and DRM and verified boot are first-class features, it's likely that Fuchsia will have built-in mechanisms that prevent the user from copying protected video content, so it's unlikely that the average Fuchsia powered device would grant the user full privileges.
Whether the user knows it or not, there is still software running on the device that is working in the interests of the vendor and/or the DRMed content creator and against the interests of the user. Yes, most users don't care, but some do. If you were the seller of a hypothetical restricted Fuchsia device, you might not lose any sleep over the users that care. As the potential buyer of the device, I will take user freedom into consideration and I will criticise the device if it's not up to my standards.
Also, users don't care about these restrictions until they do. The user might be completely unaware that there are restrictions on what they can do with the device before they decide to install something like a system-wide ad-blocker (which are becoming more popular) or maybe an app that can download YouTube videos.
The reason most users don't care is that they don't understand what's going on: They've been programmed to believe that law ≥ morality when there exist so many painfully simple - even modern - examples where this cannot possibly be the case.
People used to buy a car with the expectation it last 20-30 years and would not think about buying a car that they had to take to the manufacturer for repairs or aftermarket upgrades, after all: You need your car to get to work, and everyone knew if there was a malfunction and the manufacturer refused to repair it under warrantee (like a broken windscreen) you could at least get a competitive best-price repair from an open market of repairmen. Without this, how could you possibly trust the purchase of a car?
Now they do, and indeed I know people who rotate cars as often as they exchange their phone for the newest version. If the manufacturer won't repair it for free, they can charge as much as they can get away with - far and above the best price -- and the only reason they can do this is because they have a technical monopoly on some secret keys used to perform updates and upgrades.
If there's a user who, given the choice, would protect a manufacturers' "right" to price-gouge them, then they're a fucking idiot.
> People used to buy a car with the expectation it last 20-30 years
I can't speak about all people, in all time periods, but most people in the 1960s/70s in the USA were thinking about keeping their cars for 10 years maximum. Cars were dizzyingly cheap in those days, and a highschool student could work part-time during a single summer and buy a new sports car.
To me, the only thing that has changed between now and then is the price of vehicles, not the expectation that they're disposable.
Being anti-user isn't about providing an overwhelming value to all users of a product, but to make sure that no user ever gets stuck with no way out.
Opera v12 is a great example of that. There is no browser with its feature-set. In purely objective terms all other browsers are strictly inferior when it comes to usability and range of features outside the web rendering core. It also provides a number of data storage features. Now Opera ASA has given up on it, and because it's closed sourced not even small things like changing SSL ciphers can be fixed.
So millions of users were forced to switched to worse alternatives, and some were forced to manually extract their data.
The kick in the butt about this: There's a leak of the source code on the internet, but collaboration on it is nigh-impossible because any site hosting it is breaking copyright law. This despite Opera v12, with the Presto engine, being 100% and entirely abandoned and with the sale of the "Opera Browser" to a chinese malware company, there not even being any way for the public to know who actually owns the rights to v12.
Its as simple as imagining any scenario where your interests are at odds with the oem, the government, or literally any interested party with money and time.
If Verizon wants to sell you a device with GPS but rent you the feature for 10 bucks a month.
If the government wants the privilege of censorship unobstructed by the inherent technical impossibility of controlling every aspect of user owned devices.
If you want to avoid planned obsolescence and use your device longer than 18 months.
If you are a keirig owner if you want to buy the coffee of your choosing.
If you want to refill your ink cartridges.
Any obnoxious thing that people would trivially bypass if they had full control of their own stuff.
The fact that you an otherwise intelligent individual could ask such a staggeringly ridiculous question is why the free market is a worthless answer to any of the above.
There is a reason standards are developed by knowledgable parties rather than hoping that buyers will navigate the quagmire of complicated topics to demand sanity from merchants.
"...the free market is a worthless answer to any of the above..."
Nit: it's not a free market if the buyer doesn't understand the transaction.
What we've seen, especially in the latter half of the 20th century and afterwards, is companies using the complexity of the law to create transactions in which the buyer thinks they're getting a good deal, but in fact they're getting screwed over by lawyers. That's not a free market. That's using government complexity as a club to beat senseless consumers when they don't do things the way you expect them to. It's a form of rent-seeking using the regulatory state.
It's important to understand what it is, otherwise you aren't able to propose any reasonable solutions. For example, throwing even more complexity at the problem in an effort to protect consumers would just make matters worse.
I'm in favor of your approach, just wanted to point out that 1) it's incomplete, and 2) without an understanding of root causes we'll still be in the same spot 20 years from now
No but they care that they can't do the things they want to with the computer (or rather install software that does - or rather ask a technical friend to make the device do the thing). Most users don't think of a phone like device as a computer unfortunately.
They might not know what it is and as a result of that, they cannot care for it, but there's one thing that root access gives which no user would not want: Ad blocking in apps.
>One practical disadvantage compared to Linux is that it's not GPL, so if Google uses it to make a mainstream mobile phone operating system, other vendors won't be compelled to release their kernel sources like they are with Android today, which means a Fuchsia equivalent to LineageOS might not support as many devices.
I would disagree. With the introduction of Android 8 and Project Treble, as long as the userspace OS changes adhere to the HAL contracts, updating to a new OS version should will be considerably easier because there is no need to modify the kernel.
According to the Project Treble lead you can even place AOSP userspace on any Project Treble phone and it would work.
Seems cool that you can pass “handles” to resources like network connections between processes. That could definitely make some server software easier to architect.
Definitely suggest reading through their docs, it's fascinating. One of the features I'm most excited about is storage management.
From "What is ledger?" [0]:
> Each data store is transparently synchronized across devices of its user through a [cloud provider]. Any data operations are made offline-first with no coordination with the cloud. If concurrent modifications result in a data conflict, the conflict is resolved using an app-configurable merge policy.
I'll note that although they use Firebase as the sync provider, it should be fully possible to host your own if you wish to avoid the cloud.
Keeping stuff in sync can be a huge pain sometimes, especially when you're just dealing with scattered files. I like having this functionality as part of the core system, and getting developers to handle our multi-device world.
The Ledger design docs are worth reading, they're short and approachable. Architecture [1] explains how it's implemented, and Conflict Resolution [2] covers how to handle when things go wrong.
Judging from google's track record with android, chrome, and youtube, I'm not very excited for this project. As much as I would love some innovation in the OS world, I find myself hoping that this system does not catch on.
Google has not proven themselves to be a developer/enthusiast friendly company. It feels like they look down on the rest of the world while locking systems behind restrictive(cumbersome) APIs to protect the unenlightened from themselves. Maybe that design philosophy is okay for services/apps but it has no place at the system level IMO.
Who knows maybe the fuchsia team doesn't share that philosophy, but I doubt it.
142 comments
[ 2.6 ms ] story [ 207 ms ] threadTo name a few: UNICOS, NeXTStep, HP-UX, RSTS, ULTRIX, VMS, AIX, SunOS, Solaris, IRIX, A/UX, MacOS, ProDOS, Amiga OS.
They were the first to do push based email and IM in a context outside of business AFAIK.
When the iPhone was announced in 2007, they realized that on-screen keyboards and multi-touch control were the future, so they did a complete redesign, moving to an interface similar to the iPhone. Here's a quote from one of their engineers talking about the iPhone announcement:
“As a consumer I was blown away. I wanted [an iPhone] immediately. But as a Google engineer I thought ‘We’re going to have to start over’” Chris DeSalvo said. “What we had suddenly looked so… nineties. It’s just one of those things that are obvious when you see it.”
http://bgr.com/2013/12/19/original-iphone-android-story/
[Every time this story is told, I like to remind - note how fast Google were able to pivot / adapt when Microsoft with their crazy resources and Engineering might took way longer. (Even beyond that MS had to change the way apps were developed for WP.) Fact is Google/Danger/Android were in a fundamentally good position mobile OS design wise way before the iPhone. After the iPhone - they looked at the possibilities of multi touch soft keyboard UI and were able to get there and surpass fairly fast.]
But even adjusting for that it took MS 3-4 years after the iPhone to just get Windows Phone 7 out, and that was also clearly a rushed release, because they had to throw everything out for Windows Phone 8.
I believe after rage from Jobs they left out multitouch zooming at first and did something double tap based, even though MS had done it before Apple (without capacitive) and Minority Report has shown it.
Not having to deal with Linux's refusal of maintaining a stable driver API and ABI for a start. The number one reason that stops Android from getting updates on smartphones is that hardware manufacturers don't want the burden of constantly making small changes to their proprietary drivers to follow new linux kernel changes, something that they don't have to worry about when they make drivers for, say, Windows PCs.
Even Google's own phones, like the Nexus and Pixel, are stuck because of this. They receive updates faster than non-Google phones, but they do not receive more than 2 years of feature updates (with an additional year of security updates courtesy of Google backporting fixes from newer android builds to the older kernel).
Fuchsia is not going to be burdened by Linux kernel dev policies of constantly breaking APIs and their requirement for driver developers to open source their stuff, obey the kernel coding preferences (like when they rejected AMD's driver because of the HAL) to get them mainlined so that they can finally be kept in a maintained state.
And as a result, its drivers will be far lower quality and much less stable, and the system as a whole will pay the complexity cost of working around the awful code that hardware vendors churn out.
I don't buy it. Windows provides stable driver ABIs and works just fine. A lot of the changes to the Linux driver API are gratuitous, and isolating driver development from the whims of the core won't actually hurt.
If anything, a stable ABI will help, since a smaller, well-defined boundary between the kernel core and drivers allows for things like Vulkan-like validation layers, better debugging, better sandboxing, and even transparent thunking to userspace.
Will some drivers be shitty? Of course. But many drivers won't be, and drivers will be less shitty overall when they can spend more time on being good drivers and less time dealing with GFP_FOOBAR becoming GFP_BARFOO.
Conventional wisdom is that backward binary compatibility i some huge unreasonable burden. This conventional wisdom is wrong; if anything, maintaining a stable ABI imposes some discipline that focuses development effort and that forces you to modularize your system.
Windows also has a more robust architecture where it matters, like the fact that a GPU driver crash doesn't kill the user session (windows can reload that subsystem while keeping the user session running since Vista), whereas it can either kill Xorg or just outright freeze the system on linux. A very useful way to architect the OS, although I've only experienced it on Vista and had more stable GPU drivers from 7 onward.
Depends on the driver, but often they are buggy and will never be updated for the life of a device. Once a device has been sold the manufacturer doesn't care about support. Most linux CVE's are in drivers, imagine how many are lurking in the binary blobs of random third parties?
That's why we should sandbox drivers as much as possible! I'm a big fan of punting a lot of driver work to userspace. How are we supposed to do that if drivers are allowed to use the entire Linux kernel internal API and do whatever they want? How can we possibly isolate a driver that thinks it has the right to take mmap_sem and twiddle PTE bits?
The key new "feature" of Fuschia is that its stable ABI makes closed-source drivers easier to write in the short term, relative to Linux. As a result, the vast majority of Fuschia drivers will be closed-source. Don't you agree?
I believe supporting a stable API and closed-source drivers will result in a technically inferior, more complex, less stable kernel. The Linux model of including all the drivers in a single open source codebase, where the drivers can be refactored and improved along with the rest of the kernel, is a genuinely superior way to develop a kernel, which produces a genuinely technically superior product. I just hope Google realizes this before they sink too many millions into Fuschia.
Anyway, what I said is that sandboxing isn't a substitute for open-sourcing. They are complements, not substitutes.
FUD. L4 is the most widely deployed kernel in the world.
> Anyway, what I said is that sandboxing isn't a substitute for open-sourcing.
Given reality, something must substitute for open source drivers. Sandboxing is certainly the obvious choice.
Linux is quite real, I assure you.
[1] https://developer.microsoft.com/en-us/windows/hardware/downl...
I strongly disagree with this statement. Windows is a buggy mess on all levels from GUI down to kernel. It is a consensus of technically enlightened people
Just thinking of how painful taking a dependency on guava can be makes me think this claim is satire. :(
If it wasn't in the Java ecosystem, it might not feel weird. But the Java community had maintained backwards compatibility for a long long time. Guava promises, what, a year?
And for internal use, that is fine. I have seen some poor sods introduce it as a dependency of theirs, which can lead to frustrating upgrade cycles.
Edit to add: the Jakarta libraries are also fairly well designed. To the point that most things in guava were already there.
i.e the "why" behind the design they've chosen.
For a moment there I thought you meant the X Windowing system.
That may seem quite irrelevant, but if I'd like someone to reinvent the OS, I'd like it to be people that have taken a stance in favour of stable, simple, straightforward software (the people behind Pinboard, Tarsnap; djb... just to name a few).
Even more surprisingly, Inbox (by Google) sorts everything by last message (last time I checked, which was a long time ago).
Notably, small teams can dictate priorities that don't scale at the level of tens of thousands of engineers.
but, who or what gives Google the capability to write a new OS? (e.g. are they currently employing a group of highly experienced, top-notch OS engineers? have they formed these engineers into an effective, efficient team? etc.)
These slides from the Chrome OS Internals [0] talk provide a good overview.
[0] https://events.linuxfoundation.org/sites/events/files/slides...
For example, you still cannot safely use any third-party keyboard on Android. Because Google refuses to give users a way to block internet access for individual apps, and third-party keyboards by definition can read out your passwords and everything you type.
Would just as well be helpful for all kinds of other apps. I'd be much less concerned about giving my camera app permission to take pictures at any point in time, if I knew that it can't actually upload those to anywhere. But I can't. I have to blindly trust my camera app for no reason other than Google not wanting to give up potential ad revenue.
If their main point was to get rid of GPL in kernel, and low level userspace, their main point is bad.
When you look at the Fuchsia OS repositories in Github and select these by language the overwhelming bulk are C++. Regarding the languages you cite: there are some non-trivial parts in Go; the Fuchsia package manager, for instance. There are several bindings to certain key parts of the OS provided for Rust, but no actual Rust components that I can see. Python is used for some build and packaging utility type stuff. Kotlin is provided with one binding library with four whole commits.
Regarding two others mentioned in wikipedia; Dart is actually more prominent than Go, Python, Rust and Kotlin combined. C has lots of binding libraries, but only a pair of boot loaders appear to be core components, plus a fortune stub.
[0] https://github.com/fuchsia-mirror?utf8=%E2%9C%93&q=&type=sou...
In the spirit of HN though this comment basically guarantees its success, right?
Could expand on where it suffers? I've been playing around with Rust in the embedded space (nothing serious at all); I find it to be as elegant in a nonstd situation as it is in standard high level app development.
> and suffers from a lot of the same classes of problems C++ does,
What are those classes of problems? C++ never offered a safe alternative to C, but did offer some eases of use and stronger typing over C.
Rust on the other hand has a huge amount to offer over C. At no point in my Rust work do I ever wish I was working with C, quite the contrary. But I like strongly typed languages, Rust is definitely not for those that dislike types.
By "the embedded space" do you mean "devices running Linux with Rust in userspace?" Because that's much higher level than what I'm talking about, and has very different design concerns from those of a general purpose operating system.
My main beef with Rust for low level development is that Rust is way more complicated than it should be. IMO for serious low level programming Rust should have 1/10th the featureset. It also has issues dealing with the weird data structures that tend to come up in low level contexts in my experience. Rust also has the shiny fad status working against it IMO. If, say, 5% of C hackers understand low level programming and/or kernel hacking, then maybe 0.5% of Rust hackers do (if that).
>What are those classes of problems? C++ never offered a safe alternative to C, but did offer some eases of use and stronger typing over C.
It comes back to complexity and typing. There's nothing wrong with strongly typed languages (of which C is a member), but I strongly dislike object oriented languages and paradigms. Especially in low level contexts it's like forcing a square peg into a round hole. Other features C++ brings to the table like operator overloading and templates are antifeatures, doubly so in a kernel hacking context. Many of the same patterns of unnecessary complexity introduced by C++ are also present in Rust.
C is boring, but it's also transparent and straightforward. Ergonomics takes a backseat to simplicity in C, which is a compromise I'd take any day.
Rust itself is so inherently different from other a language like C that it takes a long time to truly understanding lifetimes and the borrow checker to the point where you are actually making use of the languages features.
The straightforwardness of C is really where it shines, and for me at least Rusts biggest upside is also its biggest downside, because learning to write good Rust is not an easy process.
No, I mean TockOS with the Hail dev board: https://www.tockos.org/blog/2017/introducing-hail/
> Rust is way more complicated than it should be
People often make this statement, but I don't know exactly what it means. The type system is great for writing finite state machines, which I'm finding to be a nice quality for the toy programs I've written on Tock.
> Rust also has the shiny fad status working against it IMO.
Rust is 2 years into it's stable life. It's young, will it ever exceed the number of lines written than C or C++, almost definitely not, but I wouldn't dismiss it off-hand because people like it, there might be a good reason for that.
> If, say, 5% of C hackers understand low level programming and/or kernel hacking, then maybe 0.5% of Rust hackers do (if that).
I wonder about this statement. I've noticed quite a large number of people in the community working with Rust in the embedded space. According to the people who responded to the Rust survey this year, https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Resul..., it was nearly 17%.
> C is boring
I've met more undefined behavior that makes me not agree.
> and straightforward.
:/
> People often make this statement, but I don't know exactly what it means.
I can't speak for op, but you're right: people often make this statement. I'll try to explain what I might mean:
C is way more complicated than it should be.
The things we want in a language are tools that allow us to tell the computer what to do, but because people are bad at that, language design is taking us in the direction of telling the computer what we mean so it can tell us whether we're talking gibberish or not.
I don't need a type system. I don't need "warnings" about converting floats to chars: I know what I'm doing and why. I have a good idea what kind of machine code the compiler is producing, and yes: I often objdump to make sure.
If I need a FSM, I'll use erlang. If I need any kind of data processing, I'll probably use K/Q where I can. I can write some fast stuff in C where I need it. If I just need to bosh some stuff together I have perl. Maybe I want to fantasize about a DSL? It'll probably be a lisp or a forth. If I wanted a strong type system for units I want to get from some model nerds, I'll use OCaml.
I don't see the point in Rust when doing these things takes more code and runs slower, and worse:
> Rust is 2 years into it's stable life. It's young.
I got burned by Python when it was" two years into its stable life" sometime around 1.5 and again around 2.2, and so I hesitate even looking at rust unless in a decade it can still run and compile rust programs written today.
This whole "let's rewrite everything in rust" is good practice. I'm watching you guys do it, and I know afterwards you'll try to beat the performance I'm getting in other languages.
Once you're writing programs that are smaller and faster than me, then we'll probably talk.
> C: I've met more undefined behavior that makes me not agree.
I don't write C like most people, so perhaps I don't have trouble with it like most people. My C programs don't leak memory or crash, and I tend to use a belt+braces approach to security that is very difficult in languages without good multiprocess support.
No, you don't.
Regardless of your skills and seniority (I'm guessing pretty junior with this kind of hubris), there will come a time where you will make mistakes that can be caught by a good compiler. You want this compiler at your side, and the more statically typed your language is, the more robust your code will be.
> Once you're writing programs that are smaller and faster than me, then we'll probably talk
What a strange metric. Assembly language would probably meet these requirements but surely, you would not consider it.
If you check their profile their site suggests that have ~15 years of experience.
I've been programming professionally for almost thirty years at this point.
That's admittedly long enough to get some peculiar ideas about programming, but there's a certain kind of person that thinks "statically typing" is a panacea for programming mistakes -- or even that there's a single solution for anything at all...
Static typing is not perfect but it's better in all respects than dynamic typing.
... unless of course that solution is static typing.
> Static typing is not perfect but it's better in all respects than dynamic typing.
Except performance, of course: A dynamically-typed language is at the top of the STAC-M3 benchmarks for time series data processing.
Oh and defect count: Qmail has the lowest defect count of any source-available software in the last twenty years and it's written in C.
So I guess static typing is better unless you want correct code that runs quickly, which unfortunately is important to me.
Static languages are universally recognized and demonstrated as faster than dynamically typed languages, even if you claim to have found one rare exception. This is not just an opinion, it's scientific and objective fact.
But please share with us that code that runs more quickly on a dynamic language than a static language for you, I am genuinely curious (and equally curious to find out if you just made this up).
That makes sense, since your background isn't in high performance computing and you can't use google:
https://stacresearch.com/m3
The first item on the list is written in an interpreted language.
> This is not just an opinion, it's scientific and objective fact.
I've just demonstrated two counterexamples, so it's clearly not "scientific and objective fact". Indeed I've never met anyone who even thought Rust would outperform an experienced C programmer in programmer speed, program runtime, and low program size.
Could I see the code? Because I'm pretty sure you can't write a fast numeric code without the knowledge of which type you will get on input. That's why fortran still rocks and we do nat have anything beyond fortran, c and c++ in the field of computation.
You're not far off.
The first trick is that even though `x` can have any type, `x[4]` and `x[5]` must have the same type. This kind of array whilst uncommon in Python is extremely common in array languages. Array languages tend to have a lot of vector operators (and so therefore are very competitive users of the AVS512 instruction set) which tend to be very fast. Programmers of array languages also tend to avoid things like loops and branches -- indeed you might enjoy http://nsl.com/ if you want to expand your mind a bit on that point.
The second trick is that an interpreter can be made very small. If you can get your entire program and the interpreter into L1 then you do not stall the CPU while your program fetches various parts of itself from memory. This is a trick languages like Fortran and C and C++ don't miss per-se, a very experienced programmer can usually identify the hotspots and optimise the hotpath for these things, but it is very time consuming to do this when your entire program is the hotpath!
Do you actually have anything to show to back up your claim? Anything at all?
Except the first paragraph:
The STAC-M3 Benchmark suite is the industry standard for testing solutions that enable high-speed analytics on time series data, such as tick-by-tick market data (aka "tick database" stacks).
I'm not going to bother any further with such an obvious troll.
Good luck dude. Wish you the best.
Because they're not on the page, so I can only conclude you made this up.
Even if you use byte arrays everywhere aren't you still documenting the datatype somewhere? Or are you telling me you have them all in your head? How do you remember that ptr[0x3f] refers to the name field of the struct? At the very least you'd turn those magic numbers into a constant. (#define CUSTOMER_NAME_FIELD 0x3f) and suddenly you've reinvented structs...
Types are statically enforced documentation that is trivial to create. Yet I see people constantly wanting to avoid this small triviality to "be more productive".
In your case you should just use assembly and shut up.
- how many instructions execute between an interrupt trigger and your vector getting executed
- if some piece of data is getting stored in text, data, or runtime space (harvard v single address spaces can make things weird)
- minimizing or not using a stack to avoid clobbering your puny memory
- other misc. things that even hardware vendors don't make easy (or sometimes possible) to find
Honestly I don't think that even C is great for these things, but I mostly blame hardware vendors/architects for this situation. They all like to roll their own standards for documentation, language interfaces, etc. Sometimes it feels like a competition to see who can come up with the worst.
So more of the "Arduino like" embedded space. That also has little to do with the design constraints of a general purpose operating system.
>People often make this statement, but I don't know exactly what it means. The type system is great for writing finite state machines, which I'm finding to be a nice quality for the toy programs I've written on Tock.
Rust gets new features daily [1]. C gets new features every decade if we're lucky.
>I wonder about this statement. I've noticed quite a large number of people in the community working with Rust in the embedded space. According to the people who responded to the Rust survey this year, https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Resul..., it was nearly 17%.
Embedded space != kernel hacking, as I've already pointed out.
[1] https://github.com/rust-lang/rfcs/commits/master
Does it not? It's the same issue around no-stdlib, stricter sense of allocated memory, etc. If it isn't something that I can extrapolate from you'll have to explain better why. It's been a while since my CS courses on operating systems.
> Rust gets new features daily [1]. C gets new features every decade if we're lucky.
Yes, this is an age thing. I'm sure in it's infancy, C was gaining features and changing rapidly. For example, C changed significantly early on it's syntax from K&R to Ansi. C compilers have to support that.
It's reasonable to say that the language isn't ready for your use, but the features that are being gained are all related to areas around ease of use of the language, making it easier to get started and lower the initial learning curve. They seem important. By the way, you linked to the RFC repo instead of the language repo: https://github.com/rust-lang/rust/commits/master. The language does have a lot of features that make it into the nightly branch, but those take a long time to bake until they're promoted to stable.
> Embedded space != kernel hacking, as I've already pointed out.
I thought we were talking about low-level programming, not explicitly Kernel hacking. Yes, Arduino and it's ilk are definitely not full OS'.
For actual Kernel hacking in Rust, there is:
- https://github.com/redox-os/redox
- https://intermezzos.github.io/book/
- https://os.phil-opp.com/
All of those projects seem very interesting. For Linux drivers, there was this exploratory project I saw a while back: https://github.com/tsgates/rust.ko (hasn't been touched in a while).
So people are doing it and seem to be enjoying it.
No, because a general purpose OS has to do that and effectively, securely, and performantly manage userspace access to those resources (including hardware resources, which you didn't mention). It also has to facilitate secure and performant interactions between userspace programs. Beyond kernel hacking you also have to do some serious work on userspace design, especially if you have a microkernel. This is an entirely different domain than embedded programming usually deals with.
>Yes, this is an age thing. I'm sure in it's infancy, C was gaining features and changing rapidly. For example, C changed significantly early on it's syntax from K&R to Ansi. C compilers have to support that.
Sure, but that doesn't make my argument less compelling. Rust may follow the same path but that's years out and IMO they've already gone too far.
>The language does have a lot of features that make it into the nightly branch, but those take a long time to bake until they're promoted to stable.
But not before the ecosystem runs with it and ships packages that require you to use a nightly compiler to be productive, in my experience. Not to mention that several projects still build the compiler themselves!
I have some opinions about projects like Redox but I'm out of time.
https://fuchsia.googlesource.com/netstack/+/master
The design also seems extremely sensible and modern: Everything is namespaced and sandboxed (there's no default "/"), everything is an "object" (sounds similar to Plan 9's file descriptors), capabilities from the ground up, standard RPC between OS components (FIDL, similar to COM or XPC), built-in package management (looks like apps aren't globally installed by unpacking archives, but rather they're run directly from packages, and the process gets the archive file system mounted in its namespace), etc.
While Google seems to be aiming for phones, I wouldn't surprised if this ends up as an option on Google Cloud Platform in a few years' time.
In XNU, things like file systems, graphics and device drivers are all running in kernel mode, in the same address space as the kernel. The Windows kernel has the same design -- it's designed as a microkernel, with separate modules internally that communicate via a form of IPC, but everything is running in one process (as opposed to a real microkernel architecture where file systems etc. are userland processes).
With XNU, Apple forked Mach 3.0 and have been making a lot of changes to it over the years, even though Mach itself has progressed since then. On the other hand, XNU inherited Mach's high syscall overhead (considerably higher than Linux), and to my knowledge Apple has moved a lot of stuff into ordinary syscalls rather than Mach messages to remove this overhead.
Edit: Interestingly, around the time before Leopard, when Darwin was still a thing, there was a research project called Darbat [1] that tried to supplant parts of Mach with L4, a more modern microkernel, and actually run XNU as a userland process on top of it. Unfortunately, nothing came of that project.
[1] https://arstechnica.com/staff/2006/06/4407/
[1] https://en.wikipedia.org/wiki/User-Mode_Driver_Framework [2] https://docs.microsoft.com/en-us/windows-hardware/drivers/wd...
The nice thing about Plan 9's everything-is-a-file setup is that everything has the same file-like interface. Saying everything is an object does nothing to convey any sort of standard interface.
https://marc.info/?a=111558719100068&r=1&w=4
http://rmitz.org/carmack.on.operating.systems.html
Rob Pike replies here[1] that direct framebuffer access and networking are easy to get as new devices, although they need to be made available by the kernel. The "everything is a file" mantra doesn't fail, why would it?
In the second link, Carmack just notices that plan9 is pretty dead, and we all know it is :)
[1] https://marc.info/?l=9fans&m=111558695515846&w=4
Everything is a file is how X Windows over network kind of works.
For real graphics performance that can match other systems, xshm and DRM had to be developed.
According to Google, Fuchsia is designed for:
modern phones and modern personal computers with fast processors, non-trivial amounts of ram with arbitrary peripherals doing open ended computation.
i guess Google's Fuchsia push is motivated by some other, internal concerns.
One practical disadvantage compared to Linux is that it's not GPL, so if Google uses it to make a mainstream mobile phone operating system, other vendors won't be compelled to release their kernel sources like they are with Android today, which means a Fuchsia equivalent to LineageOS might not support as many devices.
Also, capability-based security is fine as long as there's some way for the owner of the device to acquire all capabilities. If there is not, it's fundamentally anti-user, since it's treating the user as an adversary. Since most Android devices require aftermarket modifications to get root access, I'm not too hopeful about Fuchsia. If these bullet points are anything to go by and DRM and verified boot are first-class features, it's likely that Fuchsia will have built-in mechanisms that prevent the user from copying protected video content, so it's unlikely that the average Fuchsia powered device would grant the user full privileges.
I don’t get this sentiment at all. The vast majority of users don’t know what root access is, let alone care about it.
Also, users don't care about these restrictions until they do. The user might be completely unaware that there are restrictions on what they can do with the device before they decide to install something like a system-wide ad-blocker (which are becoming more popular) or maybe an app that can download YouTube videos.
The reason most users don't care is that they don't understand what's going on: They've been programmed to believe that law ≥ morality when there exist so many painfully simple - even modern - examples where this cannot possibly be the case.
People used to buy a car with the expectation it last 20-30 years and would not think about buying a car that they had to take to the manufacturer for repairs or aftermarket upgrades, after all: You need your car to get to work, and everyone knew if there was a malfunction and the manufacturer refused to repair it under warrantee (like a broken windscreen) you could at least get a competitive best-price repair from an open market of repairmen. Without this, how could you possibly trust the purchase of a car?
Now they do, and indeed I know people who rotate cars as often as they exchange their phone for the newest version. If the manufacturer won't repair it for free, they can charge as much as they can get away with - far and above the best price -- and the only reason they can do this is because they have a technical monopoly on some secret keys used to perform updates and upgrades.
If there's a user who, given the choice, would protect a manufacturers' "right" to price-gouge them, then they're a fucking idiot.
I can't speak about all people, in all time periods, but most people in the 1960s/70s in the USA were thinking about keeping their cars for 10 years maximum. Cars were dizzyingly cheap in those days, and a highschool student could work part-time during a single summer and buy a new sports car.
To me, the only thing that has changed between now and then is the price of vehicles, not the expectation that they're disposable.
Users don't understand what a CAN bus is, but open access to CAN buses is better for anyone who needs to maintain a car.
For cars, software and generally living on this planet, the more one doesn't understand, the more they'll pay.
Opera v12 is a great example of that. There is no browser with its feature-set. In purely objective terms all other browsers are strictly inferior when it comes to usability and range of features outside the web rendering core. It also provides a number of data storage features. Now Opera ASA has given up on it, and because it's closed sourced not even small things like changing SSL ciphers can be fixed.
So millions of users were forced to switched to worse alternatives, and some were forced to manually extract their data.
The kick in the butt about this: There's a leak of the source code on the internet, but collaboration on it is nigh-impossible because any site hosting it is breaking copyright law. This despite Opera v12, with the Presto engine, being 100% and entirely abandoned and with the sale of the "Opera Browser" to a chinese malware company, there not even being any way for the public to know who actually owns the rights to v12.
If Verizon wants to sell you a device with GPS but rent you the feature for 10 bucks a month.
If the government wants the privilege of censorship unobstructed by the inherent technical impossibility of controlling every aspect of user owned devices.
If you want to avoid planned obsolescence and use your device longer than 18 months.
If you are a keirig owner if you want to buy the coffee of your choosing.
If you want to refill your ink cartridges.
Any obnoxious thing that people would trivially bypass if they had full control of their own stuff.
The fact that you an otherwise intelligent individual could ask such a staggeringly ridiculous question is why the free market is a worthless answer to any of the above.
There is a reason standards are developed by knowledgable parties rather than hoping that buyers will navigate the quagmire of complicated topics to demand sanity from merchants.
Nit: it's not a free market if the buyer doesn't understand the transaction.
What we've seen, especially in the latter half of the 20th century and afterwards, is companies using the complexity of the law to create transactions in which the buyer thinks they're getting a good deal, but in fact they're getting screwed over by lawyers. That's not a free market. That's using government complexity as a club to beat senseless consumers when they don't do things the way you expect them to. It's a form of rent-seeking using the regulatory state.
It's important to understand what it is, otherwise you aren't able to propose any reasonable solutions. For example, throwing even more complexity at the problem in an effort to protect consumers would just make matters worse.
I'm in favor of your approach, just wanted to point out that 1) it's incomplete, and 2) without an understanding of root causes we'll still be in the same spot 20 years from now
Is a minority of users not users? By this logical, we can remove all accessibility features, because disabled users are only a minority.
I would disagree. With the introduction of Android 8 and Project Treble, as long as the userspace OS changes adhere to the HAL contracts, updating to a new OS version should will be considerably easier because there is no need to modify the kernel.
According to the Project Treble lead you can even place AOSP userspace on any Project Treble phone and it would work.
when will google toilet arrive ?
trust them for everything
From "What is ledger?" [0]:
> Each data store is transparently synchronized across devices of its user through a [cloud provider]. Any data operations are made offline-first with no coordination with the cloud. If concurrent modifications result in a data conflict, the conflict is resolved using an app-configurable merge policy.
I'll note that although they use Firebase as the sync provider, it should be fully possible to host your own if you wish to avoid the cloud.
Keeping stuff in sync can be a huge pain sometimes, especially when you're just dealing with scattered files. I like having this functionality as part of the core system, and getting developers to handle our multi-device world.
The Ledger design docs are worth reading, they're short and approachable. Architecture [1] explains how it's implemented, and Conflict Resolution [2] covers how to handle when things go wrong.
[0] https://fuchsia.googlesource.com/ledger/#what-is-ledger
[1] https://fuchsia.googlesource.com/ledger/+/HEAD/docs/architec...
[2] https://fuchsia.googlesource.com/ledger/+/HEAD/docs/conflict...
Google has not proven themselves to be a developer/enthusiast friendly company. It feels like they look down on the rest of the world while locking systems behind restrictive(cumbersome) APIs to protect the unenlightened from themselves. Maybe that design philosophy is okay for services/apps but it has no place at the system level IMO.
Who knows maybe the fuchsia team doesn't share that philosophy, but I doubt it.