5 ms·

>Porting a mainstream browser to Plan 9 is about 50 times more labor than has ever been put into Plan 9 People put a lot of effort in to Plan 9 (and 9front spe

>Porting a mainstream browser to Plan 9 is about 50 times more labor than has ever been put into Plan 9 People put a lot of effort in to Plan 9 (and 9front specifically these days), so I want to point out that this is mostly the fault of these "mainstream" browsers being so complicated. It is actually easier for us to emulate an entire virtual machine and run a linux + chrome setup within it then it would be for us to port all the code over. I also find it no surprise that Fuchsia is getting some chrome dev time, but I have a hard time of believing that it's due to popularity. Google has little interest in maintaining chrome for other more used systems like the BSD's. Seems like they are only interested as a byproduct of wanting to sell appliances running Fuchsia.

hollerith 3y ago
These "mainstream" browsers being so complicated is a large part of why I don't like them, but the reality is that no matter how much I don't like it, the web is unavoidable with the result that if I were to run Plan 9, I would need to run a second OS with which to browse the web (and I like to save snippets of the web, so I either need to keep those snippets on the second OS or rig something up to make it easy to send the snippets to my Plan 9 install). (And I regularly need to upload documents and images stored on my computer to the web, so I'd either need to keep my documents and images on the second OS or rig something up to avoid the tedium of manually copying the document or image every time from Plan 9 to the second OS so I could upload it.) I.e., not having any mainstream browser is a big deal for an OS, so when someone asked for a comparison between Plan 9 and Fuchsia, I thought I'd mention it. More precisely, it is a big deal for a user-facing OS, and Plan 9 is mostly user-facing. In fact, I've never heard of anyone using it as, e.g., a web server.
- moody__ 3y ago
  Indeed, thankfully using a 9front system from another OS is quite nice. My workstation at home is a Linux machine with a drawterm window open fullscreen. You can think of drawterm like our version of windows RDP, with a shared clipboard and a way of sharing files seamlessly between the host and the remote system. Under the hood, drawterm is just an implementation of /dev/draw that gets given to a remote system, so you're not forwarding compressed images but individual draw RPC messages. Over a LAN connection you can even play doom at 1080p.
  - hollerith 3y ago
    What's the security story like for 9front? For years, Android, iOS, Windows, MacOS and ChromeOS has used a verified boot process that prevents any malware from surviving a reboot in any of the system software, i.e., anywhere except for the user's home directory and maybe other directories created by the user that the user is responsible for maintaining. I don't suppose 9front has that? Also when I used drawterm (as part of Plan 9 from Userspace on a Mac) the drawterm windows had no anti-aliasing, which I might have been able to get used to, except that the native-Mac windows used anti-aliasing and switching back and forth I found a jarring experience (and I was never able to figure out how to configure the Mac (and my browser) not to do the anti-aliasing). (Technically, my browser was doing its own low-level drawing, but it had been carefully tuned by the maintainers of the browser to visually resemble the results of the native Mac drawing systems.)
    - deleted 3y ago
      [deleted]
    - eschneider 3y ago
      As for secure boot, assuming plan9 can boot from a read-only volume, that shouldn't be hard to implement. The (simplified) way it works on most systems is that secure boot is implement in the SOC and that's used to verify the installed bootloader and then the verified bootloader verifies that the boot volume is unmodified (think checksum, but a bit more complicated to make it boot faster. :) There isn't anything about that that couldn't be incorporated into almost any boot process.
      - hollerith 3y ago
        If it isn't hard to implement why does no Linux distro besides bottlerocket (specialized for use on AWS and other cloud services) Android and ChromeOS do it?
        stonogo 3y ago
        Debian, Ubuntu, Red Hat, Fedora, Suse, Arch, Gentoo, and Slackware all support secureboot. After that I got tired of looking up linux distributions, so there are likely more.
cmrdporcupine 3y ago
When I worked at Google the efforts to port Chromium over were seemingly tied in large part to needing to have parts of it to get the Chromecast ecosystem running on it. Because the devices they were targeting for Fuchsia to use were built on top of that. (though a lot of that UI also got rewritten in Dart/Flutter instead, so) I wasn't directly involved but was a tiny bit of a voyeur. I seem to recall (this was 3-4-5 years ago) that there was a lot of push to try to componentize things in a more Fuchsia-ish way, but this naturally ran up against the realities of how huge and big the Chrome codebase is. And Chrome has its own IPC system (mojo) and its own component model(s), its own threading system, etc. and assumes POSIX stuff throughout, etc. My suspicion at the time was that as something like Chromium gets ported to Fuchsia the result will be less that Chrome becomes friendly to Fuchsia, as much as that Fuchsia becomes less distinct, and more a "typical" OS, out of pragmatism. I dunno, I'm curious to see how that effort is going. But I think it accords with your point. Porting big applications to "alternative" operating systems with more interesting or exotic models... you either end up losing the OS's distinctiveness (in which case why not just run in a VM), or having to rewrite a lot from scratch.
- moody__ 3y ago
  >Porting big applications to "alternative" operating systems with more interesting or exotic models... you either end up losing the OS's distinctiveness (in which case why not just run in a VM), or having to rewrite a lot from scratch. Very well said.
- IshKebab 3y ago
  I guess the advantage is that other apps can still take advantage of the OS's unique features. As I understand it Fuchsia has a POSIX compatibility layer which maybe they'll have to use for Chrome, but they wouldn't need to use it for new apps.

hollerith 3y ago

These "mainstream" browsers being so complicated is a large part of why I don't like them, but the reality is that no matter how much I don't like it, the web is unavoidable with the result that if I were to run Plan 9, I would need to run a second OS with which to browse the web (and I like to save snippets of the web, so I either need to keep those snippets on the second OS or rig something up to make it easy to send the snippets to my Plan 9 install). (And I regularly need to upload documents and images stored on my computer to the web, so I'd either need to keep my documents and images on the second OS or rig something up to avoid the tedium of manually copying the document or image every time from Plan 9 to the second OS so I could upload it.) I.e., not having any mainstream browser is a big deal for an OS, so when someone asked for a comparison between Plan 9 and Fuchsia, I thought I'd mention it. More precisely, it is a big deal for a user-facing OS, and Plan 9 is mostly user-facing. In fact, I've never heard of anyone using it as, e.g., a web server.

moody__ 3y ago
Indeed, thankfully using a 9front system from another OS is quite nice. My workstation at home is a Linux machine with a drawterm window open fullscreen. You can think of drawterm like our version of windows RDP, with a shared clipboard and a way of sharing files seamlessly between the host and the remote system. Under the hood, drawterm is just an implementation of /dev/draw that gets given to a remote system, so you're not forwarding compressed images but individual draw RPC messages. Over a LAN connection you can even play doom at 1080p.
- hollerith 3y ago
  What's the security story like for 9front? For years, Android, iOS, Windows, MacOS and ChromeOS has used a verified boot process that prevents any malware from surviving a reboot in any of the system software, i.e., anywhere except for the user's home directory and maybe other directories created by the user that the user is responsible for maintaining. I don't suppose 9front has that? Also when I used drawterm (as part of Plan 9 from Userspace on a Mac) the drawterm windows had no anti-aliasing, which I might have been able to get used to, except that the native-Mac windows used anti-aliasing and switching back and forth I found a jarring experience (and I was never able to figure out how to configure the Mac (and my browser) not to do the anti-aliasing). (Technically, my browser was doing its own low-level drawing, but it had been carefully tuned by the maintainers of the browser to visually resemble the results of the native Mac drawing systems.)
  - deleted 3y ago
    [deleted]
  - eschneider 3y ago
    As for secure boot, assuming plan9 can boot from a read-only volume, that shouldn't be hard to implement. The (simplified) way it works on most systems is that secure boot is implement in the SOC and that's used to verify the installed bootloader and then the verified bootloader verifies that the boot volume is unmodified (think checksum, but a bit more complicated to make it boot faster. :) There isn't anything about that that couldn't be incorporated into almost any boot process.
    - hollerith 3y ago
      If it isn't hard to implement why does no Linux distro besides bottlerocket (specialized for use on AWS and other cloud services) Android and ChromeOS do it?
      - stonogo 3y ago
        Debian, Ubuntu, Red Hat, Fedora, Suse, Arch, Gentoo, and Slackware all support secureboot. After that I got tired of looking up linux distributions, so there are likely more.

cmrdporcupine 3y ago

When I worked at Google the efforts to port Chromium over were seemingly tied in large part to needing to have parts of it to get the Chromecast ecosystem running on it. Because the devices they were targeting for Fuchsia to use were built on top of that. (though a lot of that UI also got rewritten in Dart/Flutter instead, so) I wasn't directly involved but was a tiny bit of a voyeur. I seem to recall (this was 3-4-5 years ago) that there was a lot of push to try to componentize things in a more Fuchsia-ish way, but this naturally ran up against the realities of how huge and big the Chrome codebase is. And Chrome has its own IPC system (mojo) and its own component model(s), its own threading system, etc. and assumes POSIX stuff throughout, etc. My suspicion at the time was that as something like Chromium gets ported to Fuchsia the result will be less that Chrome becomes friendly to Fuchsia, as much as that Fuchsia becomes less distinct, and more a "typical" OS, out of pragmatism. I dunno, I'm curious to see how that effort is going. But I think it accords with your point. Porting big applications to "alternative" operating systems with more interesting or exotic models... you either end up losing the OS's distinctiveness (in which case why not just run in a VM), or having to rewrite a lot from scratch.

moody__ 3y ago
>Porting big applications to "alternative" operating systems with more interesting or exotic models... you either end up losing the OS's distinctiveness (in which case why not just run in a VM), or having to rewrite a lot from scratch. Very well said.
IshKebab 3y ago
I guess the advantage is that other apps can still take advantage of the OS's unique features. As I understand it Fuchsia has a POSIX compatibility layer which maybe they'll have to use for Chrome, but they wouldn't need to use it for new apps.