5 ms·

>Are there any F/LOSS alternatives to Snap that are as widely used and tested? While not released yet I'm thinking WebAssembly and browser APIs should eventual

>Are there any F/LOSS alternatives to Snap that are as widely used and tested? While not released yet I'm thinking WebAssembly and browser APIs should eventually cover this use case - I expect browsers to expose more sandboxed versions of native APIs and the browser will become the new OS for desktop OS. People will probably start experimenting and packaging their own browser builds with extra APIs that don't get released in to web browsers right away - like Electron - instead of running node it would just expose more stuff to the browser JS/WASM.

danieldk 10y ago
While not released yet I'm thinking WebAssembly and browser APIs should eventually cover this use case - I expect browsers to expose more sandboxed versions of native APIs and the browser will become the new OS for desktop OS. Yes, let's throw away all the great toolkits (Qt, Cocoa, etc.) that we have, which have developed into an extremely stable base over the past 20 years, with look & feel consistency between applications, and replace it by some experimental browser tech and constantly reinvented web frameworks. </sarcasm> On a more serious note: I think sandboxing application for existing toolkits is a problem that is far easier to solve than changing browsers into general purpose operating systems with consistent UIs. In fact, Snap, Flatpak, etc. already implement many of the necessary bits and it's been done before on UNIX (Sandboxed macOS applications). Of course, Linux has to switch to Wayland for GUI isolation, but that'll be true for any solution.
- rubber_duck 10y ago
  >Yes, let's throw away all the great toolkits (Qt, Cocoa, etc.) that we have, which have developed into an extremely stable base over the past 20 years, with look & feel consistency between applications, and replace it by some experimental browser tech and constantly reinvented web frameworks. </sarcasm> I don't think you understand how WASM works. Qt can compile and work on GLES 2.0 (WebGL) and WASM is just a sandboxed bytecode that maps closely to CPU instructions and C memory model, meaning you could run Qt apps inside of WASM/Browser sandbox, and given the small size of WASM binaries compared to ASM.JS that's feasible even considering the size of Qt. Browser with WASM is just a sandbox on top of native APIs and some chrome - it's essentially the app model for desktop with low friction distribution - you have back/forward, easy switching/kill, resource sand-boxing, etc. just like you do on your phone.
  - danieldk 10y ago
    I don't think you understand how WASM works. I do. And most of this you could already do for a while without Web Assembly, either native using e.g. NaCl or compiled to Javascript/Asm.js (Emscripten). Running Qt in the browser it not some future, it is already possible. The problem is that if you go that route, you lose a lot of platform integration. Moreover, you throw in another layer for what is practically a solved problem (the Linux kernel has all the necessary bits for sandboxing, which Chrome et al. also use for sandboxing). it's essentially the app model for desktop with low friction distribution As someone who distributes a Qt application on Windows, Linux, OS X. I don't need this. I just need to be able to distribute one app bundle that works on all Linux distributions. OS X and Windows are already a walk in the park. And by having a native app, I have proper integration now (e.g. Full Screen, Dock, and file association support on the Mac). just like you do on your phone. My phone uses native apps, thank you. (Though is it is in the process of switching to LLVM bytecode.)
    - rubber_duck 10y ago
      >Running Qt in the browser it not some future, it is already possible. It's possible, it's just not feasible - NaCl is chrome only and has some limitations around distribution and the tool-chain is very specific (Google provided port of Clang/LLVM), asm.js/emscripten sucks both in parse/compile time and in download size. >Moreover, you throw in another layer for what is practically a solved problem (the Linux kernel has all the necessary bits for sandboxing, which Chrome et al. also use for sandboxing). What you get is a cross platform layer. You can then add in platform specific extensions and code around those as optional features. The only systems that lets you do something similar right now is full blown VMs like JVM/.NET and this is lower level, potentially allowing more languages to target it. Like you said browser will just wrap the native interfaces to provide compatibility - low friction cross platform app development/deployment.
- ashitlerferad 10y ago
  > Of course, Linux has to switch to Wayland for GUI isolation It took Keith Packard a few hours to fix this problem in Xorg.

danieldk 10y ago

While not released yet I'm thinking WebAssembly and browser APIs should eventually cover this use case - I expect browsers to expose more sandboxed versions of native APIs and the browser will become the new OS for desktop OS. Yes, let's throw away all the great toolkits (Qt, Cocoa, etc.) that we have, which have developed into an extremely stable base over the past 20 years, with look & feel consistency between applications, and replace it by some experimental browser tech and constantly reinvented web frameworks. </sarcasm> On a more serious note: I think sandboxing application for existing toolkits is a problem that is far easier to solve than changing browsers into general purpose operating systems with consistent UIs. In fact, Snap, Flatpak, etc. already implement many of the necessary bits and it's been done before on UNIX (Sandboxed macOS applications). Of course, Linux has to switch to Wayland for GUI isolation, but that'll be true for any solution.

rubber_duck 10y ago
>Yes, let's throw away all the great toolkits (Qt, Cocoa, etc.) that we have, which have developed into an extremely stable base over the past 20 years, with look & feel consistency between applications, and replace it by some experimental browser tech and constantly reinvented web frameworks. </sarcasm> I don't think you understand how WASM works. Qt can compile and work on GLES 2.0 (WebGL) and WASM is just a sandboxed bytecode that maps closely to CPU instructions and C memory model, meaning you could run Qt apps inside of WASM/Browser sandbox, and given the small size of WASM binaries compared to ASM.JS that's feasible even considering the size of Qt. Browser with WASM is just a sandbox on top of native APIs and some chrome - it's essentially the app model for desktop with low friction distribution - you have back/forward, easy switching/kill, resource sand-boxing, etc. just like you do on your phone.
- danieldk 10y ago
  I don't think you understand how WASM works. I do. And most of this you could already do for a while without Web Assembly, either native using e.g. NaCl or compiled to Javascript/Asm.js (Emscripten). Running Qt in the browser it not some future, it is already possible. The problem is that if you go that route, you lose a lot of platform integration. Moreover, you throw in another layer for what is practically a solved problem (the Linux kernel has all the necessary bits for sandboxing, which Chrome et al. also use for sandboxing). it's essentially the app model for desktop with low friction distribution As someone who distributes a Qt application on Windows, Linux, OS X. I don't need this. I just need to be able to distribute one app bundle that works on all Linux distributions. OS X and Windows are already a walk in the park. And by having a native app, I have proper integration now (e.g. Full Screen, Dock, and file association support on the Mac). just like you do on your phone. My phone uses native apps, thank you. (Though is it is in the process of switching to LLVM bytecode.)
  - rubber_duck 10y ago
    >Running Qt in the browser it not some future, it is already possible. It's possible, it's just not feasible - NaCl is chrome only and has some limitations around distribution and the tool-chain is very specific (Google provided port of Clang/LLVM), asm.js/emscripten sucks both in parse/compile time and in download size. >Moreover, you throw in another layer for what is practically a solved problem (the Linux kernel has all the necessary bits for sandboxing, which Chrome et al. also use for sandboxing). What you get is a cross platform layer. You can then add in platform specific extensions and code around those as optional features. The only systems that lets you do something similar right now is full blown VMs like JVM/.NET and this is lower level, potentially allowing more languages to target it. Like you said browser will just wrap the native interfaces to provide compatibility - low friction cross platform app development/deployment.
ashitlerferad 10y ago
> Of course, Linux has to switch to Wayland for GUI isolation It took Keith Packard a few hours to fix this problem in Xorg.