Beep Boop Bip
[Return] [Entire Thread] [Last 50 posts]
Posting mode: Reply
Name
Email
Subject   (reply to 2447)
Message
BB Code
File
File URL
Embed   Help
Password  (for post and file deletion)
  • Supported file types are: BMP, C, CPP, CSS, EPUB, FLAC, FLV, GIF, JPG, OGG, PDF, PNG, PSD, RAR, TORRENT, TXT, WEBM, ZIP
  • Maximum file size allowed is 10000 KB.
  • Images greater than 260x260 pixels will be thumbnailed.
  • Currently 1064 unique user posts.
  • board catalog

File 163509769455.png - (27.13KB , 436x439 , Google_Fuchsia_logo_svg.png )
2447 No. 2447 [Edit]
What do you think about the open source, UNIX-inspired Fuchsia(aside from it being developed by google). I am an ignoramus and windows user, but in spite of that, Fuchsia has(or will have) a few things that seriously appeal to me.

>Zircon is the core that powers Fuchsia. It is composed of a microkernel and a small set of userspace services, drivers, and libraries necessary for core system functions such as booting.
>Fuchsia’s filesystems live entirely within userspace. They are not linked nor loaded with the kernel; they are simply userspace processes that implement servers that can appear as filesystems. As a consequence, Fuchsia’s filesystems themselves can be changed with ease
>Due to the modular nature of Fuchsia’s architecture, it is straightforward to add filesystems to the system.
>Zircon is an object-based kernel. User mode code almost exclusively interacts with OS resources via object handles.
>In Fuchsia, almost everything is a component and it is the unit of executable software... Components can only use shared libraries that are included in the same package as the component... There is no concept of inter-package dependencies
>A given release of the Fuchsia platform typically supports multiple ABI revisions, which lets the platform run older applications
>This document proposes a mechanism for running unmodified Linux programs on Fuchsia... the Fuchsia system does not impose an opinion about the internal structure of components. In order to interoperate as a first-class citizen with the Fuchsia system, a component need only send and receive correctly formatted messages over the appropriate zx::channel objects... The programs are run in a userspace process whose system interface is compatible with the Linux ABI. Rather than using the Linux kernel to implement this interface, we will implement the interface in a Fuchsia userspace program

I like that it uses a microkernel, the filesystem implementation is so flexible, the kernel is object-based, and there's no possibility of dependency hell. As a windows user, I can't really understand or get behind Nix's "everything is a file" approach, or the ubiquitous sharing of dependencies between packages. Now, there's probably plenty of things wrong with the project on a conceptual or execution level, which is why I made this thread. I want to hear some opinions on this thing.
Expand all images
>> No. 2449 [Edit]
It has some nice ideas, but to me the limiting factor is that it's developed by google so it might end up like qnx which also had nice ideas but isn't widely adopted. Linux is great not because it brings revolutionary ideas to the table, but because it's neutral-enough that everyone feels comfortable using it and the maintainers are willing to merge in support for exotic architectures or peripherals. I'd never see google allowing the same degree of openness.

>Zircon is an object-based kernel. User mode code almost exclusively interacts with OS resources via object handles.
I've dabbled a bit with osx's kernel xnu which uses mach ipc a lot, and it feels neat but practically I don't know if it's better than syscall. I really like the message passing paradigm though, and at least on osx I feel that idea sort of permeates the entire stack, down from the mach aspects up through objective-c. I'll let someone else who's more familiar with systems research comment here on the benefits though.

Also it's interesting that they decided to create a separate IDL [1] instead of just reusing protobuf, given how widely that's used within Google. Although the wire format definitely seems inspired by it.

Also there's the fact that it's not clear if fuschia is a first-class project developed by google or whether it's just their fallback plan in case they want to move mobile/iot off of linux.

[1] https://fuchsia.dev/fuchsia-src/reference/fidl/language/language
>> No. 2450 [Edit]
>it might end up like qnx
>I'd never see google allowing the same degree of openness.
I'm hoping being open source and able to run linux binaries prevents these problems. At the very least, I'd like to see something which can run on an average laptop and wouldn't be less convenient than linux.
>> No. 2451 [Edit]
File response.pdf - (23.88KB )

2451
>>2450
Ugh I had typed out a long response but for some reason TC servr rejected it ("internal server error" – this has happened before and I think the cause was that the WAF used by TC's host trips far too easily) so I had to retype it, so forgive the curtness of the response. I've attached it.
>> No. 2452 [Edit]
>>2451
>so I had to retype it
Thank you for doing so.
>> No. 2453 [Edit]
>>2451
>It's not clear to me that google is going to put in the effort to develop the userspace parts since I think the target of fuschia seems to be IOT devices
Yeah, this will probably be dependent on google's aims. Chromebooks are a big deal for them though. It would make sense for them to make a fuchsia chromebook at some point if they use it for phones.

>Seems like FUSE. I believe that you can get 95% of the benefits through things like free bsd jails/openbsd pledge/zones, even–egads–containers
Ehh, but it's kind of a clusterfuck. All these different technologies made by different people with different aims and different standards, and then users are supposed to research them, hobble them together, and deal with the potential conflicts and overhead. Having it all built in and working together seems so much cleaner.

>this could technically be done on linux as well if people would stop the obsession with dynamic linking everything
Not giving the option seems like a great way to stop the obsession. Flatpaks are still dependent on repositories and also require "flatpak" to be installed, so they're not satisfactory to me.

>if I recall, it's glibc which messes thing up
I looked into it, and appimages don't work at all on systems which use musl. So much software is tied to glibc, so even if there's a superior other option, it's hard to switch. Fuchsia actually uses a fork of musl, but programs can use their own libc.
>> No. 2456 [Edit]
>>2453
>Chromebooks are a big deal for them though. It would make sense for them to make a fuchsia chromebook at some point if they use it for phone
That would assume google has a coherent strategy and grand narrative. They don't. In the end it ends up being team politics guided not by a grand vision but by team leads angling for promo and engineers guided by perf. Viewed through that lens, I think it's unlikely the people who built their career on promoting chromeos are going to allow fuschia to replace it. Ditto for android, which is why fuschia has been relegated to IOT things like nest hub.
>> No. 2457 [Edit]
Newest article
https://9to5google.com/2021/10/08/google-fuchsia-expanding-additional-smart-devices/
>> No. 2458 [Edit]
>>2457
Better article: see the jedi blue/nera leaks from google about how they stated point blank their aim to create an internet dominated by them

>Google had a plan called "Project NERA" to turn the web into a walled garden they called "Not Owned But Operated". A core component of this was the forced logins to the chrome browser you've probably experienced (surprise!)"

Just because a project is open source doesn't mean that it's neutral. Chromium is "open source" and yet it's almost wholly controlled by google. Sure there are forks like brave but at the end of the day it's all basically a reskin of chrome. And firefox conveniently gets worse just as chrome is approaching peak market dominance, so much so that I'm convinced of a shadowy conspiracy that Google at least played some part in the executive shifts at the mozilla foundation.
>> No. 2460 [Edit]
>>2458
>Sure there are forks like brave but at the end of the day it's all basically a reskin of chrome
And who's fault is that? Any person or group with sufficient time and motivation could make a browser based on chromium that suits their tastes, privacy, ui and feature-wise. Even if you argue it's a moving target, so what? A browser that supports most websites is good enough. There's still people that use ie or falcon.

>their aim to create an internet dominated by them
Which is only tangentially related to fuchsia because it's mostly deployed on iot devices. Google is no different from AT&T before they were broken up. If anything, AT&T was worse since they didn't open source anything. Fuchsia will be around regardless of what happens to google.

I don't feel like forever being complacent with a worse option just for the sake of ideological purity.

Post edited on 26th Oct 2021, 5:58pm
>> No. 2461 [Edit]
>>2460
> Any person or group with sufficient time and motivation could make a browser based on chromium that suits their tastes, privacy, ui and feature-wise
Having a browser "based on chromium" is really no better than chromium itself, and theoretical possibility doesn't bear out in the real world. Unless you're ok with rebasing to older version of chromium and using that for perpetuity (which might honestly be fine if you disable js), the efforts required to continually rebase to HEAD are pretty high. In fact as far as I'm aware blink (the rendering engine) and the overall security model of Chromium are really tightly coupled together, so much so that you can't choose piecemeal which pieces you want, it's all or nothing. Now I guess it's "theoretically possible" that maybe someone can go through and uncouple just the rendering engine out, but the fact that no one has done it makes me thing it's a non-trivial task. It'd be easier to just work with webkit. But that opens up another can of worms, because Apple intentionally cripples webkit in other regards to push native mobile apps over web apps (I'm not a fan of most PWA's anyway, but just showing that it's not an easy battle to win)

The only greenfeld rendering engine I've seen is that experimental one by Ekioh, and it's a sad state that the most innovation here has come from a company targetting set top boxes.

>Fuchsia will be around regardless of what happens to google.
Again, just because a project is open source doesn't mean that it's immediately adopted by the community. While I'm willing to bet that if Google dies blink will live on in some incarnation (after all, webkit has survived this long), I think it's unlikely that fuschia will. In fact it's more likely the hobbyist ones such as Haiku will survive longer, because it actually has a userbase that's excited to use it and cares about it.

Or to take another example, XNU (/Darwin) is technically "open source" but we all know that it's really just at Apple's mercy and it's a monumental effort to even build it. But at the same time, LLVM is doing really well, presumably because that in part grew out of academia. There's no way to know for sure which way Fuschia will go, but given Google's history I'd wager that it's abandoned by google in less than a decade.

>I don't feel like forever being complacent with a worse option just for the sake of ideological purity.
There are plenty of other OSs and kernels out there: Qubes, Haiku, BSDs. And better yet you can actually install them right now, and there's an actual community around it. Yes Fuschia interesting on technical grounds, but so are a dozen other projects. Take a higher level look at fuschia: the reason they're moving everything into userspace is because it's much easier to have closed-source proprietary drivers/modules that way. No need for manufacturers to abide by that GPL and release source. And based on the history of all of Google's other projects, you can bet that if you're not part of the company then anything other than minor contributions are going to be blocked.
>> No. 2462 [Edit]
>>2460
>If anything, AT&T was worse since they didn't open source anything. Fuchsia will be around regardless of what happens to google.
Wasn't the fact that bell labs unix was proprietary which led to linux? In a way that's at least nicer since there's no hidden agenda.
>> No. 2463 [Edit]
>>2461
>Unless you're ok with rebasing to older version of chromium and using that for perpetuity
That's what I meant. Isn't that what Pale Moon did?

>doesn't mean that it's immediately adopted by the community
Well, there's daliahOS. That's something.
https://dahliaos.io/

>Fuschia interesting on technical grounds, but so are a dozen other projects
It's not appealing only because it's interesting. I might as well use Singularity if that was the only thing I valued. You may be completely right that things will turn out like they did with Darwin, but for now I'm optimistic. Even Chromium OS is open source, so Google is different from Apple in some sense.

Post edited on 26th Oct 2021, 9:11pm
>> No. 2464 [Edit]
>>2463
>so Google is different from Apple in some sense.
If you want to believe that, then go ahead. But any project that's primarily spearheaded by a company run by money grubbing execs is not one that I would personally put my trust in. See also recent ms .net saga

https://dusted.codes/can-we-trust-microsoft-with-open-source

The "community" will never be a first class citizen in such projects maintained by companies.

Post edited on 27th Oct 2021, 1:26pm
>> No. 2850 [Edit]
Interview with the former director of the project.
https://9to5google.com/2022/08/30/fuchsia-director-interview-chris-mckillop/
>> No. 3043 [Edit]
File 166972792911.jpg - (88.30KB , 354x548 , 84ef3e117a43eec05ee458ee9d800b4a.jpg )
3043
New(ish) release.
https://fuchsia.dev/whats-new/release-notes/f8
>> No. 3107 [Edit]
File 167372322735.gif - (506.82KB , 1024x768 , 27dd0bff526ebde738fd85d2ecc194bf.gif )
3107
Version 9
https://fuchsia.dev/whats-new/release-notes/f9
>> No. 3187 [Edit]
File 168161590663.jpg - (186.14KB , 1400x1500 , 993223b3d889824b096b4b3c10fa72df.jpg )
3187
Version 10
https://fuchsia.dev/whats-new/release-notes/f10
>> No. 3265 [Edit]
File 169292653057.png - (158.36KB , 1650x1650 , 9f4784ca7072a5177bb2e8370700da79.png )
3265
Version 12
https://fuchsia.dev/whats-new/release-notes/f12
>> No. 3285 [Edit]
File 169939714644.jpg - (341.55KB , 837x480 , ad483526ecf8b0e38531314fceb4e4bf.jpg )
3285
Version 14
https://fuchsia.dev/whats-new/release-notes/f14

A lot of work has been done on Starnix, the Linux comparability layer. Some risc-v stuff too.
>> No. 3321 [Edit]
File 170577541152.jpg - (920.93KB , 1254x1771 , 09dad5354d5db1357af605b882c9f5d5.jpg )
3321
https://9to5google.com/2024/01/15/google-is-no-longer-bringing-the-full-chrome-browser-to-fuchsia/

Yeah, people were right to doubt the longevity of this project. How sad. Looks like everybody is still going to be stuck with the same 3, shitty options. Windows with its updates and privacy concerns and ui fuckery, MacOs with its vendor lock-in, over-priced hardware and walled-garden, and Linux which is just shit.
>> No. 3365 [Edit]
In spite of the bad news, I'm still checking up on this. Version 16 has been released.
https://fuchsia.dev/whats-new/release-notes/f16

A bunch of additions and improvements to starnix
>Added support for /dev/uinput and route it appropriately to the Fuchsia input subsystem.
>Enabled RISC-V support in Starnix with basic tests running (Starnix with vDSO tests).
>Initial implementation of SELinux server in Starnix.
Also some connectivity improvements.
[Return] [Entire Thread] [Last 50 posts]

View catalog

Delete post []
Password  
Report post
Reason  


[Home] [Manage]



[ Rules ] [ an / foe / ma / mp3 / vg / vn ] [ cr / fig / navi ] [ mai / ot / so / tat ] [ arc / ddl / irc / lol / ns / pic ] [ home ]