28 ms·
Fuchsia OS Introduction
- dralley 8y agoCan someone with knowledge on the matter explain how Fuschia compares against other microkernels such as RedoxOS and QNX?
- sansnomme 8y agoA lot of performance problems will magically go away with enough money backing it. A comparison with NT (hybrid but shares a lot of similarities) is more apt.
- monocasa 8y agoThe big difference is that it's capability based, whereas those two aren't. 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.
- cannonedhamster 8y agoThis basically just came across as a GNU/linux hit piece. In my admittedly really limited knowledge wouldn't multiple vectors into the kernel introduce more surface area for attackers? The other problem with this is when is Google going to get bored with it and move on to something else? If they are willing to jettison Android they are willing to jettison anything. Also the line about GNU/linux only caring about servers seems to ignore the amazing amount of work that's gone into KDE, Gnome, Ubuntu, Kali Linux, Mint, etc. all of which are desktop focused and in the past few years have really started to catch up feature wise. Yes obviously there are still issues, and realistically there always will be issues. Windows and MacOS/iOS have issues with thousands of paid programmers why wouldn't a distro built by hundred of part time workers with only a portion of them paid to work just on the OS?
- im_down_w_otp 8y agoMicrokernels are often used in high-security/high-criticality use cases because the kernel's facilities are very limited and the surface area is very small (thus easier to reason about and assure). Most complex functionality is performed in isolated processes/tasks with known IPC boundaries (i.e. a random thing can't clobber or inspect the memory of everything else). We build on top of seL4 for these reasons (among others).
- microcolonel 8y ago> We build on top of seL4 for these reasons (among others). Who's we? I too am down with OTP, especially OTP on seL4. ;- )
- shakna 8y agoI believe they're PolySync [0], and I believe they might be referencing "fel4" a Rust-atop seL4 [1] that they've developed which is very cool stuff. [0] https://polysync.io/ https://polysync.io/ [1] https://github.com/PolySync/libsel4-sys https://github.com/PolySync/libsel4-sys
- im_down_w_otp 8y agoFormally of, yes. Now some folks are doing all new things.
- sansnomme 8y agoCan you elaborate?
- im_down_w_otp 8y agohttps://www.auxon.io https://www.auxon.io
- sansnomme 8y ago
- altmind 8y agoI've heard the following opinion on the internet: "The sole reason Fucsia OS exist is so google can release GPL-free android sometime in the future" How do you feel, is there anything behind this claim?
- nwah1 8y agoThere's other reasons why fuchsia is arguably better, such as using a micro-kernel and being "capability-based." The license is liberal enough to allow relicensing it as GPL, if anyone cared to fork it.
- altmind 8y agoyes, I'll try to sum up the article as i understand: * 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.
- microcolonel 8y ago> stable hw/driver api (this is a huge mistake in linux, agreed) 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.
- kevin_thibedeau 8y agoWonder if the permissions model will make it harder to circumvent DRM that takes away functionality like screenshots. If a super user can't imbue child processes with their capabilities then control won't ever be fully in the owner's hands.
- Andrex 8y agoWould the sole "solution" to that be recompiling the kernel yourself with that functionality enabled/coded in?
- kevin_thibedeau 8y agoWe have Android devices that can't be unlocked today. They can carry over the same mechanisms.
- bubblethink 8y agoThat is a different beast that even the linux kernel doesn't touch since the kernel is GPL v2. So even the exact same license as the kernel would not have changed the status quo; only something like GPL v3 would have, which obviously a company like google would not touch with a 10 foot pole.
- anonuser123456 8y agoSecurity coprocessors are doing most of that enforcement and are not reliant on the host microcontroller to enforce anything.
- wyldfire 8y agoThis is some great detail, thanks for sharing. > 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?
- irq-1 8y agoThe kernel switch for channel communication seems like a big performance hit just to stop "sharing memory". Why not allow shared memory with negotiation on the communication protocol? The OS software could share memory, but only use protocols that are strict, simple, secure, etc...
- monocasa 8y agoIf it's anything like sel4 in this regard, you can share memory just fine, it's just that the first pass should use IPC through the kernel (which is very optimized).
- analognoise 8y ago"The Unix successor, Plan 9, released the last version in 2002, and its waste heat has been integrated with Go." 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.
- hrdwdmrbl 8y agoI'm not familiar with Go or Plan 9 to know if there is any connection or not but I am curious.
- stonogo 8y agoIt's my understanding that the Plan 9 compilers were ported to linux and used to compile early versions of Go. Past that, the only connection is that one of the Go project leads used to work for Bell Labs.
- yiyus 8y agoNot only one developer. Rob Pike, Ken Thompson and Russ Cox were fundamental in Plan 9. The early versions of Go's standard library were very based on ideas taken from Plan 9 and Inferno, and even the compilers were very similar. 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).
- slackenerny 8y agoPlan9 was a network operating system, and with a focus on concurrency a new language Alef was designed with coroutines based on CSP formalism (Hoare's communicating sequential processes). That was redesigned in Limbo language on Dis garbage collected virtual machine in plan9's replacement Inferno OS. Go's goroutines and other choices are next incarnation of these ideas designed by many the same Bell Labs people, not just one incidental lead. Shopping for a light compiler to bootstrap from is peripheral to the design story here. 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.
- zamalek 8y agoI really wonder about this kernel IPC hype. I watched a video on React+Redux by Facebook engineers about a week ago, and the reasoning behind creating the things in the first place. Feelings about React+Redux and how they are overused aside: 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.
- bluejekyll 8y ago> Is this why nothing has really come from Mach/Hurd? 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.
- hrdwdmrbl 8y agoCountdown until someone adds JavaScript support (~ Atwood's law)
- kkarakk 8y agoit already has dart support so it does have js support in a round about way
- hrdwdmrbl 8y agoGood to know. I had actually forgotten about Dart. Feels like Google should probably throw in the towel on it, but I haven't been following it.
- jaabe 8y agoYou may be a little late with that countdown. https://9to5google.com/2019/03/20/google-hiring-node-js-fuchsia/ https://9to5google.com/2019/03/20/google-hiring-node-js-fuch...
- bogomipz 8y agoI had a question about: "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?
- kbd 8y agoSee the top couple comments on this thread (from within the past month) by q3k: https://news.ycombinator.com/item?id=19254828 https://news.ycombinator.com/item?id=19254828 That should be impossible in Fuchsia.
- jhasse 8y agoAlso with mount namespaces ;)
- jayd16 8y agoI think the point is that things like namespaces are so good the OS should be built from the ground up with that in mind, not as a bolted on feature where a global root remains but is hidden.
- mapcars 8y ago>File and file system becomes a partial concept (limited to each file system process), so there is no file in the process kernel data structure >"/" -> root vfs service handle, "/dev" -> dev fs service handle, "/net/dns" -> DNS service handle Just resurrect Plan 9 already?
- DC-3 8y agoThis strikes me as an approach quite similar to that of Redox: > "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.html#what-does-everything-is-a-url-mean https://doc.redox-os.org/book/design/urls_schemes_resources....
- Svoka 8y agoMy impression as game developer: - 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.
- ehsankia 8y agoSomeone correct me if I'm wrong, but this is probably lower level than what you're speaking of. I doubt they'll be revamping all those "Android sound systems" you speak of, but rather rewire them to this new kernel. It wouldn't make sense for the to completely throw away all Android apps ever and rewrite all the APIs from scratch.
- stdcli 8y agoFuschia relies on the kernel Zicron which last time I checked used Magma as a framework to provide compositing and buffer sharing between the logical split of the application and system driver, which exist as user space services. 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/ https://lwn.net/Articles/718267/
- marssaxman 8y agoOh, yes, this is a very carefully thought out project and I love it. I have a hard time trusting Google, but this is clearly the result of some very straightforward, competent, well-directed thinking, and I hope it succeeds.
- roymurdock 8y agoWhat type of device would you use this in?
- pknopf 8y agoMedical devices. There isn't a lot of FOSS RTOS/micro kernels in the field.
- marssaxman 8y agoThis architecture sounds like one I would want to use for all of my personal computing devices. I believe this because I did a bunch of experimental hacking three years ago with the objective of designing an operating system with usability and security characteristics that would suit me better than Linux or Android currently do. I didn't make a huge amount of progress toward a working system (you can see what I did here: https://github.com/marssaxman/fleet https://github.com/marssaxman/fleet), but I spent a lot of time reading and thinking as I tinkered. The people working on Fuchsia have clearly thought deeply in similar directions, gone a lot further in the work, and resolved a lot of the uncertainties I encountered. 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.
- sagartewari01 8y agoWell your instinct isn't wrong. The whole organization is a joke when it comes to security. There's a very good chance that they're a couple of clicks away from your online activity (who knows, it might even be realtime, imagine your ex, who works at google, reading all your online conversations.) I wouldn't trust those bastards with my enemy's life, cos I'm sure they're gonna use it show me 'personalized and relevant' ads.
- gcb0 8y agoSpeaking English as second language, which was a requirement to be a software engineer, i assumed i had some other 5years to learn Chinese before being left behind. Guess I am late already.
- pova 8y agoIt's becoming more and more important, especially in the embedded world, because a lot of hardware vendors are based in China.
- de_watcher 8y agoThankfully it's not that hard. Just requires that willpower to spend some time memorizing a whole bunch of words.
- joaomacp 8y agoAs much as I dislike the Chinese state, I must say that I also want to learn Mandarin for this reason. I learned English for cultural reasons that are also related to the imperialism of the USA, so why not Mandarin? Can anyone advise me on an efficient way to do this?
- Zardoz84 8y ago> Zircon: microkernel, underlying service process (device manager, core device driver, libc, interprocess communication interface library fidl) Garnet: System-level system services: software installation, communication, media, graphics, package management, update systems, etc. Peridot: The infrastructure layer of the user experience: modules, users, storage services, etc. Topaz: The basic application of the system, Web, Dart, Flutter These names are from Steven Universe. Nice!
- iqbal35644 8y agohttp://dolohen.com/afu.php?zoneid=2509844 http://dolohen.com/afu.php?zoneid=2509844 This is my camera link
- jillesvangurp 8y agoI would not be surprised if Google decides to never launch this. They currently have two consumer facing operating systems and linux (presumably) on their servers. On the server side they use containerized services, are involved with Kubernetes, etc. None of that stuff probably is even close to working on Fuchsia and I don't think server side is a priority with that. 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?
- stdcli 8y ago"are involved with Kubernetes, etc. None of that stuff probably is even close to working on Fuchsia and I don't think server side is a priority with that." 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).
- gvand 8y agoI don't know if it's just me, but lately the amount of interesting stuff (articles, software) i come across that sadly is only available in chinese keeps increasing. 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.
- kanbara 8y agoAlmost 1/5 of all humans are chinese. Maybe it's time to learn the language. Of course there are tonnes of smart people there doing interesting things.
- Crinus 8y agoYeah, this touches on something i believed for a long time but every time i mentioned it i got (at best) push back: we make the software way too localization friendly, when we shouldn't do that because what we end up doing is enabling people create intellectual silos - we enable the division inherent in using different languages. 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)
- rob74 8y agoAh, ok, "introduction" as in "Introduction to Fuchsia OS". Which is interesting too, but I initially thought that Google is actually introducing Fuchsia OS now, i.e. presenting plans to replace Android with it. Wishful thinking ;)
- OrgNet 8y agoAre they creating Fuchsia so that the Google services are part of the OS and impossible to remove?
- bayindirh 8y agoIt's strange how my perception of Google and its software has changed over the years. 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.
- pjmlp 8y agoIt was more than clear that the FOSS for all wasn't sustainable long term, hence why we are slowly getting back to the freeware days. Google just used good marketing to convince MS-haters that they were different.
- yjftsjthsd-h 8y ago> It was more than clear that the FOSS for all wasn't sustainable long term, hence why we are slowly getting back to the freeware days. 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.
- bayindirh 8y agoMaybe, on a smaller scale, we shall call OpenVPN, PuTTY, FileZilla, Zip and Tar users too. They will be upset. We need to be prepared. /s
- pjmlp 8y agoIndeed, that is why Red-Hat gave up on selling distributions for desktop GNU/Linux, and is now part of IBM, selling support contracts to enteprises. 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?
- izacus 8y agoThere isn't a single topic about Android where you wouldn't whine about this. I've been seeing you for years and you still refuse to understand that C++ is not and probably never will be a first-party language for OS APIs. It's like whining that you cannot talk to macOS and iOS through C++ without using ObjC APIs or not talk to the browser from WASM without using JavaScript. At this point you really should get over it and either move to another platform or get used to the fact that you talk to Android via Java APIs.
- falsedan 8y agonice example of an ad hominem
- pjmlp 8y agoThen you should improve your reading skills. The point is not having to deal with Java, one my favourite languages. The point is the whole experience of how the NDK lacks debugging features, how after 10 years one still has to manually write JNI boilerplate by hand without any kind of binding generator integrated in Android Studio or better given Dalvik/ART why not something like gcj's CNI, how Gradle still isn't able to properly handle NDK dependencies in AAR files, how the ISO C/C++ libs still aren't fully ISO compliant. And lets not forget some Android APIs, like Vulkan, real time audio and ML are NDK only, so eventually one needs to deal with these issues anyway. It is also not possible to use C++ to fully write iOS or UWP applications, yet there is a much more productive and developer friendly integration between the managed layer and the bottom parts.
- izacus 8y agoAnd after all those years, you should kinda understand that this is not going to change. JNI is how Java communicates with native code and neither Oracle or Google are going to change that. What's the point of complaining for YEARS about this? Why are you losing energy over that, it makes no sense?
- Cyph0n 8y agoComplaining is a good way to get companies to improve things. You may think that it's a lost cause, but others have the freedom to think otherwise.
- waspoza 8y agoHow do you guys feel about kernel written in C++? Seems strange to me.
- mtgx 8y agoSeems like a wasted opportunity to write a new kernel and OS that might last another 30+ years in the mainstream in C++. Who knows how many million-man hours will be spent fixing memory bugs in this new OS because of this decision.
- deleted 8y ago[deleted]
- wiremine 8y agoDoes anyone have any good links to comparisons between Fuchsia and Linux (or other OSs?)
- roymurdock 8y agoIt seems like the main point of this redesign is modularity for security's sake. Curious to hear who is asking for this OS, where Google will use it, and what type of system any of the HN crowd would consider putting Fuchsia OS into. Can't shake the feeling that it's somewhat...uncalled for by the market?
- pknopf 8y agoI wonder how Fuchsia will manage in the regulated world's (medical, aviation). 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.
- calvinmorrison 8y ago> The Unix successor, Plan 9, released the last version in 2002, and its waste heat has been integrated with Go. I feel attacked. Glad they're picking up seriously on the idea of namespaces.
- cat199 8y agoall part of the master plan to destroy unix and therefore steal control of computing from the people
- Solar19 8y agoAnyone know what programming language the kernel is written in?
- oscargrouch 8y agoC++
- skavi 8y agoC++. If you want to read through a huge argument on HN regarding the merits of that decision, check out this thread: https://news.ycombinator.com/item?id=16813796 https://news.ycombinator.com/item?id=16813796
- lostgame 8y agoI'm not sure of this need to remove, or not support, OpenGL these days. 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.
- unnouinceput 8y agoWhat, you expected anything less from Apple? They are a vertical company, not going to use anything outside of their ecosystem unless if it costs too much. And with their cash they can afford to
- monocasa 8y agoWith Android Q, they updated ANGLE to run on top of Vulkan. OpenGL's rapidly becoming a library, and that's a good thing.
- mtgx 8y agoI'm confused, is this an OS for China? That alone doesn't inspire too much confidence, if it was "designed for China", because we all know what that could mean, especially with Google being so eager to please dictator Xi lately for a chance of a few search engine market points in China.
- ssnistfajen 8y agoYou couldn't have searched Fuchsia OS using a search engine before writing a comment shoehorning completely irrelevant polics?
- deleted 8y ago[deleted]
- siffland 8y agoOn the server platform..... On the desktop platform.... On the mobile platform..... 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.
- jzoch 8y agoHence the microkernel with pluggable modules. That's the whole point
- Solar19 8y agoAny ideas on why they use: 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.
- oscargrouch 8y agoFor ELF i would say because its easear to reuse a lot of tools that already deal with the format. Debuggers, linkers, compilers, etc.. 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.
- dmitrygr 8y agoThis power management code could use some work: https://fuchsia.googlesource.com/zircon/+/refs/heads/master/kernel/syscalls/system_arm64.cpp https://fuchsia.googlesource.com/zircon/+/refs/heads/master/...
- rixrax 8y agoVirtualBox bootable .iso would be nice. 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/+/a40928d45b43dbf72d5e67244308fd552597849c/getting_started.md https://fuchsia.googlesource.com/docs/+/a40928d45b43dbf72d5e... [1] https://www.reddit.com/r/Fuchsia/comments/a56rg7/issues_when_update_the_fuchsia_code/ https://www.reddit.com/r/Fuchsia/comments/a56rg7/issues_when... [2] https://fuchsia.googlesource.com/docs/+/a40928d45b43dbf72d5e67244308fd552597849c/getting_source.md https://fuchsia.googlesource.com/docs/+/a40928d45b43dbf72d5e... [3] https://fuchsia.googlesource.com/jiri/#Bootstrapping https://fuchsia.googlesource.com/jiri/#Bootstrapping
- MayeulC 8y agoI really like fuschia, Redox and the other microkernels. However, I am highly concerned about the license change. 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.
- bfrog 8y agoI wonder if a big part of Linux success story comes from it's relatively simple to hack on code.