Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fuchsia overview

fuchsia.dev

Post reply on HN
Print view View original

181–190 of 235 posts

Re: Fuchsia overview

#181

Post by Leherenn »

netdur wrote: post #57
catern wrote: post #35

>Fuchsia aims to provide drivers with a binary-stable interface. In the future, drivers compiled for one version of Fuchsia will continue to work in future versions of Fuchsia without needing to be modified or even recompiled. This approach means that Fuchsia devices will be able to update to newer versions of Fuchsia seamlessly while keeping their existing drivers. This is a massive step back for open source. The fa…

sorry but that's just naive idealism, my wife has android flagship, a Samsung s10, she will receive one more year of updates, then she will be on her own, my daughter has iPhone 6S, this old device will receive iOS 14 soon. my wife do not care about updates, she will not hesitate a second to get iPhone once she knows her social media or pictures is not safe on her android device, this is the issue Android have and Fu…

Note that it will only get one more major Android version, but Samsung provides 4 years of security updates, so she still has 3 more years before she's on her own.

Certainly not as good as Apple, but I believe that's the best you can find in Android land.

Re: Fuchsia overview

#182

Post by rwmj »

catern wrote: post #35

>Fuchsia aims to provide drivers with a binary-stable interface. In the future, drivers compiled for one version of Fuchsia will continue to work in future versions of Fuchsia without needing to be modified or even recompiled. This approach means that Fuchsia devices will be able to update to newer versions of Fuchsia seamlessly while keeping their existing drivers. This is a massive step back for open source. The fa…

I guess that Linux will quickly get an "NDISwrapper" equivalent that can run Fuchsia binary blobs. We'll all be a little bit worse off as a result, but with mostly working peripherals.

Re: Fuchsia overview

#183

Post by BiteCode_dev »

catern wrote: post #35

>Fuchsia aims to provide drivers with a binary-stable interface. In the future, drivers compiled for one version of Fuchsia will continue to work in future versions of Fuchsia without needing to be modified or even recompiled. This approach means that Fuchsia devices will be able to update to newer versions of Fuchsia seamlessly while keeping their existing drivers. This is a massive step back for open source. The fa…

I'm a strong FOSS proponent, most of my software is released under MIT, I use Linux daily and help others to use open source as much as I can.

And yet I find this idea total BS.

The reason I could even migrate to Linux when I was a teen was compatibility. It's because free softwares (VLC, Firefox, OOo...) were ported to Windows, a proprietary plateform, so that I could then feel at home later on Linux. And I made a definitive switch thanks to Ubuntu, because it made using most hardware easy, by accepting to use proprietary drivers when required.

Strong arming the industry into Libre never worked. The GPL is one of the least popular licences for this very reason. I, myself, never uses it.

Representing close source as evil doesn't work either.

It's like being vegetarian (which I am) and guilt triping people about meat. It's completly counter productive.

The result we got is that the year of Linux on the desktop never happened, because playing on Linux is hard, because the last cool gadget doesn't work, because you have to carefully chose your laptop to be sure it will work with it (E.G: my XPS 2-in-1 webcam doesn't work on Linux).

It also adds a lot of work to the kernel devs to try to keep up with the outter world, but they have a limited bandwith.

So Linux BT still sucks (even more than regular BT). Wifi is still not on part with the XP on other OS. Batter life is abysmal (I'm dual booting, and the difference is X2).

All for an ideal we never reached anyway.

Help and encouraging for FOSS makes a better world.

Being pushy about it hurts us.

Re: Fuchsia overview

#184

Post by AsyncAwait »

pjmlp wrote: post #180
AsyncAwait wrote: post #177

Earlier quoted context omitted.

> Every Nvidia and Intel competitor (AMD) is probably already reverse engineering their binary drivers and binary libraries trying to steal their IP, so Intel and Nvidia’s fears are imo justified. If NVIDIA or Intel could easily protect their open source code from being stolen from AMD, the story would be different. Intel's GPU drivers are free software, they even contribute them themselves, same goes for AMD. I thin…

They do so by using different teams, and their open source variants always lag behind what their closed source drivers are capable of doing across Windows, Apple and game consoles.

The drivers are decent enough nonetheless. I think having an open driver done by a different team and maybe a bit less optimized is still preferable to not having an official open driver at all.

Re: Fuchsia overview

#185

Post by pjmlp »

stewbrew wrote: post #165

I still think its strange to create an OS that officially supports only 2-3 languages for development. Sounds rather 1980s to me.

Sounds very much like any Apple, Google, Microsoft, IBM, Oracle, Sony, Nintendo, pick your embedded OEM, ... to me.

UNIX has always been the snowflake, and even there, commercial UNIX SKDs are pretty much C, C++ and Fortran, followed by the usual POSIX scripting languages.

To create a good developer experience in OS SDK IDE and platform APIs, there are only so much one can support.

Unless we are doing UNIX ABIs and the best one can hope for are 70's C style bindings.

Re: Fuchsia overview

#186

Post by terminalcommand »

naasking wrote: post #127
ptomato wrote: post #50

Earlier quoted context omitted.

> For various reasons, but nothing fundamental. "Hardware vendors being unwilling to make the drivers they write open source" is a pretty fundamental reason. Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers? I don't think that realistically there's a third option. The open source community is not, for example, going to…

> Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers? I don't think that realistically there's a third option A phone in which the kernel never needs to be updated, like with the seL4 microkernel.

Most BIOS are also closed source. If I used a microkernel primitive enough not to require changes, I could live with not updating the kernel unless there is a security bug.

A third solution could be to require device manufacturers to share their source code with a trusted third party (such as google/certification authority). This third party will make sure that the driver does not include any harmful code and provide signed binaries. Binaries could also be updated for newer versions that way, even if the original manufacturer loses interest/goes bankrupt. If the IP gets stolen, the device manufacturer could sue this third party, therefore business people will also feel secure.

It is not ideal, but I could be able to live with this solution.

Re: Fuchsia overview

#187

Post by pjmlp »

innagadadavida wrote: post #88
qmarchi wrote: post #68

Earlier quoted context omitted.

Actually quite the opposite, Fuchsia already runs on production devices manufactured by Google. The (ridiculously long named) Google Nest Home Hub and Home Hub Max both can run Zircon and Fuchsia on device, although it's very much for development.

Apart from the unfortunate sounding name, for this to be relevant on android phones or watches, it needs to simply work with the 2+ million apps out there. Just posix compatibility is insufficient - apps rely on Linux implementation behavior.

No one doing apps cares about POSIX on or Linux on Android, unless we are talking about people rooting their devices.

The official stable APIs are the Java/Kotlin frameworks, NDK native libraries, ISO C and ISO C++ standard libraries.

Exactly to cut down on misbehaviours of developers getting hold of unofficial Linux syscalls or non public .so, Google has started to use LinuxSE and seccomp to lock out such kind of apps.

So any Android application that only uses public APIs will have no trouble migrating to Fuchsia.

Re: Fuchsia overview

#188

Post by tempodox »

I was trying to find out from that site who's behind this and if that information is in there it must be really well hidden. Apart from other concerns, I'm not going to touch an OS from a group that doesn't clearly state who they are.

Re: Fuchsia overview

#189

Post by pjmlp »

michaelmrose wrote: post #136
bsder wrote: post #92

Earlier quoted context omitted.

Well, the touchstone is audio. If Fuchsia manages to have audio performance like iOS, then they definitely rearchitected rather than just slapped lipstick on a different pig.

Do people actually have audio problems with android? People don't seem to even have a problem with all the bad quality audio devices they ought to have a problem with let alone the OS.

Musics do have, hence why Samsung had their own real time audio stack, which Google eventually adapted into Android.

There are several years of Google IO stuff going into this, until you finally reach the talk done together with a Samsung representative and a couple of DJs using the new demo app on stage to prove Android was finally ready for music professionals.

It is just a matter to go down the Google IO archive.

Re: Fuchsia overview

#190

Post by terminalcommand »

dahfizz wrote: post #120
cameronbrown wrote: post #80

Earlier quoted context omitted.

I really want to agree with you, and in principle, it would be far better for hardware manufacturers to upstream their drivers. In practice this hasn't happened and will never happen, because there's no incentive to support hardware no longer making money (a chip is only sold once, after all). I think the mounting cost of e-waste is a far bigger deal. Think of the unimaginable amount of carbon impact from the million…

> Updatability can save devices for much longer I'm skeptical of this. People buy new phones because they are faster, or because they did update and the new version of the OS is very slow on old hardware. People buy new hardware because they want new hardware. Most non-tech people I know actively avoid updating their phones because it's annoying. They will ignore the notifications and choose older software over the i…

Hardware has its limits of course, but sometimes if you can’t upgrade your OS, you can’t install apps. You’ll be stuck with a screen saying “This application requires IOS X and higher”. When that frequently happens, you are forced to upgrade your phone, even if you’re content with the hardware.

Avoiding updates and ignoring notifications could stem from a different reasons. People may not want to take the time and maintain their phones. I consider myself a techy person, but I also put off updating my phone, taking good care of it, upgrading it. I also dread tidying up my room, getting a hair cut, shopping for clothes, eating healthy, sleeping well etc. It could be a personality trait.

Avoidance conserves energy :)

Post reply on HN