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

Google’s Fuchsia OS on the Pixelbook

arstechnica.com

Post reply on HN
Print view View original

101–110 of 126 posts

Re: Google’s Fuchsia OS on the Pixelbook

#101

Post by solarkraft »

happyguy43 wrote: post #57
SllX wrote: post #44

Earlier quoted context omitted.

Depending on the future direction they take this, it might end up replacing OpenBSD for me. Mac OS X and OpenBSD are my daily drivers, but at their core, they are BSDs, and less and less I find myself using the NeXTSTEP portion of Mac OS X and more and more time in BSD-land, which is leading me to move more and more of my overall computer time to OpenBSD which is a great operating system but is still largely a contin…

Don’t hold your breath. The zircon API isn’t innovative in any modern sense. Additionally it’s bloated and not clean like L4. It’s just in house IP for Google. (HN won’t let me directly reply to the comment below so here it is: Nothing in zircon doesn’t already exist on Linux or any other modern kernel. Additionally it has bloat, like 3 distinct IPC mechanisms. Even further, if it ends up being any technical person’s…

This is interesting: I thought they had taken a lot of care to implement very clean concepts.

Re: Google’s Fuchsia OS on the Pixelbook

#102

Post by willtim »

fooker wrote: post #97
willtim wrote: post #92

Earlier quoted context omitted.

Assuming your analogy has merit, I doubt very much this is true. Computer modelling, for example, has improved significantly over the years. However, it is true that many high profile failures in aerospace have been due to software errors, so I would say that software tooling is certainly one area that they could also benefit from.

In line with your reasoning, software development methodology has significantly improved over the years. One does not write C++ in 2018 as they would have written C in 1980.

Best practice has changed, but C++ does not enforce it. Did Samsung follow best practices with Tizen?

Languages like Rust and Haskell are an attempt to put such best practice into the language tooling.

Re: Google’s Fuchsia OS on the Pixelbook

#103

Post by fooker »

willtim wrote: post #102
fooker wrote: post #97

Earlier quoted context omitted.

In line with your reasoning, software development methodology has significantly improved over the years. One does not write C++ in 2018 as they would have written C in 1980.

Best practice has changed, but C++ does not enforce it. Did Samsung follow best practices with Tizen? Languages like Rust and Haskell are an attempt to put such best practice into the language tooling.

>Languages like Rust and Haskell are an attempt to put such best practice into the language tooling.

Best practice often varies between projects and changes rather often, ..say.. in a matter of a few years. Most of what Haskell and Rust offer are a library away (yes, even compile time checks) for C++, but not vice versa. There is a reason new languages with baked in 'opinion' come and go.

Re: Google’s Fuchsia OS on the Pixelbook

#104

Post by willtim »

fooker wrote: post #103
willtim wrote: post #102

Earlier quoted context omitted.

Best practice has changed, but C++ does not enforce it. Did Samsung follow best practices with Tizen? Languages like Rust and Haskell are an attempt to put such best practice into the language tooling.

>Languages like Rust and Haskell are an attempt to put such best practice into the language tooling. Best practice often varies between projects and changes rather often, ..say.. in a matter of a few years. Most of what Haskell and Rust offer are a library away (yes, even compile time checks) for C++, but not vice versa. There is a reason new languages with baked in 'opinion' come and go.

You cannot make C++ secure and safe with a library.

Re: Google’s Fuchsia OS on the Pixelbook

#105

Post by kuschku »

ZiiS wrote: post #90
kuschku wrote: post #85

Earlier quoted context omitted.

And by now not even the caller app, or the phonebook app, or the calendar, or Homescreen, or settings, or search are open anymore.[1] Everything now requires Google's proprietary services Oh, and Google prevents OEMs from cooperating with Amazon.[2] As result, Android is almost completely controlled by Google. And you call that "open"? ________________________ [1] To disprove this, please find me the full current sou…

You can still go fully open; https://microg.org/ and https://f-droid.org/en/ I don't have Pay, and no cloud push notifications, and the GPS assist isn't quite as perfect, but the only real bugbare is no swyping keyboard.

Sure, but that's not the same. By that argument — the core of the OS is open, just everything on top isn't — you might as well call macOS open because Darwin is open.

Android is nowadays proprietary, sadly.

Re: Google’s Fuchsia OS on the Pixelbook

#106

Post by fooker »

willtim wrote: post #104
fooker wrote: post #103

Earlier quoted context omitted.

>Languages like Rust and Haskell are an attempt to put such best practice into the language tooling. Best practice often varies between projects and changes rather often, ..say.. in a matter of a few years. Most of what Haskell and Rust offer are a library away (yes, even compile time checks) for C++, but not vice versa. There is a reason new languages with baked in 'opinion' come and go.

You cannot make C++ secure and safe with a library.

If you state your criteria for 'safe' and 'secure', I can point you towards library implementations for each of your points.

You can not stop the users from shooting themselves in the foot, but that is not the goal here. We want to enable 'safe and secure' programming, not develop toy idiot-proof write-only languages that are useless for large projects.

Re: Google’s Fuchsia OS on the Pixelbook

#107

Post by willtim »

fooker wrote: post #106
willtim wrote: post #104

Earlier quoted context omitted.

You cannot make C++ secure and safe with a library.

If you state your criteria for 'safe' and 'secure', I can point you towards library implementations for each of your points. You can not stop the users from shooting themselves in the foot, but that is not the goal here. We want to enable 'safe and secure' programming, not develop toy idiot-proof write-only languages that are useless for large projects.

> You can not stop the users from shooting themselves in the foot, but that is not the goal here.

It should be the goal. Even experts make mistakes. This is why static type systems exist. The logical thing to do is to strengthen the type system to prevent more classes of errors.

Re: Google’s Fuchsia OS on the Pixelbook

#108

Post by fooker »

willtim wrote: post #107
fooker wrote: post #106

Earlier quoted context omitted.

If you state your criteria for 'safe' and 'secure', I can point you towards library implementations for each of your points. You can not stop the users from shooting themselves in the foot, but that is not the goal here. We want to enable 'safe and secure' programming, not develop toy idiot-proof write-only languages that are useless for large projects.

> You can not stop the users from shooting themselves in the foot, but that is not the goal here. It should be the goal. Even experts make mistakes. This is why static type systems exist. The logical thing to do is to strengthen the type system to prevent more classes of errors.

And yet you always need to provide users an way out for the sake of pragmatism. Examples: Rust's unsafe block, Haskell's Unsafe.Coerce, etc.

If the user avoids the analogous features in C++ and stick to modern conventions, it is not less safe/secure.

Re: Google’s Fuchsia OS on the Pixelbook

#109

Post by willtim »

solarkraft wrote: post #96
willtim wrote: post #87

Earlier quoted context omitted.

It's all written in C++, so from a security and reliability perspective, I'm sketical it's going to offer much improvement over Linux. I don't see any evidence yet of "new technology". I'm happy to be proven wrong.

Of course the programming language defines the architecture ...

Programming languages do influence how a problem is solved and this often affects architecture. This is especially true with respect to concurrency. However my main problem with C++ is security, not want architectures it inspires.
Post reply on HN