3 ms·

> last I looked Chromecast was still a thing, so the OS distrib is still there and shipping on devices Chromecast for TV now runs android, CastOS use cases are

> last I looked Chromecast was still a thing, so the OS distrib is still there and shipping on devices Chromecast for TV now runs android, CastOS use cases are mostly moved to android or fuchsia now. > There were no feature advantages to the Fuchsia transition I agree, yet I'm glad they did this just for the interestingness of technology. (Theoretically, the Rust based OS may have better security/protection against memory/buffer issues, but thats surely overshadowed by the bug risk of a new OS) > It would actually be very easy to kill it My understanding from my time there is that CastOS isn't in a shipping-new-features state anymore. > If Fuchsia was gone, Android would take over. This is why the announced Pixel Tablet is also a hub device.

stuaxo 4y ago
It should be slightly less janky than Android with all the Java in it. There are still a lot of midrange phones out there, and IOS has always felt smoother.
- ignoramous 4y ago
  > It should be slightly less janky than Android with all the Java in it. GP comment mentions that userspace apps on Fuschia are predominantly Flutter apps, which isn't only running Dart (in a VM), but also using Skia for 2D (and 3D?) graphics, and that isn't going to go faster than native. With Fuschia, I believe the primary objective has always been a secure kernel base to build the rest of the OS upon. Even ignoring its vast codebase (think: openvpn/ipsec v wireguard), that is pretty hard to do with Linux without performance costs or support from underlying architectures (ex: https://github.com/google/kernel-sanitizers https://github.com/google/kernel-sanitizers). The Android Runtime otoh has long moved to AOT for hot-paths (profile-guided optimization) and JIT for the cold ones.
  - pjmlp 4y ago
    Dart is also AOT/JIT compiled since version 2 was introduced.
- pjmlp 4y ago
  Java is AOT compiled since Android 5, switched into AOT/JIT with PGO feedback loop since Android 7, and as of Android 8 PGO data gets shared across devices via the Play Store. The biggest difference is that while some Android devices might be a sluggish if too many applications are taking liberties with memory, on iOS they just die, specially on Objective-C code, where not everyone checks all pointer related code.
ghaff 4y ago
I'm a bit surprised Chromecast is still kicking. It used to be a pretty unheralded innovation which I found to be really useful. But, honestly, these days I usually have multiple other options to get most content up on a TV screen.
cmrdporcupine 4y ago
Yeah I have the Android TV based Chromecast device here at home. It's janky and laggy in the UI :-) My coworkers did hero-work getting chromium to render beautifully at decent frame rates with very little lag on a very cheap and underpowered SoC for the original Home Hub UI (which was HTML-based). Then most of it got tossed so the UI could be rewritten in Dart/Flutter.
- yafbum 4y ago
  > Then most of it got tossed Surely someone "took responsibility" for that one
- vetinari 4y ago
  Pardon my ignorance, but what UI in Chromecast? From what I remember, there are just pretty pictures with clock when you don't play anything and your chosen stream, when you do. But if you mean UI of Android TV itself, then it seems to be a choice of a suitable SoC, or rather not picking an underpowered one. For example, Nvidia picked well for their Shield line.
  - cmrdporcupine 4y ago
    The topic in the thread here is the Google/Nest Home Hub / Home Hub Max display assistants. They initially ran a version of the same "CastOS" (we didn't call it that then) the same as what ran on Chromecast sticks. But the landing screen on it is richer than what boots on a Chromecast, and it had an interactive gesture based touch screen. CastOS is just a Linux distrib with some boot and build stuff stolen from Android, but the user space for it is basically booting straight into a chromium based web shell. Before it (the display assistant) launched, I wrote (and ported from ChromeOS) some of the gesture stuff on it. And some of the accessibility features (magnification). The "Dragonglass" UI that ran on it was originally built as a HTML/TypeScript stack application. Later it was rewritten in Flutter/Dart, ran for a while like that on CastOS using a Wayland-based wedge layer; and now it runs on Fuchsia. (I don't think any of this is particularly internal or secret anymore since it's old news and replaced, and most of it was visible from the public chromium repo. Also they can't fire me anymore because I quit ;-) )

stuaxo 4y ago

It should be slightly less janky than Android with all the Java in it. There are still a lot of midrange phones out there, and IOS has always felt smoother.

ignoramous 4y ago
> It should be slightly less janky than Android with all the Java in it. GP comment mentions that userspace apps on Fuschia are predominantly Flutter apps, which isn't only running Dart (in a VM), but also using Skia for 2D (and 3D?) graphics, and that isn't going to go faster than native. With Fuschia, I believe the primary objective has always been a secure kernel base to build the rest of the OS upon. Even ignoring its vast codebase (think: openvpn/ipsec v wireguard), that is pretty hard to do with Linux without performance costs or support from underlying architectures (ex: https://github.com/google/kernel-sanitizers https://github.com/google/kernel-sanitizers). The Android Runtime otoh has long moved to AOT for hot-paths (profile-guided optimization) and JIT for the cold ones.
- pjmlp 4y ago
  Dart is also AOT/JIT compiled since version 2 was introduced.
pjmlp 4y ago
Java is AOT compiled since Android 5, switched into AOT/JIT with PGO feedback loop since Android 7, and as of Android 8 PGO data gets shared across devices via the Play Store. The biggest difference is that while some Android devices might be a sluggish if too many applications are taking liberties with memory, on iOS they just die, specially on Objective-C code, where not everyone checks all pointer related code.

ghaff 4y ago

I'm a bit surprised Chromecast is still kicking. It used to be a pretty unheralded innovation which I found to be really useful. But, honestly, these days I usually have multiple other options to get most content up on a TV screen.

cmrdporcupine 4y ago

Yeah I have the Android TV based Chromecast device here at home. It's janky and laggy in the UI :-) My coworkers did hero-work getting chromium to render beautifully at decent frame rates with very little lag on a very cheap and underpowered SoC for the original Home Hub UI (which was HTML-based). Then most of it got tossed so the UI could be rewritten in Dart/Flutter.

yafbum 4y ago
> Then most of it got tossed Surely someone "took responsibility" for that one
vetinari 4y ago
Pardon my ignorance, but what UI in Chromecast? From what I remember, there are just pretty pictures with clock when you don't play anything and your chosen stream, when you do. But if you mean UI of Android TV itself, then it seems to be a choice of a suitable SoC, or rather not picking an underpowered one. For example, Nvidia picked well for their Shield line.
- cmrdporcupine 4y ago
  The topic in the thread here is the Google/Nest Home Hub / Home Hub Max display assistants. They initially ran a version of the same "CastOS" (we didn't call it that then) the same as what ran on Chromecast sticks. But the landing screen on it is richer than what boots on a Chromecast, and it had an interactive gesture based touch screen. CastOS is just a Linux distrib with some boot and build stuff stolen from Android, but the user space for it is basically booting straight into a chromium based web shell. Before it (the display assistant) launched, I wrote (and ported from ChromeOS) some of the gesture stuff on it. And some of the accessibility features (magnification). The "Dragonglass" UI that ran on it was originally built as a HTML/TypeScript stack application. Later it was rewritten in Flutter/Dart, ran for a while like that on CastOS using a Wayland-based wedge layer; and now it runs on Fuchsia. (I don't think any of this is particularly internal or secret anymore since it's old news and replaced, and most of it was visible from the public chromium repo. Also they can't fire me anymore because I quit ;-) )