HN user

alexlarsson

657 karma
Posts15
Comments119
View on HN

The generator doesn't do that atm no. Seems like it would be useful though.

On the other hand, I belive systemd would load override files for the generated .service file, although those can just override details on the systemd level, not the generated podman command.

It is expensive, but also it is a competitive advantage (of sorts), as we can see with electron. At the end of the day its just a strategic decision Mozilla made to focus on the application itself.

As the original author of GtkMozEmbed I'd like to say that this is way too little, way to late. Mozilla has historically been very much against anyone trying to use the engine in anything other than the firefox app.

This is completely up to them of course, and it probably let them move firefox forward faster, due to not having to care about APIs. However, it also means that chrome completely took over the entire market with electron and similar things.

Yes, but it can't assume any random function call it does doesn't use a different pointer to the same object which is not const. So, even if you don't cast const to non-const pointers you can run into the const value changing.

There isn't a history of issues with people wanting to update to a newer bash causing issues though.

Generally sticking with whatever bash your distro comes with is fine, whereas the services you deploy often depend on a particular version of python.

Fedora 30 7 years ago

Latest rpm-ostree can layer to /opt if that was the problem.

It is possible to do it. And it probably happens naturally for a handrolled toolkit. However when the (one) developer of the GUI is different than the (many) app developers using it things typically end up different.

For instance you end up with things like ui designer tools that produce manifest files, where you just expect that some non-programmer can edit it and load it into your app without having to rebuild the toolkit.

As an uneducated estimate (from someone who has written compilers and GUIs entirely from scratch) I'd say 100K of additional statically linked object should be enough for almost any desktop application.

This is completely misguided. For a modern UI library it is very very hard to figure out what code is actually used.

Say we load the ui description from an xml file. What controls get used in the app then? Maybe the xml has a webview control in it? Then we can't drop the webview dependency.

Then your app needs to load an icon, which typically goes via some generic image loading API. What types of loaders are there? Can we get rid of the gif loader (and dependencies)? If any single image file reference is not hardcoded in the binary, again we can't.

Want to script your application in lua/python/js, and let it call into the UI library? Then we have to assume that basically any code can be reached.

Static linking like this just is not realistic.

I don't think that is quite true. Yes, for normal intergers 17 and 4, you can say the above. But mod can also be used as an operation on (and into) the equivalence classes of Z mod 4.