HNHacker News
TopNewBestAskShowJobs

ttgo

9 karma · joined June 28, 2020

submissionscomments
ttgo··on Linux Mint drops Ubuntu Snap packages
Flatpak is not a walled garden. Flathub totally messed up the decentralised aspect of flatpak but in theory flatpak can be totally decentralised and you would add software source like you add .debs PPA

Flatpak doesn't impose closed-source, we have distros which only use open source flatpak repos.

Models like Flatpak have the advantage of "download from website & install" i.e you get the apps directly from the producer (which is better for security) while having no walled garden app store but having the advantage of auto updates & permission systems

I do not like Flatpak for technical reasons but Flatpak itself is in no way a walled garden solution, the problem is Flathub.

> I don't care one bit about Linux being a mainstream desktop distro

If you still want to be able to run Linux at all (not even on new hardware) on a consumer hardware, then you should care.

- Linux doesn't run (decently) on Microsoft latest surfaces - Linux won't run on new Apple hardware - Linux doesn't run on Android phones (with a few exceptions) - once Google switch to Fushia no more Linux kernel on mobile hardware - on the long term Huawei will ditch Android and other OS for their own thing.

Linux will die on consumer hardware (except on servers) if it does not become more popular. According to Apple's keynote the future of Linux is in its cage, in a VM running on walled garden MacOS. According to Microsoft the future of Linux is WSL, running on top Windows.

If you do not like walled garden then you should definitively care about Linux getting more mainstream before no comsumer hardwares support it anymore

ttgo··on Linux Mint drops Ubuntu Snap packages
flatkill.org is clickbait, not written in good faith, and doesn't propose any solution. Moreover things like "it's obvious Red Hat developers working on flatpak do not care about security" is just unnecessary and toxic.

Issues mentioned on flatkill are already fixed, will be fixed or doesn't depend on flatpak itself (like the UI / icon in the software app store).

I don't like Flatpak either but I think we should elevate the debate to deeper architectural issues of flatpak that won't be fixed easily. Personally, I do not like the following in Flatpak :

- no effort on full reproducibility like Nix&Guix

- a big fat flat runtime rather than traditional fine grained dependencies (although OStree avoids duplication, but still very elegant)

- you can't install extra pkg in the sandbox. So the quite overkill solution in RedHat's vision is to separate between Toolbox/Podman for devs vs Flatpak for users, rather than trying to make a single unified sandbox for everything. Of course everything breaks down when you try to code using a Flatpaked IDE, if you follow RedHat's vision you basically need to spawn a toolbox container from an unsandboxed flatpak instance of your IDE : https://github.com/flathub/com.visualstudio.code/issues/44

So personally, I'm still waiting for a packaging system that is :

- compatible with the idea of a declarative/immutable os (like nix, guix, silverblue)

- tries to make everything reproducible (like guix)

- sandboxed with runtime permission API (like Flatpak portals, IOS, Android)

- sandbox can be augmented with packages so that you can code in your sandboxed IDE + add necessary dev packages inside a same sandbox without having to break it

ttgo··on Godot 4.0 gets SDF based real-time global illumination
As I mentioned, the lack of damage tracking is an important problem. It leads to high CPU/Battery usage which isn't great for laptop & phones.

Electron/Web might eat lots of ram but I think the renderer is more optimised for UI and will use less CPU/Battery.

Also Godot has an internal architecture made for games which might be a bit overkill/less elegant for UI-only apps :

https://godotengine.org/article/why-does-godot-use-servers-a...

I'm not sure if the separation of logic and rendering in separate threads like that is the way you would build a high perf UI library

ttgo··on Godot 4.0 gets SDF based real-time global illumination
We often hear saying game engines redraw every frame so it is not appropriate for UIs.

In Godot, you can set an option to redraw only when something change like in UI libs (for e.g Godot Editor use this option)

However , I think one main aspect missing from UI libs is damage tracking (=redraw only the part of the screen that changed and tell the compositor to also only redraw that part).

In terms of architecture, Godot is all I want. I wish I could build general purpose apps with it. Everything is a node & just simple trees. Abstraction of everything you need over all platforms. GDNative let you access everything from any language.

I really wish I could build everything with Godot. I enjoy it so much more than web dev or android dev even for UI