Fuchsia OS Introduction
bzdww.com
bzdww.com
- Vulkan first graphics interfaces. I mean, OK. Not that I'm in love with this overly complex API, but fine.
- No OpenGL support. I guess this is where world is moving
- No POSIX support. Quite a bit of game engines rely on it, oh well, when google cared about developers
- Nothing about sound (my personal thing)
As game developer working with Android was unpleasant to say the least. For example sound - android has like 4 sound systems, all of them (except simplest one available from Java side) are not fully implemented, and swarming with compatibility bugs across manufacturers and android versions. Oh, not to say that they introduce new one once in a while, with new version adoption slower than a sloth.
I get that Google engineers enjoy rewriting things they don't like, but, come on. Fix existing first. Don't change APIs on us - not everyone has extra million of $$$ to throw on a project to refactor it every time Google decided that they want shiny new thing, which as result is broken too but in different ways. OK. I admit, I exaggerate, but it seems like tough times for game engines (besides super hyped ones like Unity or Unreal, which also has no problem throwing tens of millions).
Note about OpenGL support: I'm pretty sure they'll drag it in by porting ANGLE library which is currently actively worked on. Compatibility layers for Vulkan are getting momentum, but I hope they'll join forces with MoltenGL/VK instead of making their own worse analog.
It wouldn't make sense for the to completely throw away all Android apps ever and rewrite all the APIs from scratch.
The fact that graphics drivers exist as user space services should reduce latency by minimizing the need for capabilities, the equivalent of a system call which requires an expensive system call/trap handling routine in std linux (for example).
This is presumably to support an architecture with direct access to a GPU where the main CPU scheduler doesn't have to schedule a round trip of data from main CPU to data bus to GPU and back, compared to std linux on std hardware architecture, for example which will support this overall design to decrease latency and advance open source graphics development in a user space setting.
- No OpenGL support. I guess this is where world is moving
Vulkan is still built off of OpenCL, which is kernel code designed explicitly for the GPU. While not technically OpenGL, it is a more direct interface architecturally with the hardware and there are plenty of engines working on vulkan support. Consider there are other advantages to using a graphics driver than just OpenGL (like parallel computing and abstracting large data sets into matrices that map nicely into GPUs) and optimize based on this assumption and it is not as unreasonable as it sounds.
- No POSIX support
"Full POSIX compatibility is not a goal for the Fuchsia project; enough POSIX compatibility is provided via the C library, which is a port of the musl project to Fuchsia. This helps when porting Linux programs over to Fuchsia, but complex programs that assume they are running on Linux will naturally require more effort." - https://lwn.net/Articles/718267/
- OpenGL should be a library. This is just going to make OpenGL development easier in the long run. Right now there are too many OpenGL implementations and the differences matter. Running one OpenGL library on top of N different Vulkan implementations is miles better than running on top of N different OpenGL implementations.
- POSIX can be a library too. It doesn’t have to be provided by the kernel. People have been strapping POSIX layers on top of things for ages. This was originally how Mach worked. You can still do weird things on iOS and macOS “below” the POSIX layer (although most POSIX syscalls are just provided by the kernel).
You talk about how hard it is to change APIs… and how much you hate to refactor things every time Google decides they want the shiny new thing. But POSIX is rooted in the 1970s. It sucks. It’s about time to try something new. The entire POSIX model is based around the idea that you have different people using the same computer and you don’t want them to accidentally delete each others’ files. There are a ton of APIs in POSIX which are straight-up shit, like wait(). Sandboxes are unportable and strapped-on, using arcane combinations of things like chroot and cgroups.
Let’s give people a chance to try out something new. Unix is somewhere around 50 years old now. OS research is dying out. Make it easier to run untrusted programs.
I was learning about kernel dev around the same time as trying to understand how conditional execution and speculative execution worked as a result of really trying to understand every step that happens when a system call hands something to the kernel and the kernel does something with it and hands it back to the system.
I kept asking but alot of supposed linux nerds I spoke with couldn't tell me how the kernel and user space truly handed off data or negociated memory with eachother, leaving me drawing out trap handling routines on a posterboard penciling in gdb dissassembles of memory for system call source code, feeling dumb for not knowing, meanwhile we all find out about Spectre and Meltdown and that really there is not a secure handoff without significant performance degradation and/or increased sandboxing for things like the browser, etc.
And of course what is the root of the issue here? The root of the issue is that linux is too deeply integrated into monopolized hardware architectures, which is perhaps why AMD's stock price skyrocketed the day Spectre and Meltdown came out, when we found out the only mitigation for this legendary security vuln in the near future, will cost a 30% reduction in performance across the board with intel as opposed to much less with AMD given the AMD architecture was less prone to exploiting the vulnerabilties around speculative execution.
The more I learned about these things plus issues with other basic functions like wait() ot strcpy() or in general the lack of protections around C, the more I entertained the idea of looking for alternative operating systems. The networking stack in Fuschia is written in Go for example. While I don't know much about Go, can it be worse than C when it comes leaving it up to almost every developer to take care of their own garbage collection and what the performance and security implications of this are?
Magenta is designed to be modular enough in nature to withstand the waves of hardware architectural evolution coming and given we are approaching 5nm development (the theoretical limit of how small a transistor gate can be before we can no longer control interactions/flipping a transistor switch due to quantum interaction), and this is not far off, Intel already has 10nm in production and probably others now as well (its been a bit since I checked) then to quantum computing:
Because quantum computing (this is debatable and I know the least about this) is not ready for mass production, particularly on the mobile scale, my conjecture is once we reach the theoretical limit of how small a transistor will be, designs will turn to optimizing for performance in every other way we can without relying on powerful processors to accomodate for memory bloat or endless dependencies (yes I also pray this requires javascript modules to be better or die out but thats a long range dream).
Meanwhile AMD gains ground post spectre and meltdown. So, in summary, there are alot of other options to consider than just optimizing for POSIX forever.
Therefore, I am glad there is a push to explore alternatives. I feel as though anyone who thinks it's not potentially beneficial to explore POSIX alternatives based distros does not work with Unix based systems in any kind of depth on a daily basis, but if someone does, and you think Linux for example, is the best operating system in the world and can't be improved upon outside of its defining protocols, then I would love to hear from you on this thread. I am not nearly as experienced as most people who work with Linux, but I can say that most I have interacted with it view it as a love hate relationship for many of these very reasons.
You can also see this trend of unhappiness with Linux OS defaults out in the wild outside of google.
More and More and serious applications are looking to bypass userspace application development to be either more secure, customize, most often for the purpose of if not security, to optimize performance for the things we use to consider the std linux kernel somewhat good at.
Here are few varied examples I can think of off the top of my head anecdotally when trying to solve everyday problems for users with linux, but I am sure there are many more:
1. Dropbox bandaid attempts to customise network schedulers usually handled in kernelspace due to performance issues: https://blogs.dropbox.com/tech/2018/03/meet-bandaid-the-drop...
2. Wiregaurd is an example of a VPN where communication negociation is handled more and more in the kernel, because traditional vpn designs have left TLS handoffs in userspace (what is the point of userspace anymore for serious application development when this is the trending security default): https://www.wireguard.com/
3. Sysdig implements epf functionality to allow for sysadmins and devops engineers to customise and or secure in ways we don't trust or consider the default linux operating systems userspace/kernel space design to do anymore: https://dig.sysdig.com/c/pf-blog-introducing-sysdig-ebpf
Dig into the worlds of Burroughs B5500 (now Unisys ClearPath), IBM OS/360 (now IBM z), IBM OS/400 (now IBM i), and the now gone Mesa/Cedar, Oberon, Active Oberon, SPIN OS, Topaz OS, Mac OS/Lisa, Singularity, Midori, Inferno, ...
Google is not stupid, they are not going to deprecate android overnight and replace it with Fuschia, this operating system has been in the works open source, you can see the commits on github for atleast two years I think more, and there will clearly be many iterations of its development to come with increasing adoption each time as people make money on the platform, just like with Android which took years before it reached the threshold of 50% use compared to iphones and no iphone video games developers that I know of starved to death trying to adapt to this change. The drama on this thread about api changes are significant for sure and I understand Google redacts API's or suddenly starts charging for them in a way that makes small companies close up shop overnight (like google maps for example) but it is not a justification to pretend that objective limitations around Moore's Law and the need for competition in computer hardware is forcing companies who have experience in both spaces to reconsider kernel development at a more fundamental scale.
Still, it will be a scenario similar to ChromeOS. How many people are buying ChromeOS devices to run Android apps?
Burroughs B5500, first OS written in an high level systems language (ESPOL, later NEWP) in 1961, 8 years before C came into existence. Already used compiler instrics instead of Assembly, and the concept of unsafe code blocks.
IBM OS/360, famously introduced the concept of containers, alongside IBM OS/400, also has language environments, think common VM for multiple languages.
IBM OS/400, originally written in a mix of Assembly and PL/S, uses the concept of managed runtime with a kernel JIT called at installation time, and uses a database as filesystem.
Mesa/Cedar, system language developed at Xerox PARC, using the same IDE like experience similar to their Smalltalk and Interlisp-D workstations. Uses reference counting with a cycle collector.
Oberon and its descendants, Niklaus Wirth and his team approach to systems programming at ETHZ, after his 2nd sabaticall year at Xerox PARC.
Mac OS/Lisa, these first versions of Apple OSes were written in Object Pascal, designed in collaboration with Niklaus Wirth, whose extensions were later adopted by Borland for Turbo Pascal 5.5.
Singularity/Midori, the research OSes designed at MSR, largely based on .NET technologies.
Inferno, the actual end of Plan 9, using a managed language for userspace, Limbo.
SPIN OS/Topaz OS - Graphical workstation OSes for distributed computing developed in Modula-3
Only Google changes rules of the game on developer. They do not realize that they are make •a platform•, not a product. Stable, comfortable platform that software runs on. I honestly don't give two cents about all their struggles to make "a better OS". OS is to launch apps, and making those apps is a miserable experience, where I have full time people just to keep up with Google 'improvements'. Somehow every other platform is fine. I hardly had to change code written 10 years ago for iOS, for consoles or Windows - not at all! But Google keeps making their own special PhD driven darlings.
Strangely, the only Android drivers, that can be trivially ported between Android version, are those "unstable" bits in Linux kernel.
Take any postmarket smartphone firmware — if something does not work after porting to new Android version, you can bet, that it is a proprietary userspace blob. Who develops HAL for those blobs? — Google. Who controls it's API? — Google.
What "stability of drivers" are we talking about here? Certainly not the kind, helpful to users.
That's only because the Linux kernel is actively hostile to the idea of maintaining a stable driver interface. Windows 7 drivers from 10 years ago still work in Windows 10.
This is patently, provably FALSE[1]
MS goes out of their way to NOT to break APIs. My ancient ATI netbook can run Windows Vista graphics drivers on Win 10. MS only breaks driver API when massive kernel/underlying APIs demand it. ex. 98->NT, XP->Visa.
Now contrast that with Linux. Linux kernel devs are openly hostile to binary blob drivers so they make no attempt to preserve ABI stability. I've see this happen multiple times with ATI binary drivers in GNU/Linux and when I was running cyanogenmod on my phone.
[1] https://www.techadvisor.co.uk/how-to/windows/how-get-drivers...
As a user, I concur with this. I can install Android apps created in 2012 that still work in Android 9.
In iOS, I remember that each major update made half of my apps broken (in some cases, completely broken).
I really find it hard to believe that Android is worse than proprietary, undocumented, Windows-only toolchains of Symbians, Tizens and bunch of other embedded crap, not to mention the horrors of what was PS3 toolchain at the begging.
I think you might be overdramatizing this a bit.
Next I tried GKE and it was an absolute joy. I had a simple web app serving traffic an hour in. Probably because unlike Android, they have to make people like GKE to sell it.
Do you think a proprietary Windows C++ compiler for an embedded platform will make your DI uses easier? :)
And if you prefer a more modern example, Android is indeed worse to use than UWP or iOS.
When they release stable releases, they are actually betas, and updated documentation is scattered around Medium and G+ posts, alongside Google IO and DevBytes videos, why bother updating the official documentation.
After 10 years, the NDK still feels like a 20% job from a team that is forced to accept that Android should provide a bit more than just 100% Java.
Oh, the irony!
Please no, Symbian C++ was the worst development environment i had the displeasure to touch. I'd rather hand write every Java binding for every single API call manually in NDK than even consider looking at Symbian C++ again.
(relevant experience from Nokia's Series 60 around the time of 6600, i don't know if Symbian improved after that, i lost all will to bother with the platform, but considering you still had to implement exceptions via macros by hand because of technical decisions made two decades earlier, despite the platform not being backwards compatible and thus could fix said decisions, i do not expect that things improved)
> We're planning to implement a new more powerful network request interception API in a future version, which will be available to L+ devices with a recent enough WebView via AndroidX. Being able to read POST bodies is one of the features we're intending to include. Unfortunately we can't share schedule information about when this may be available, but we are aware of this use case and intend to support it.
Instead of fixing bugs and making incremental improvements, they seem to have a strong propensity for grand rewrites.
I got tired of the constant parade of new Google APIs, libraries, and technologies years ago and have been choosing alternative products whenever possible.
https://web.archive.org/web/20170125134508/http://sleepmode....
I'm really sorry that you have this feeling, but this has nothing to do with PhDs. It's impossible to get promoted by bug fixes inside Google, and people are promotion driven.
There were many people who tried hard to fix a lot of bugs, but they usually burn out due to lack of recognition inside Google.
Maybe it's working for them from a bottom-line perspective, but it's made their brand as an engineering company clownish.
I think Google is too big at this point already, but that's an orthogonal question.
Again, though, may not make sense for them from a $$$ perspective. Jank and rough edges galore may be something they're willing to live with.
[EDIT]
How this works in my head:
Manager: Could you take a look at the Android developer documentation? Some of it's badly outdated and have you actually tried using it? A lot of the advice is... kinda bad. Also maybe look at a few of these UI components we had the Summer interns make, they've got bizarre implementations and are difficult and inconsistent to customize. Oh and god have you looked at our issue tracker? Has anyone, actually? Like, ever?
Developer: Hey so have you heard of this place called Amazon?
Manager: Uh I mean how about we start a fourth greenfield instant messaging product instead?
Developer: That's better. Amazon? Who's Amazon?
And all of this isn't only motivated by "not doing boring tasks", but also because this is what drives promotions / career advancement. So "launch a feature/project, get rewarded, and switch team" seems like a trend, and it does not encourage to think about long term maintenance / etc. (It isn't a generality either, but it is a bit of a trend)
This is why people job-hop for meaningful career advancement. Much easier than dealing w/ the broken promotions processes these companies employ.
Working on improving the quality of the software is not always easy to measure in terms of impact, and hard to get recognition for in the same as shipping a new feature.
Where Google differs, maybe, is that its promotion system is well codified and rewards the "difficulty" of the deliverable. This is skewing the balance to reward adding more complexity in the system for the sake of solving it (you create difficult problems artificially, they aren't intrinsic to the nature of the user needs you should solve).
There are teams whose only role is to work down those tickets, one after the other.
On the flip side, my first programs that I wrote for myself in the 90's still run. Yeah, I know that DOS is emulated now, but MS made them still work, and I didn't even have to re-compile.
I have this conspiracy theory that Google is purposefully trying to make things difficult to get rid of developers that don't have a lot of resources.
I think Hanlon’s Razor applies -- this isn’t intentional, it’s just unfortunate mistakes.
I think the main driving factors are:
- Many Android APIs were badly designed from the start;
- Android was not designed for easy OS updates, so many users have old OSes;
- Google like Apple’s approach of aggressively deprecating old APIs, and try to do the same. But unlike Apple, they still have to deal with old OS versions, and their fundamental OS design is not as sound. The end result is what we see, messy and buggy APIs.
I agree and Apple does this on iOS as well. It's a way of clearing out old apps.
> They do not realize that they are make •a platform•, not a product.
Consider: maybe Fuchsia isn't a platform?
ChromeOS certainly isn't a platform: developers don't develop "for ChromeOS." App developers target the WebExtension ABI (or, more recently, the Android ABI), and ChromeOS just runs their apps using mysterious virtualization magic that doesn't matter to the developer. You don't target the OS; you just target a stable ABI. (Other examples of this: the Linux kernel ABI used by Docker on {Linux, macOS, Windows}; the Linux kernel ABI used by Illumos branded zones; the Linux userland ABI used by the Steam Runtime.) Essentially, you can think of ChromeOS not as an OS in the traditional sense, but as a hypervisor. The libs your apps depend on aren't part of the OS; they're part of your ABI's zonal environment, which is stabilized separately from the OS.
I would expect that Fuchsia is doing the same: being an OS but not a platform. The only people who will have to directly target Fuchsia are Google engineers.
And I still can't stop laughing after reading: > Somehow every other platform is fine
To paraphrase JWZ's CADT article linked below "writing thoughtful critique" is not fun, "making useful suggestions to improve something" is not fun but "writing a snarky, resentful rant on HN" is fun.
ps. most developers on Android are not game developers, maybe time to think about seeing the world from other peoples point of view?
*eventually is a big significance here. If I wouldn't have my APIs available on launch of FucOS, or like a clear roadmap to them in half a year, I would have to start my own projects to work around of that "eventually it would work" promise. Because "eventually" is not good enough.
Some people here think your own experience is just an anecdote. They're wrong of course. Ones own experience is a data point (or even a collection of them).
Is that an anecdote or a data point? What if 150 people tell you the same thing? Having done exactly that, I don't really care how anyone else classifies it, it is my reality.
The issue with running OpenGL on top of Vulkan is that Vulkan's API exposes a very rigid and static view of the GPU and OpenGL is the exact opposite, allowing arbitrary state changes at any time. While actual GPUs are not as dynamic as OpenGL, they are also not as static as Vulkan so by implementing it on top of Vulkan you are forcing state changes that would not be necessary for the underlying GPU.
Also OpenGL being a higher level API provides for more opportunities for optimization than Vulkan (a very common example would be display lists which thanks to their immutability and opaqueness can have a large number of optimizations applied to them - something that both Nvidia and AMD takes advantage of, especially Nvidia which performs very aggressive optimizations on them).
Of course, given enough time, faster hardware will solve this.
Vulkan is already going down the same path in spite of its youth.
This is all a good thing.
That option hasn't been taken away from you. And unlike OpenGL, you can't unknowingly be relying on an extension since they're opt-in. So what's the problem again?
Anyway, middleware has won the battle of 3D graphics, what goes on the bottom layer is largely irrelevant to most devs.
Ergo middleware is the new cross-platform API.
But it's not. Where is this OpenGL implementation that runs on Vulkan? I would argue that it should come as fully open source from Khronos group since they are the ones providing both standards. It's fine to create a new thing with a long term vision of what a better world looks like. But people won't follow if the pieces they need today are just a wish.
[1]: https://github.com/Think-Silicon/GLOVE [2]: https://github.com/google/angle
I've the feeling that POSIX is an API that makes many assumptions about how things internally are implemented in the kernel. So POSIX as a library is often limited or inefficient.
What they do, more typically, is 'Write Linux software'. If they care about POSIX they will try to ignore features they don't think was mentioned in some POSIX manual from 20 years ago. It's all very hand-wavy.
This is why you see the major operating systems advertise Linux software compatibility rather then paying for POSIX certifications. AIX, Solaris, Windows, etc. Sure it's not a official standard, but it's going to be pretty well defined because you can just model your compatibility on WWLD.
If push comes to shove then Fuchsia could just add some variation of 'usermode linux' as one of those userspace kernel services.
I contribute to an open source project called Torsocks, which is part of the Tor Project, and this comment really resonated with me. Creating a syscall sandbox that works across even a few, generally similar POSIX-compliant OS's is ridiculous.
FreeBSD and MacOS for example have a very similar system interface. But sandboxing on FreeBSD is via pledge, and MacOS uses the App Sandbox. Linux uses seccomp.
It's a mess.
Could you or someone else elaborate on what is so loathsome about the wait() system call?
This was what drove me out of my (brief) stint at Android development. Did some hobby development to learn the ropes, spent a lot of time trying to "do it right". It was a bit clunky but alright I guess. Left my project alone for a few months while my day job was busy. Came back to it to find that, in a few months, there had been not one but two generations of deprecated APIs between what I'd written and current 'best practices' and that a bunch of pretty fundamental stuff had been deprecated.
I'm not wasting my life chasing that particular Red Queen.
This is caring about developers, just that you don't understand it.
I think you're hugely overstating the importance of POSIX, not to mention downplaying the fact that POSIX really isn't sufficient requirement to not have to do any code porting.
Those layers would have to be reimplemented to retain compatibility.
> I think you're hugely overstating the importance of POSIX.
People generally understate importance of POSIX, just because it's old. It's impossible to get APIs perfect and you are throwing away decades of work in the name of getting APIs "right". No one is going to rewrite everything from scratch, just because the new APIs look shiny. For reference read about Unix wars[1].
OS is a tool to start apps, and if they can't make it comfortable to make and support apps, they failed before they started.
Google's problem is their academic goal to make a nice OS, IMO.
If they want to test the waters in relatively unexplored waters let them do so.
OpenGL was never a serious contender for modern games and there's a good reason why all new 3D APIs are moving to more low-level representations (Vulcan, DX12, Metal) with libraries on top. OpenGL is a horrible implicit stateful machine which is terrible to multithread and still holds a model of a hard-wired 3D accelerator as a base, which isn't how new graphics cards work. Everything else is bolted on top of that out-of-date idea which makes is hugely unwieldly for new software.
If possible, I'd prefer to keep using APIs from 1960 instead.
When I read that I caught a hint at a problem. API design should not be an ongoing activity. People should design a new API and then we should all use it for a long time. If it's frustrating that POSIX is still used, you might want to consider that stability is the feature that keeps it around.
Perhaps it's time to reread Joel on "fire and motion":
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
I'm all for this Fuchsia thing, but they claim to have the experience to design something better so do that and let it stand. Regular software updates are actually a sign that you don't know what you're doing.
As for Fuchsia, given that the team comes from a different background and the OS APIs, I am not expecting the straightjaket experience from NDK.
Well, tell that to game developers working for consoles. They don't have access to the same APIs and they made it work just fine. Most of the time, you don't make your own engine and rely on some other engine to support your platform, so it just works.
I've done enough Wii, PSP, PS3 or PS4 development and having different APIs was never a problem.
It is already expected to have to rewrite your GFX backend anyway using the specialized API for the platform, but people don't expect the same for general use APIs too.
The last time I created a new project from the Android Studio built-in template, it was broken from the start - UI editor throwing an error, googling didn't help, I didn't have so much time to debug it so gave up again. I expected built-in template to always work.
I hate java, I always hated that tree of subdirectories. What worse, there are some Maven repos and some proprieters Gradle binary which is randomly downloaded to my pc like a malware. Why is that? It is very difficult to configure the project, so many XMLs, documentation is not very good, build process takes a long time. Android studio is slow and takes much RAM as any java-based IDE.
Rename a project? Near impossible. You have to be a guru to know all the places where to change it, rename directories, etc.
In comparison, it is very straightforward to develop for iOS. It is possible to integrate C/C++ easily. Normal gdb/lldb. Cocoa UI is nice, nice frameworks with reasonable documentation. The only problem is the closed platform, requirement to pay for Development program, signing all binaries.
When Android was first released I've put it to the same category with Open Firmware & Debian. Now when I see Fuchsia, I reflexively categorize as a pseudo-open source software, where you can see the code but cannot do anything useful on the long run, because it's designed to be downloadable but unusable for casual/research purposes.
Maybe "we put out the source for you to see and start to limit its free use when it matures enough" model gets tiring for me.
Google just used good marketing to convince MS-haters that they were different.
Someone should tell RedHat. And Debian. And, y'know, Linux. I'm sure Linus will be devastated to hear that the last couple of decades have just been a fluke.
They will be upset. We need to be prepared. /s
How many business are making money selling Debian based software?
And how many business critical software stacks are still based on GPL, without any kind of dual license of some sort?
Their business model allowed them to develop KVM and OpenShift.
Debian gave birth to the biggest number of derivative distros. They're the biggest and most mature base. Even Ubuntu is a Debian derivative.
While there are no enterprise software that I know (my domain doesn't overlap with "enterprise software"), I'm aware that some of the heavy hitters in the software world have their killer features based on open source software or algorithms (Photoshop's content aware fill comes to my mind which is based on resynthesizer of GIMP).
I guess those Red-Hat boxes at my parents basement are a piece of imagination.
> Debian gave birth to the biggest number of derivative distros. They're the biggest and most mature base. Even Ubuntu is a Debian derivative.
Great, and how much money do they earn from it?
No, they are not, but Linux distros were never small (except Slackware & Gentoo), so many of us were unable to download them (with 56kbps modems). We bought the complete CD sets, which were essentially repositories on CDs. I had SUSE 6.0 box set.
A generation has abused university networks to download ISO files and write them to discs. That's why most universities had local repositories for a considerable amount of time. Many still have. The place I work hosts country-wide official repositories of most Linux distributions.
> Great, and how much money do they earn from it?
Why not ask to the non-profits which govern the money and assets of the Debian and other projects? The page is here [0]. Looks like Google is also a donor in SPI which hosts Debian, PostgreSQL, Arduino/ArduPilot, Arch, etc.
BTW, most Debian and open source developers don't do it for the money. They build the software for fun and use their skills in their day-job to do their work. Also, there are many developers paid to work on open source code and implement the required features. Glibc's developer is (was?) an RH employee for example. Intel pays developers to implement their open source network and graphics drivers. AMD's both open and closed source driver teams (yes there are two, isolated teams) are on AMD's payroll.
Open Source software is sustainable. You pay for knowledge and the effort, not the code.
That is to miss the point. Nobody give a shit how much money can be made selling Debian. The users care about how much they can get done by using Debian. Software has essentially zero replication cost, so those who try to make a lot of money from it are rent seekers. The challenge then is how to create software in the fist place. Those that charge for software and provide continued high quality development will be OK, while those that buy RedHat just to make money will not (long term).
I see Fuchsia as a good compromise here, it's going to have more free and open layers than MacOS on top of Darwin has. It's going to avoid a lot of the security issues Windows had and even the Debian/Ubuntu OSes and can probably be closer to MacOS/iOS in that way. It's certainly going to be a lot more open than Windows.
However, in the end, it will also allow Google, hardware and graphics library makers to have more proprietary parts that they control the vision on around the end user experience. It can certainly be the Windows alternative we need and hopefully Microsoft will realise that open sourcing Windows and allowing forks will be the best way for the OS to survive.
Fuchsia is in its infancy now. A little prototype. with its stable API and other features, it smells like a "hardware-vendor friendly" (or vendor-first or oriented) platform.
It may replace Android, maybe Linux in Google's own data centers. Then, we'll have another platform like OpenSolaris. Open, but not. The primary reason I like Linux is its transparency, openness, freedoms it provides and the resulting flexibility, and I'd hate to see these freedoms are eradicated with a so-called Open platform controlled by another mega-corporation called Google.
If it doesn't, then just fork it.
Forking is always easy, maintaining is hard. Also, we're not sure whether things will be made harder by Google when things get mature.
I don't have any Android devices, and I don't follow its forks, derivatives or general state too closely. If you have the money and the means, you can always make a fork of an open source software and make it work for you.
To be more accurate, maybe I can say it won't be very useful for the general public, but big companies can do whatever they want since they have the money and the man-hours.
First of all, it allows hardware vendors to be lazy. If a driver compiles, unless there's a grave bug in the driver, the vendor won't do anything. Because it doesn't hurt their bottom line much (nVidia has some serious bugs with their closed source driver, and they play the deaf, but that's another issue). When the API is not stable, something will change/improve inevitably, and the driver will break. A non-compiling driver is guaranteed to wake the vendor up, and maybe they'll fix some of the smaller bugs while they are at it.
Second, it hampers kernel development. You have a killer feature you want to implement, and it needs new API calls to be a first-class implementation? No, you can't do that because the API is stable, you can't change it. You need to work around it, tuck it behind more generic calls, add overheads, etc.
Fuchsia's API stability mean that a vendor can write the driver once, and send it to integrators once. Unless someone complaints enough, they won't need to touch the code. When the ABI is stable, you can just distribute the .o files, and forget all about it. The driver is working somehow, the integrator is happy, the vendor is making money. This is the dream of commercial software. They can implement once, and deprecate once and for all. Hooray!
This completely ignores the fact that most hardware vendors have no financial incentive to make driver updates for hardware that you have no choice to replace because it's a chip embedded in your phone and they get to choose between forcing you to pay them more money for a new one _or_ spending money for no reason to update the drivers for old hardware. Breaking compatibility very demonstrably does not get mobile device vendors to ship updates, but it _does_ fuck the device owners. Let the driver that works just fine keep working just fine! Don't make a billion people suffer on old kernels because you think that a hardware vendor should do extra work to support a chip that they already made their money from just because you decided to break something that was working just fine before you made your change.
> ...no choice to replace because it's a chip embedded in your phone...
My comment wasn't targeted at the embedded usage scenarios only. There are professional and consumer devices (hand-vein readers, printers from certain manufacturers, high end and high-speed scanners), which advertise Linux support on their boxes and documentation, but only provide binaries and modules for some archaic Linux distributions. This situation is hurting both sides of the equation. Some of these devices are very nice, expensive devices I'd (and many would) buy, but their non-existent Linux support keeps the users away from them. Their change in attitude will not probably change the stance in the long run due to trust issues.
The problems are not only at kernel level either. Some of these devices run translation layer binaries in userspace, and these binaries are written without following the standard coding practices in Linux. As a result, an ordinary library update breaks the binary for good. Again, the manufacturer does nothing because it has no incentive to do so, and my expensive device becomes a paperweight.
> Let the driver that works just fine keep working just fine!
Coming from this perspective shall we stop all development on Linux kernel and userspace, so everything works? Why Microsoft is constantly changing driver models ever so slightly, and every manufacturer is updating the drivers about the cards and chips they've already developed and embedded on my motherboard, NIC, sound card, etc.?
> ...just because you decided to break something that was working just fine before you made your change.
While Linux kernel API is officially unstable, there's a rule in its development: if userspace breaks after a kernel patch, the problem is in the patch. Kernel changes shall not break or change userspace behavior. Hence, nothing is broken on purpose in the kernel. The evolution makes things change, and we shouldn't stop this change if we want Linux to be a cutting-edge operating system and platform.
I know, but I think that the Linux kernel developers should update their views on the impact of ignoring the embedded scenario.
> Coming from this perspective shall we stop all development on Linux kernel and userspace, so everything works?
No. Preserve the old methods so that things that used to work keep working. Microsoft does this. Windows userspace apps from 20 years ago still work in Windows 10 today despite the system having advanced significantly since then. Windows 7 hardware drivers from 10 years ago still work in Windows 10 too. New functionality doesn't need to break old functionality.
> Why Microsoft is constantly changing driver models ever so slightly
They mostly don't. See above.
> every manufacturer is updating the drivers about the cards and chips they've already developed and embedded on my motherboard, NIC, sound card, etc.?
Bug fixes. Almost never interface changes.
> While Linux kernel API is officially unstable, there's a rule in its development: if userspace breaks after a kernel patch, the problem is in the patch.
You just said userspace. What is userspace? If I can't update my kernel because it means that my camera will stop working because I only have the one binary blob for it, then the kernel has broken _my_ userspace. But that scenario is explicitly ignored because the userspace rule doesn't apply to drivers.
The Linux kernel pushes GPL virality further than it should go by effectively mandating that one of three things must happen:
1) you give them your driver code
or
2) you keep doing work to re-certify and re-release your driver (but you could just mainline your driver code, hint hint!)
or
3) billions of people go fuck themselves
Mobile device vendors choose 3 because it makes them more money by obsoleting the devices more quickly. It's time to recognize that fact.
> Preserve the old methods so that things that used to work keep working... I have many old applications which compile without modification, or work without re-compilation given all the libraries are available. In Linux, most of the libraries are backwards compatible. Newer versions of the required libraries works with the said application unless the application gets the version and requires a strict version. For these libraries, the packages are always available (e.g. Spotify required libssl-1.0.0 for some time, but they updated it so it works with 1.0.{0,1,2}). Most of the low level libraries are API/ABI stable in Linux world.
> Microsoft does this. Windows userspace apps from 20 years ago still work in Windows 10 today despite the system having advanced significantly since then.
With the help of WindowsOnWindows (WoW32,WoW16), a complete embedded Windows XP image, a great hack called Compatibility Layer and other tidbits which makes things much more complicated and convoluted. Modern Windows 10 contains at least three complete Windows subsystems (or abstract installations) inside. This is hardly a good solution. You can install a complete 32 bit Linux subsystem to achieve the same thing, which is neatly called as multi arch support, and it's much simpler: a set of libraries, nothing more.
> Windows 7 hardware drivers from 10 years ago still work in Windows 10 too.
From my experience 7 to 10 compatibility is not universal. Despite having the same "foundation", 2K drivers didn't work on XP. XP drivers didn't work on Vista albeit advertised as compatible. Same for Vista to 7. 7 to 10 mostly works, and it's better than ever, but it's hardly bulletproof. Hardware vendors used this incompatibilities as an excuse to be lazy and obsolete lots of hardware. Been there, experienced that.
> Bug fixes. Almost never interface changes.
Sound card & TV tuner drivers are notorious because of the timing and direct access they required. Interface and access capability changes killed Creative's hardware EAX in XP to Vista migration IIRC. The cards are buried behind expensive API calls with the expense of latency. Most of the effects have vanished (since the card access in vanished) overnight. I had many of the Creative cards (Live, Audigy, Audigy2), and felt the hurt.
> If I can't update my kernel because it means that my camera will stop working...
Actually, I have a lot of hardware which were deserted by their manufacturers by not updating their drivers and Microsoft refusing to provide even a basic driver. Nearly all of these devices work under Linux, with better performance compared to their official drivers.
I had a printer which had a translation layer binary, but no kernel space driver. This translation layer binary is used as an intermediate CUPS filter to convert the PDF/PCL to printer's own language. The binary didn't conform to POSIX/Linux standard coding practices, and if you didn't provide the exact (old) library it wanted, it forked continuously and didn't work. So your print button was rigged as a slow death button for your PC. I can accept a binary blob, but code it right.
Similarly we have ~1000 servers at work. Some of them are ~10 years old, but they work with most modern distros without complaining. Everything is available, and stable. Even closed source drivers. I don't think the problem is the unstable API/ABI.
BTW, an interface change doesn't affect all the modules. Your module is affected if the interface you talk to changes. You only need to recompile the .o or the source since ABI is not stable due to non-stable API. This is not a real world problem from my experience with said servers.
> The Linux kernel pushes GPL virality further than it should...
I think we need that vitality, but it's another discussion topic, so I'll leave it here.
> 1) you give them your driver code
No, You can provide an .o file if you want.
> you keep doing work to re-certify and re-release your driver
Again, you can just update the .o file if the interface you talk to changes. Not a big deal if you're serious about Linux support.
> (but you could just mainline your driver code, hint hint!)
Unless you implement your magic in the driver (like a WinModem), and you didn't license closed IP from someone, you can open source your drivers. Even Broadcom open sourced their drivers. So it's not something scary if you plan it right.
> 3) billions of people go fuck themselves
The mobile vendors' choice is business related. Even if the code is open, they will obsolete it nevertheless. So, open source driver availability is not a factor here.
I also want to add some more information about this.
- AMD has re-designed its silicon to allow fully open drivers. This is a big gesture towards Linux and Free Software.
- Many high end hardware manufacturers (like Mellanox) open source their software stack (OFED, Subnet Manager) because the code is worthless as an IP without their silicon and hardware.
- Open source drivers prevent obsoletion, but driver cannot manufacture the chip itself, so it has no role on product lifecycle. Upcycling embedded hardware is not trivial for everyday user.
But over the years they moved all the apps to closed-source, one after the other, even some core elements (play services).
Pretty soon it will be no more open source than iOS (the kernel is open source, yay!)
But if I could chose to get Debian on my phone bundled with a crappy phone app that looks like it was developed in the last century, I would immediately pick it.
Redux came first and it happened because the "interaction graph" between various components on the website became virtually impossible to resolve cognitively. The engineers (especially on-boarding engineers) faced troubles understanding how everything worked in concert and, especially, the side-effects of a single change. The nail in the coffin for the engineer was Facebook chat and she was forced to use numbers, instead of lines, to depict interactions because the graph was too dense. Redux forced interaction in one direction, with "back interaction" happening one frame/tick later. Web developers have praised and embraced this architecture.
If you look at the very first image in the article, it moves from a very straightforward application -> VFS -> ext2 -> driver -> disk graph to a [potential] rats nest. It runs counter to the hard lessons that Facebook have learned with complex distributed systems.
Is this why nothing has really come from Mach/Hurd? Up until putting 1 and 1 together a few minutes ago, micro-kernels sounded so clean and elegant. They now seem unwieldy. Perhaps there is exists another layer of architecture that can tame the dependency/interaction graph; isolation really does sound like a good idea, but we need a better way of doing it.
Mach 3.0 was the kernel used in NeXT and the original Mac OS X release. It was quite a bit later replaced with a rewritten kernel XNU, that’s basically a hybrid. The reason as I understand it, message passing in the kernel is expensive when crossing user space so often.
I wouldn’t call that nothing coming of Mach, it did really well!
Also, I’d say that micro-kernels are closer to the paradigm of react/redux (redux the message bus, react the user space servers) than to a monolith design like Linux.
https://en.wikipedia.org/wiki/Redux_(JavaScript_library)
https://en.wikipedia.org/wiki/React_(JavaScript_library)
Perhaps you're talking about the Flux architecture? Not the same thing. Care to share the video you mentioned?
Redux and Flow are somehow branded as alternatives to MVC, when they are precisely MVC (store=model, dispatcher/reducer=controller, etc). It seems that Facebook (and many others) implemented MVC very poorly and pretended to abandon it instead of admitting they just did it better on the next attempt.
If anything, the success of redux simply reinforces the fact that MVC is a very useful pattern for UI applications. But, it bothers me that newer developers might be persuaded by the anti-MVC branding.
What I found interesting was that the original developer(s) of react.js seems a lot more up-front about this:
https://omny.fm/shows/future-of-coding/1-1-how-reactjs-was-c...
Of course, the whole idea of, in-theory, re-creating the UI at every refresh cycle is not part of MVC, so that is new and interesting. Considering all the work that has to be done to undo that abstraction (as it doesn't really match reality), I am not sure how useful it actually is.
https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...
A key design feature of Flux is that many unrelated (or related) stores can respond an event, and that there is a defined lifecycle for handling events. I don't believe those really map to MVC.
Because Mach. First generation microkernel. Slow. The microkernel world has moved way past that, whereas Hurd has stayed behind still using Mach. [0]
The second generation was spawned by Liedtke's L4, which basically attacks the performance problem of the first generation, making it negligible.
The third generation makes capabilities a first class citizen, core to the design. Its main representative is seL4.
As an added note, multiserver is a better fit for SMP than locks and the lock contention they imply.
[0] http://sigops.org/s/conferences/sosp/2013/papers/p133-elphin...
I remember where I was and what I was supposed to be doing when I was instead reading the HN article that posted this lwn article (above) about Magenta 2 yrs ago, after finding Eric Love's Guide to Linux Kernel Development, and found this a fascinating read to compare to, given my learnings in kernel dev at the time.
How do you feel, is there anything behind this claim?
* better process isolation
* stable hw/driver api (this is a huge mistake in linux, agreed)
* less historical craziness(who likes fork()?)
* more micro-kernel
some of the things I personally cannot buy:
* vulkan native. android is not vulkan-native, it provides both opengl es and vulkan, for your choice
* flutter. why bundling and bringing opinions to the system becomes a benefit? it was a major problem with android that you have to interact with java if you want any native ui => I would prefer more ways/languages/bindings to interop with the UI
* fidl ipc. cool, again, why bundling something with the os?
* vDSO. why is even vdso on the slides - vdso is important, but it already with us for a decade.
This article is great because its one of the first that breaks down Fuchsia on a tech level. But at the same time, its not an article that explains all the reasons the fuchsia is better that what google have now.
Not to get into a flamewar over this, but there are real benefits to Linux's rolling driver ABI (the "API", however, is mostly stable, contrary to what you say). It encourages mainline collaboration, and greatly improves the quality and compactness of the drivers.
On Windows (and to some extent macOS), you'll find whole classes of driver where each driver has its own proprietary internal implementation of something that should have been in the API and ABI, but is not (or just was not when the driver was written). Linux has great, up to date drivers for the vast majority of devices you'd want to use†, and all of the best ones are built (compactly!) right in to the kernel, so it is more or less moot at this point whether a stable ABI is a good thing (at worst, it didn't matter in the long run; at best, it made the system better).
The level of integration and standardization in the Linux kernel is spectacular, and absolutely would not have been achieved if vendors were empowered to link ABI-compatible binary blobs into end user kernels. There is tremendous value in the fact that I can manage, consistently, every LED, every DVFS controller, every fan controller, every GPIO pin, etc. on each supported system in a consistent fashion. Left to their own devices, each vendor would use their pet interface (as seen with NVIDIA putting their foot down and demanding EGL surfaces be used with their driver on Wayland, despite the fact that no standard software supports it); NVIDIA insists that this is the way it's meant to be played, and I'm glad that the answer is a resounding no.
† Outside of the Android ecosystem, which, through what could maybe be called poor stewardship on the part of Google, inexplicably refuses to develop against the mainline kernel, so is constantly fighting to maintain literally thousands of vendor-, OEM-, model-, SKU-, country-, and carrier-specific kernel trees for absolutely no recognizable benefit, and against the clearest and most consistent advice of the highest experts on the subject.
I have some bad news for you. They got their way.
I feel like this is demonstrably a false promise by looking at the billions of mobile devices never getting any updates because of vendor neglect.
> and greatly improves the quality
Compared to what?
> and compactness of the drivers
Which no user has ever cared about.
> up to date drivers for the vast majority of devices you'd want to use†
I notice that you excepted billions of devices in order to make this claim.
> inexplicably refuses to develop against the mainline kernel
It's not inexplicable. It's easier and cheaper.
The user cares because it results in fewer bugs.
Third-party firmware like CyanogenMod exists only because in-kernel GPL parts can be ported to new OS versions.
With Fuchisa there won't be anything like CyanogenMod anymore.
I think you're confused. If the interface for the drivers stays stable, then you can just carry over the same exact binary blob and it will keep working perfectly, which is exactly what Microsoft does. Windows 7 drivers still work just fine in Windows 10.
> Compared to what?
Compared to what happens on Windows and Android, where individual drivers have to reimplement common functionality, often in inconsistent ways.
> Which no user has ever cared about.
Users care that their drivers work and that they continue to be supported in the future. Less compact code is larger, and therefore buggier. Drivers which are provided as proprietary userspace blobs are invariably unmaintained and stop working with future kernel versions.
If an Android device launches with a new CPU or device, the OEM has to go through the process of up-streaming the changes to mainline before they can launch their phone? not going to happen.
That's a wishful thinking. Majority of Android drivers are userspace blobs. Linux kernel development process is completely irrelevant for them.
Device vendors don't update already sold devices because they don't care (and because average consumer also does not care).
You should consider why the hardware vendors are in the critical path for OS updates in the first place. Dell doesn't get to decide whether you can apply Windows updates.
They more or less intend to supply the hardware only. This avoids the pretence of vendor updates entirely, by both the company (Pine64) and the ARM licensee (Allwinner).
The software stack is up to you, with mainline Linux support courtesy of the A64 [0] powering a number of 'RPi-killer' boards. Device updates will be supplied by the likes of Ubuntu Touch, LineageOS, postMarketOS et alia mobile distributions.
Maybe. Except that for me (and I know I'm not alone) the second most important part of my pocket computer after web searching is the camera, and they're unlikely to have anything great in there.
> Allwinner
Hah. The repeat GPL violator?
thereby we get the constant tension between google and hardware makers that want to keep their jewels secret, and the linux/foss community that wants to keep their freedom to install their (open) software on any device... by keeping the drivers in with the kernel, linux can foster that end, but it causes no end of frustration to google et al...
i think that’s probably the reason we get fuchsia: google can be open source, and with the hw makers, keep the proprietary parts proprietary... the result being, we have open kernel and os bits but no guarantee (or much hope at least) we could ever run it on our devices...
i think that’s the biggest cultural divide: freedom to change and replace the software vs freedom to look at the code (and maybe run it in an emulator...
It does to a very significant degree. Windows 7 drivers from 10 years ago still work today with Windows 10. Windows 95 user software from 23 years ago will still work today in Windows 10. Microsoft cares strongly about maintaining compatibility and only removes functionality when necessary.
There's a whole class of devices that will never be in linux mainline kernel - experimental filesystems(remember those years wher FUSE was a patch?), propietary hardware(embedded devices), kernel bypass hardware(onload), security hardening mechanisms(remember PaX?), commercial software who basically sell the driver(intel studio profiler).
All this breaks every time linux releases a major rewrite. If the vendor is out of business or no longer interested in a product - you are left with the drivers that do not work.
Moreover - in a case of major api breakage - its kernel contrubutors who are left with re-writing every driver for a new api, delaying the kernel releases.
Formal verification is the difficult but necessary next step for security-intensive applications.
Also, any new kernel should only be written in a memory-safe language. Rust would be the best, since it is also safe from data races, outside of unsafe blocks.
The proof evidence is very hard to extend meaningfully for new platforms, and you're limited to environments which have a sufficient MMU.
We're starting with seL4 and building a whole Rust-based userland around it, and creating a whole pile of compile-time assurances along the way to make sure we're not inadvertently doing something dangerous or stupid with the rope seL4 gives you.
It's worth it for us. However, it is a colossal pain in the ass. That said, in the coming months we're likely to open source some of our progress in making it easier and more reliable to work with, integrate with, and otherwise leverage seL4 for certain use cases.
As an aside, I wonder just how much async/await in Rust will obviate the need for small kernels in deeply embedded applications. If I can do blocking IO with my peripherals and use the async state machines to do "task" switching, well... who needs tasks and capabilities? It'd land somewhere on the "language OS" side of an embedded OS almost.
Waiting directly on the resource like that would require exclusive access quite often though?
When we open source things in the coming weeks & months they'll all land on GitHub, https://github.com/auxoncorp, so that's probably the lowest touch way of observing what we're up to as things mature.
While Rust seems to be promising here, I'm not sure whether the current async/await implementation will really allow for this. I experimented a bit with it, and found lots of issues where async/await lead to severe memory bloat (composing 3 async functions that do not a lot things requiring a 20kB task allocation). The compatibility with Futures and the requirement to move async fns to compose them before using them (which requires extra stack - which again ends up as extra heap/task memory) plays a bit against it. But these things are also worked on, so let's seee how it works out.
You should read [1] to understand how Rust achieves this.
A data race has Undefined Behavior, and is therefore impossible to perform in Safe Rust.
...
However Rust does not prevent general race conditions.
This is pretty fundamentally impossible, and probably honestly undesirable. Your hardware is racy, your OS is racy, the other programs on your computer are racy, and the world this all runs in is racy. Any system that could genuinely claim to prevent all race conditions would be pretty awful to use, if not just incorrect.
Maybe you should read a bit more on its docs [1]. I quote:
However Rust does not prevent general race conditions.
IMO vulkan-native is the right choice because opengl (or opengles, or anything else) can always be reimplemented on top of vulkan anyway. Layering opengl on top of vulkan means you're no longer at the mercy of hardware vendors to provide a bug-free opengl implementation. And if you're calling a userland opengl library running on top of vulkan, you can actually debug into graphics system and much more easily tune performance. (Debugging through into opengl calls is almost impossible when the opengl implementation is hardware-specific and part of the graphics driver itself).
But what is a thing is whether or not the GPU driver bothers to have an OpenGL ES path or not. It's obviously simpler if the driver doesn't, but a quality driver implementation will also obviously always beat something like ANGLE in every way.
So take a hypothetical Nvidia Shield 5 running Fuchsia in 5 years or whatever. If games are still dominantly in OpenGL ES, then you can bet your ass Nvidia will be shipping a first-class GLES driver and not use ANGLE-on-Vulkan.
In practise it wouldn't work all that well unless you pay a development team to push the GPL version significantly ahead, but it's a possibility.
Nothing in the MIT license says that you can claim credit, ownership, or restrict licensing terms on someone else's code.
What you can do, of course, is include the original MIT licensed work in a larger project with other GPL'd pieces. That does not "relicense" anything, and I'm only constrained by the GPL if I use the GPL'd part of the codebase.
I can download X11 from Redhat and still use it under the original terms from MIT.
The MIT license explicitly grants the right to sublicense.
The world "relicensing" doesn't exist in copyright, nor in the linked article. Instead there are some similar situation being bunched together and faulty used interchangeably.
A copyright author can redistribute a work they own under new terms. This would be the case when they have offered a work under say MIT and change the copyright license for any future offer under the GPL. It is similar to a merchant changing the price, ie in the past the product cost X but now it cost Y. Naturally past customers don't suddenly have to pay more for something they already paid for, but buying more (or getting updates) applies the new price.
The copyright author can also dual license it. In this case they would offer the work but under two different licenses at the same time. This would be like a merchant offering a product under two payment plans, one where you pay up front and an other more expensive method where you pay a small amount each month for a bigger total. In both cases the product is the same but the condition of sale is different.
The MIT license itself also allows for something similar to resellers, ie people who take a copy and apply their own additional set of conditions when they distribute it. This doesn't change the original offer, but those getting a copy from the reseller has to honor the resellers term and condition in addition to the original conditions of the author. This is similar to going to a store where you pay both the product original price and the margin of the reseller. You can always go to the original manufacturer and only pay the original price, but you may miss out on features that the reseller include in their package.
When you combine MIT code with GPL code you are creating a derivative work of involving at least 3 sets of copyrights. Your copyright (since I am assuming you did more then just copy paste), the MIT licensed copyright, and the GPL copyright.
Anybody using that code is subject to those 3 sets of copyrights combined. It's a derivative work of all 3 code bases so it has all 3 copyrights and depend on the original licenses for anybody else to legally copy.
Since the GPL is the most restrictive and disallows any additional restriction then the code base is _effectively_ GPL licensed.
Fuschia has a highly permissive license that would allow anyone to fork it and release the fork under a completely difference license.
Any project can be opensource but still under direct control.
For anyone wondering what that means, here's a good place to start:
http://erights.org/elib/capability/overview.html
> Modern capability security theory comes mostly from the work of Norm Hardy, Charlie Landau, Bill Frantz and others...
I worked with Norm and Bill at Tymshare in the '70s. Alas, Norm passed on last year, but I got to see Bill at his memorial. If you're in the Bay Area and into ham radio, you might run into Bill on the N6NFI repeater.
It's baffling that it has taken 30 years to trickle down.
Android's platform design would arguably have been considered modern in 2007 or 2008, but it is 2019, and the cracks in Android's capabilities have been widening for a while. Sometimes people still think of Android as "newer" in the operating system space, but it's a decade old!
Attempts to do so often entail more or less, tacking on a whole different environment, as Microsoft has attempted with UWP. To a certain degree, it'd be easier to just start over from scratch, as Google is attempting to do.
either they or the organizations paying the bills just didnt care yet.
Windows NT came out over 20 years ago, in 1993. The first public release of Linux was in 1991. And the BSDs trace back even longer, you could say back to the original Unix from 1969. So a decade is recent I'd say.
But that does not mean that they dont target the same devices, the same market and the same use-cases.
my current company supports down to only api level 19 and even then it's like having to maintain multiple apps to support apis <23
So I'd say for most of its business activities, Google is actually okay with the GPL, otherwise they'd have rewritten it a long time ago. Given the size of Google and how important Android is to them, I think they'd have prioritized Fuchsia OS far more if their bottom line were really affected.
There is a point with drivers, as Fuchsia has better support for proprietary drivers than Linux and IIRC one of the Android modifications was to add HALs to the kernel to make proprietary drivers easier. But it's not a killer argument, after all they figured it out for Android.
Their business intent with Fuchsia is definitely not clear so it's a honey pot for speculation. I don't know. Maybe they wanted to diversify their approaches and have something if the Android kernel fork gets more and more patches and eventually backporting becomes impossible and they need to maintain it on their own now. Maybe they just want to be upstream as it involves a great deal or power that you have. Maybe it's part of a deal with a hardware vendor who wants their driver to become proprietary in the future.
[1]: https://web.archive.org/web/19971210065425/http://backrub.st...
Yes, google have nothing against GPL, but still GPL/agpl/lesser gpl are licenses that place specific limitations on a company modifying the original work. There are alternative licenses that do not.
The kernel is still on the "vendor" side of Project Treble, and still controlled by the OEM as a result (not that it should be but it is). This is not against "traditional linux" at all anyway. Upstream linux doesn't exactly like having a bunch of stuff rammed in as kernel modules either, that's why for example FUSE exists.
As for "removing GPL parts" - Android started with minimal GPL parts in the first place but they haven't been actively removing GPL, either. Just look through AOSP for MODULE_LICENSE_GPL - you'll find a ton of components are still (L)GPL.
Where is the upstream support for HIDL IPC with kernel?
From what I've heard Fuchsia will feature a deeper integration of Google services than Android. Demo: https://www.youtube.com/watch?v=FhX6cANaJ6o
There is an app ecosystem composed of Google Mobile Services and the Play store, today it runs on Android and on ChromeOS, and it seems that it will run on fuchsia too.
It’s a great senior engineer retention project though.
A glance at the design will tell you that no, there's nothing to that claim.
Fuchsia's only competitor is Genode. Linux is basically obsoleted by its design.
For me this reason is enough to justify linux replacement. I think it's one of the main reasons for google to, they want to deal with vendors' blobs in a more stable and ease manner.
If you combine this with the other point of Fuchsia, hardcore security, the final combined result is that nobody can audit what Google is actually doing on "your" devices. And that's why.
Are people really dumb enough to fall for this trick over and over again?
(Don't answer, that was a rhetorical question.)
On chrome os, the most significant feature is the newly added ability to run linux applications via crostini. Containerization is of apps is a big topic in general in the linux world with e.g. things like snap.
On Android, they have an extremely large installed base, enormously slow upgrade cycles, and a huge legacy development ecosystem. This ecosystem overlaps with ChromeOS as well since it can run Android apps. And Android can do linux apps as well (though that mostly makes less sense).
Fuchsia would need to play nice in that ecosystem or it will face an empty room problem where all of the key apps have not been ported yet, they have a tiny marketshare initially (thus removing the incentives for fixing that), and OEMs will likely vote with their feet by sticking to the old platforms. Part of that is supporting linux based stuff; which especially on Chrome seems increasingly important.
So, kind of pessimistic that Google has a strategy for making this work. This makes sense as a research project but not as a product strategy currently. Yes Android has issues. Maybe fixing those might be easier than replacing it entirely?
actually the networking stack in Fuschia, or more particularly zircon the kernel it is optimized around, is written in Go.
Kubernetes is written in go, which is essentially a system for implicitly defining scaled linux boxes on a giant network, and now in the most recent release is allowing for declarative architectures as well, much like how user space services for graphics drivers in Zircon will enable more declarative and optimized use of expensive resources as well (in this case, modular hardware architecture for mobile operating systems, which is what Fuschia was originally envisioned for.)
I'm also pretty sure Google also has experience with mobile operating systems (android), and Fuschia is literally a response of now over a decade of trying to interface android on POSIX in conjunction with multiple chains of monopolized and closed source hardware architectures, being intimately familiar with the evolution of trends in the mobile hardware architectural space, and trying to rewrite a kernel to optimize for that.
"Fuschia will need to play nice...Part of that is supporting linux based stuff; which especially on Chrome..." Chrome had to have an entire team dedicated to resandboxing their tabs to mitigate for spectre and meltdown, which are both results from the unquestioned but growing obscurity due to unquestioned implementations between hardware and Linux integration, which is something that Fuschia attempts to take a step back from, and by doing so simultaneously make it easier for open source development on hardware architectures while optimizing for them.
Still, total site isolation is still an advanced option in chrome that results in a 10% degradation in memory performance so people don't turn it on, if they even know to check for it/what that means (most people don't).
But the bottom line is: Empty room. beautiful OS with an empty app store is kind of a non starter in the current market. Windows Phone found that out the hard way. Also, several other mobile operating systems that did not quite make it or continue to struggle. Sailfish, WebOS, Firefox Mobile, Ubuntu Mobile, etc. Even ChromeOS struggled until they added android support and Crostini.
As we always need to remember Linux fans, the fact that Android uses a Linux kernel is irrelevant to userspace.
In any case, it wouldn't be the first time that Google walks away after putting lots of development in something. In general, I think they are closer to merging Android and Chrome OS than they are to replacing either with Fuchsia (not to mention convincing OEMs like Samsung to actually use it).
Those native libraries are forbidden to use Linux specific features, only these APIs are sancioned.
https://developer.android.com/ndk/guides/stable_apis
Since Android 7, Google has been claping down NDK users that try to used anything that isn't part of that list.
Since Android 8, APKs are only allowed to reach for their own internal filesystem and use SAF for anything else. Something that will be further enforced on Android Q, so no luck trying to peek into /dev, /share and similar.
But perhaps the reason Fuchsia won't struggle unlike the other OSes you mention, is that it is possible that it will be compatible to run all the Android apps in the play store from day one, thanks to Machina; allowing a smoother transition, a process similar to what Apple did with the PowerPC to X86 switch but in Google's case, its for a completely different OS.
Anyways, docker is a good example of how current linux systems are not optimized for modular sandboxing and containerziation. Still, people are so uneducated even in tech on how important this idea of only working with bare bones (I started in C so allocated bytes as I needed them and always considered how not to use them first, is a far cry from npming an express server and seeing the endless train of dependencies that are invoked) that still they do not secure their containers, and the number of ubuntu18.04 std base images I see running a docker container that simply contains a python app or something equally trivial, live in production at some of the top tech companies, which you can google and download a rootkit for, with no linux hardening whatsoever, is the terrifying norm of centralized web application companies today. I really am not going to buy into this idea that docker contiainers baring full replicas of the operating systems they sit on top of are a justification for POSIX.
If you want increased modularity for security, sandboxing and running different application, look at QubesOS, which is already far along and has it's own baremetal hypervisor, which is much like how docker works in userspace but optimized all the way to bare metal hardware. Fuschia takes a similiar approach when looking at optimizing modularity in mobile computing hardware architecture.
" Also, several other mobile operating systems that did not quite make it or continue to struggle."
This is true, but this is coming from the same company who has experience designing both software and mobile hardware architecture. Just because something is not already popular and widely adopted isn't a reason not to do it. I'm always an anti monopoly person myself, especially in the world of technology.
You can read my other comments and see the justifications around the need for this. As someone coming from the hardware architecture design space for qualcomm snapdragons all the way to 14nm iphone architecture, there is a need to remodularize kernel for advanced execution and increased competition in this space. POSIX is not sustainable looking 10-20-40 years into the future of hardware computing, particularly in the next ten, and android game developers who make a living off of candy crush do not really seem to care about this impending doom, only that they will have to traverse yet another learning curve if the platform gains adoption or become competitive in the space, which sucks, but it's not as bad as you'd think.
Besides, forcing people to continue to traverse learning curves keep the market competitive and keeps people from becoming to religiously entrenched that google's current android API is an unattested god. Yeh, its hard to make money sure, it's competitive sure, but we so easily forget android was a first stab and open source response to the iphone. The first motorola android phone came out my sophomore year in college. Now people can't imagine how we would survive without their 6yr olds going to school without an iphone 7. We often assume we need things to be the way they already are, and are not accustomed to change, but I can tell you Fuschia is needed in the space, operating system competition is needed in the space, and in the next decade we will be evolving to think different about excessive use of memory, dependencies and latency and be looking for something like this, luckily it will be about a decade into development at that point, about what android is now, and people say it's unreasonable to consider anything else..
If it wasn't for these groups of volunteers that translate them to english (and the other way around, also useful) these projects would be completely unaccessible.
Perhaps, but how much is in China? And how much 30 years from now?
If you had to use software in English, regardless of your native language (and mine is not English, it does not even have a latin alphabet) you'd need to have at least some proficiency with being able to read it which sooner or later make you able to write it.
I've seen that first hand: i am 99% self-taught when it comes to English and the only reason for that is that when i started using computers and got interested in programming, everything was in English. I had to learn it, otherwise i wouldn't be able to use my computers.
(and FWIW i wouldn't be surprised if a major reason that Japanese programmers are both bad at English and they tend to use their own and/or different software than the rest of the world today does is that they got translated documentation, software and computers from the earlier days of computing - essentially creating an unnecessary big barrier between themselves and the rest of the world)
In my opinion it would create a really sad mono-culture... Each language carry part of its history and culture that can't be translated at all.
It would also prevent a big part of the population to access any content. Even if you apply it to software only, it means that a big part of the world wouldn't be able to use any of those.
Now, if the software that you need to use to be able to learn English are in English, that becomes even more of an issue...
Also, why English in particular? For a huge amount of the world population it requires to learn a new alphabet. It becomes a much more complex requirement.
Is everyone supposed to learn Chinese to be able to read interesting articles ? What about Korean ? What about Wolof ?
Sharing a common language bring a lot to mankind as a whole, and is more effective to create bridges between people than most other means. Local languages are of course welcome and should be kept around for culture, but I do think that refusing to use a common language is a loss.
As for why English, well it's a bit late to ask the question imho : English has been picked as a common language quite a few years ago. There was French in Europe before, latin before that, but now it's English. I'm not especially happy about it either, since I'm not a native speaker, but here we are, and it's kind of pointless to fight against it when a big and diverse part of the world population already speak English (diverse is important, having 2 billion of people speaking a language in only one country is not really helpful for a common language).
Many of us native speakers aren't happy about it either, English is a terrible language. I have a 6-year old daughter, and across the years we have spent teaching her language skills I have learned just how messy English actually is. Watching DVDs and reading books about pronunciation rules that quite frankly even I never quite grasped until teaching my own child, it's enough to make your head spin.
Rules? Hah!
Apparently it is, otherwise we wouldn't be in thread discussing more and more interesting content only being available in Chinese. Users will learn whatever language provides content they want to consume. For me that was English. My parents learned Russian. I'd not be surprised if the next generation learns Chinese, though I'd prefer not having to do so (parents english isn't great).
Your arguments for English keeping its spot are kind of weak. It was surprising to read how few people speaking english. Wiki "English-speaking world" states just 500m-1b global and first language is less than 360m, 2/3 of those in the US. Class differences might ensure there is still more content produced in english, but china might catch up quickly and having just half as many speakers doesn't give a good head start. It being close to European languages might help, at doesn't require to learn a totally new alphabet. I would have expected English to get a nice boost due to geopolitics, but am not sure that is the cast past 2016. The US is still highly influence, due to media exports and probably most importantly dominance on the internet. China's firewall/separated Internet might save English. Though it might also protect their own language long enough to start to produce enough content to export...
Actually, I just realized how few recent popular Chinese films I've heard of. Guess I'll choose some to download, now.
Yes.
> In my opinion it would create a really sad mono-culture... Each language carry part of its history and culture that can't be translated at all.
That history and culture is only relevant to those who are interested in history and cultures, not to everyone. I am not against this, nor against other languages. People can still use English as a second language, i am talking about having a common language so we can communicate with each other, not a single language.
> It would also prevent a big part of the population to access any content. Even if you apply it to software only, it means that a big part of the world wouldn't be able to use any of those.
My point is that that population should learn to at least read English so that not only they will be able to use the software, but also read the texts from other people outside the silo that their own native language creates.
> Now, if the software that you need to use to be able to learn English are in English, that becomes even more of an issue...
No, the software to learn English can be in any language. In fact i'd rather see all the effort that goes into internationalization and localization to be placed instead into creating better software, tutorials, documentation and other materials for software that teaches people English.
> Also, why English in particular? For a huge amount of the world population it requires to learn a new alphabet. It becomes a much more complex requirement.
Because it is already used as i mention by a very large number of people, especially around computers.
The alphabet isn't a big issue, as i wrote above, i had to learn it myself and English has one of the most compact and easy to learn alphabets.
Nobody is obligated to go through the hassle of learning a new language just because someone else wanted that knowledge (volunteering to share, however, is perfectly fine). Otherwise it is a blatant infringement of personal freedom. Multilingualism should also be multi-directional instead of converging towards a single language, but that is obviously something unnoticed by a lot of Anglos who for one reason or another have decided their language and culture should trump over all else.
Languages are primarily a tool for communication and i am interested in the practicality of improving that communication - if two people speak different languages and without any common one, they simply cannot communicate.
I do not care if it would be English, Chinese, French or whatever else, that choice is irrelevant. I only said Yes to English because of its popularity, widespread use among many different countries and its position when it comes to computers (which was my original point above).
English isn't even in top 4 of world spoken languages, so I have no idea why you chose is as the OnlyRightLanguageToBeUsed(tm)?
How do those two go together?
By what measurement? Wikipedia gives Mandarin > Spanish > English > Hindi for native speakers[0] and English > Mandarin > Hindi > Spanish for all speakers.[1]
[0] https://en.wikipedia.org/wiki/List_of_languages_by_number_of...
[1] https://en.wikipedia.org/wiki/List_of_languages_by_total_num...
You can learn Pinyin in a few days, which is sufficient for you to pronounce any Mandarin Chinese romanized into Pinyin. Chinese grammar is fairly simple compared to Latin languages. Whereas English is a rats nest of special-need-to-memorize pronunciation rules.
Most of the real difficulty people experience with Chinese comes from the shock of learning the characters.
At least from my perspective, someone who knows a language very close to another and still found English easier than this other language, English is easy.
Pronunciation is indeed quite a lot of learning by heart, but it's not hard to get used to if you got the rest down. Of course, this might be much harder for Chinese, I wouldn't know.
2. One good-sized chunk of the messiness of English pronunciation (vs. written words) is actually the fault of the Dutch. Prior to the printing press spelling was more an art than a science, and the same transcribed book could be found with different spellings (especially true in different regions). Since the Dutch were the first ones with the printing press, many English books of the time were printed there, and the Dutch printers made some pretty arbitrary decisions on how they thought English should be spelled (e.g. the 'h' in 'ghost'). There was a similar effect from French scribes when they invaded England.
Now my no means were they they only ones to mess up English (read up on "The Great Vowel Shift" if you want a headache), but they did their part.
I'm not a native English speaker and have made an attempt to learn Chinese.
To me memorizing how hieroglyphs look was harder than any part of English. One need to have a good visual memory to find that easy.
"Definitely" has 19 "strokes"
"Speaker" has 14 strokes
"Visual" has 10 strokes
"Made" has 9 strokes
9 strokes is a lot in Chinese, but relatively few in English. And despite what anyone says, you can't learn English using phonics or any other method except bulk memorization. In English, every word and every one of its derivatives has to be memorized. Past tense, possessive, plural, everything has to be memorized. Nobody bats an eye at this. Learning 8 strokes for "tree" is easy, but the 4 strokes for the Chinese equivalent is hard. 12 strokes for "water" is easy. 5 strokes in Chinese is hard. Oh, and throw on 4 more strokes in English if you turn it into a verb and use the past tense, "watered". Unless you write "did water" instead and split them up with a noun in between: "did you water". What a disaster.
I am a native English speaker. I like to think I am decent at it. Better than most of the people with whom I speak in person. But did I just use "whom" correctly? And did I just start a sentence with "but"? And "and"? And leave out the subject? Is this even proper English?
I won't let Google manage my data for me, but if they can keep their fingers out of the pie I would gladly use a Fuchsia-based system as described here for my laptop, phone, and home desktop.
I'm not sure if this is a translation gaffe or not, but I'm using it as a new sick burn for sputtering projects.
Fuchsia doesn't share as much of the story but does pick up where in Dante's Inferno the original Unix people tried to abandon the root user to redeem themselves almost 30 years ago. Combined with capability based model last seen deployed in the wild with OS/400 and Burroughs machines before that, it would be the first truly new OS in decades.
Although it would be wrong to consider Go as a derived product of Plan 9, I think it is right to call it its intellectual successor (although not the only one).
Perf isn't the best comparison right now, as I've heard that kernel perf is a non goal at them moment. I think they want to build out enough of the OS to know where the best bang for their buck is when optimizing.
>"/" -> root vfs service handle, "/dev" -> dev fs service handle, "/net/dns" -> DNS service handle
Just resurrect Plan 9 already?
> "Everything is a URL" is a generalization of "Everything is a file", allowing broader use of this unified interface for schemes.
It makes sense to me - not every resource can reasonably be shoehorned into the file-folder abstraction.
[1] https://doc.redox-os.org/book/design/urls_schemes_resources....
It's not like OpenGL is the greatest graphics API, it's just that it's been used for decades - I personally learned 3D graphics rendering in GL and I still think in GL when I'm compositing a scene in my head.
If I'm going to prototype something, I have historically loved that no matter what platform I'm on, I can pretty much just hit 'compile' and I'll have the same result.
Which leads me to my second complaint - Metal. When Vulkan has come out as the clear choice for next-gen multi-platform graphics technology, Apple, once again, decided to completely invent a proprietary system instead of using the low-hanging fruit that was already there.
Especially since I thought of trying it out and followed Fuchsia instructions[0] only to run into exactly same problem building it that others have reported >3 months back[1].
Also, instructions to download and install jiri with curl under Fuchsia docs don't work either[2] and curl returns '404 not found' instead. Got around this using instructions here [3] only to fail soon after as per above.
[0] https://fuchsia.googlesource.com/docs/+/a40928d45b43dbf72d5e... [1] https://www.reddit.com/r/Fuchsia/comments/a56rg7/issues_when... [2] https://fuchsia.googlesource.com/docs/+/a40928d45b43dbf72d5e... [3] https://fuchsia.googlesource.com/jiri/#Bootstrapping
I feel attacked. Glad they're picking up seriously on the idea of namespaces.
> A channel has 2 handles, h1, h2, write messages from one end, and read messages from the other.
This seems like it's bound to be a critical section for many operations. So for one/some of the supported target architectures, what's an example of how channel write/reads look in detail? Do I need to trap or can I write "directly" into pages that the recipient can read? Can messages span cache lines?
I believe that Fuchsia sounds ambitious and it's only through the dedication of mega-tech corps like Google/etc that ambitious efforts like this can succeed. But the world in general, even the tech world, is loathe to accept change. Backwards-compatible layers to emulate the linux syscall layer would probably be a critical transition feature. This allows consumers to phase in the work required as they can stomach it, rather than suffer it all-at-once-or-nothing.
How hard is it to port Fuchsia to a new target? Can anyone point me to a series of commits for a target that does this?
About the only upside of the Android ecosystem was the kernel's license, forcing kernel drivers to be open-sourced. This allows mainlining back devices into the Linux tree, which enables a variety of user projects, such as postmarketos.
On the other hand, some of these drivers already acted as a shim to a userspace blob, and having an IPC would at least provide isolation from the blobs themselves, and allow tapping a clear IPC interface for reverse-engineering those. So all might not be lost.
On the sustainability of open source, since this seems to be debated much in this thread, I personally think (and it is a debatable viewpoint) that this ought to be incentivized at a government level (by taxing software/technology sales, and sponsoring open source projects with the proceeds). This would provide a much more robust base on which to provide (proprietary if you want) services upon.
1. MessagePack (instead of, say, FlatBuffers – am I wrong to think that FlatBuffers are more efficient? (and the format was created by Google))
2. ELF binaries (instead of, say, taking a clean-sheet approach to executable formats)
Also, on ELF they say: "The loading position of the ELF is random and does not follow the v_addr specified in the ELF program header."
(They're talking about ASLR.) This just highlights for me that a more efficient format is possible, one that doesn't have a virtual address in its headers. Perhaps there are even bigger wins possible with a clean-sheet format.
My guess is also because its easear to have a bridge with Linux executables, so you can run the same ELF and emulate the linux syscalls somewhere like FreeBSD and now Windows .
I bet they were thinking about running Android stuff more easily, and i dont think there will be much more to gain in designing a whole new executable format, when you compare how much of free tools, code and compatibility with Linux you will have in the end.
"Global file system
In Unix, there is a global root file system"
Why night this be seen as a shortcoming, especially with mount namespaces now? Can anyone say?
https://news.ycombinator.com/item?id=19254828
That should be impossible in Fuchsia.
Pick one. Have we not learned from the past that there really is not a one size fits all operating system for all use cases. I am probably alone in thinking this, but bad decisions can be made when trying to get a server OS to run on a phone.
We build on top of seL4 for these reasons (among others).
Who's we? I too am down with OTP, especially OTP on seL4. ;- )
I was just answering the "Who's we?" question.
Probably the easiest frame to think about what we're doing is building engineering automation products for systems & robotics engineers.
We ultimately want to do for those classes of engineers what things like CAD, FEA, EDA, etc. did previously for mechanical & electrical engineers in terms of managing complexity and amplifying their capabilities.
Isn't seL4's multicore support either unverified or limited (i.e. shared memory is forbidden)? Is your platform single-threaded then?
https://9to5google.com/2019/03/20/google-hiring-node-js-fuch...
A micro kernel is a big sell for regulators/QA. Also, being a RTOS.
This would disrupt many big players in the field, such us QNX.
Just requires that willpower to spend some time memorizing a whole bunch of words.
Can anyone advise me on an efficient way to do this?
Nice!