Package repos, software centres, and discoverability?

[will-ca]

I recently (just now) discovered Min though the comprehensive Archlinux wiki page on all Internet applications.

The app is great, everything looks extremely slick, most all of my accustomed keyboard shortcuts and menu items pleasantly work right out of the box without cluttering the UI, and performance is stellar on a very limited machine where Chromium and Epiphany will both regularly lag from CPU or freeze from IO for dozens of seconds at a time— but if I hadn't scrolled through that extremely extensive Archlinux wiki list and and clicked on just the right link, I never would have found it.

Putting "min" in an Internet search engine doesn't find this project, for obvious reasons. Searching "min browser" does, but that just helps with finding it when you already know about it, not discovering it in the first place. Multiple lists and articles for "lightweight Linux browser" exist, but very few of them seem to mention this project.

Min seems to be fairly unique out of all the browsers I've been able to find, in a good way. It's much more lightweight, in terms of both performance and UI clutter, than most GUI/widget-oriented browsers like Firefox, Chrome, and even Epiphany, Midori, Falkon, etc. But at the same time, it seems much more modern, stable, and usable than any other ultra-lightweight browser, like Luakit, Suckless, Lynx, Surf, etc. It seems to cut out basically all of the bloat of most GUI-oriented browsers, and it successfully does so without losing features that are actually useful. I think that's a great place to be, and I think a lot of people might agree, but we have to be able to find Min first.

Why not publish to a couple of major LInux distros' package repostiories and software centres? As a user, I like having greater selections and being able to easily find and install useful software from a trusted, auto-updating source. As Linux distributions, they'd benefit too from claiming a greater range of apps offered. As an open-source project, Min would probably benefit from an increased use base and potential developer interest due to the greater discoverability. And as people who write computer programs for living, you might be able to benefit too from potentially monetizing with some of the distribution's payware or pay-what-you-want features?

[PalmerAL]

I'm glad you like Min! Offering the features of a full web browser with a faster and less cluttered UI is one of the main goals of this project, so I'm happy to hear that you think we've succeeded with that.

The name is rather unfortunate, and I wish I had picked something else. That being said, we're somewhere on the second page of the Google results for "Min", and near the bottom of the first page on Bing/Duckduckgo, so maybe it will end up not being an issue anyway.

Centralized software stores really concern me in general, and I'm not entirely sure if it's a system I want to support if I can avoid it. On most operating systems today (iOS, macOS, Windows), there's a trend towards making it difficult or impossible to install software from outside a store, so that the platform owner can control what software you get to run and collect a percentage of whatever revenue your software produces. In general, I think it's important to encourage people to continue getting software directly from whoever's producing it, so that it remains possible to freely distribute software without the industry being controlled by platform owners.

On Linux specifically, this seems to be less of an issue; there isn't as much of a financial motivation to restrict what's available in package mangers, and I would be really surpised if Linux ever lost the ability to install software from outside a software center. As a result, I think it would be fine to do this on Linux. However, I'm somewhat confused as to what stores we should be listed on, and most of the documentation seems to be out of date. This article mentions GNOME software, KDE discover, and a few others, but none of those seem to have their own documentation for how to submit packages. If I'm understanding correctly, Snapcraft is the main source of packages, and is used by the other store frontends; do you know whether that's correct?

Pay-what-you-want is an interesting possibility, I might have to look into that more.

[ludvigng]

GNOME software and KDE discover are both just frontends that can use native packages through PackageKit, flatpaks and snaps. When installing firefox as an example, you can choose in gnome software if you want to install it from the native packages, flatpak or snaps, if you have them enabled.

The drawback of snaps is that you cannot use alternative software repos other than canonicals IIRC. None of the other packaging formats suffer from this. So that probably fits into your concern about centralized software stores.

When it comes to flatpaks, you can add as many repositories as you want. Fedora has one, Elementary OS has one, etc. The most common one used is Flathub, and submitting an application is described here. I might be able to help out by creating a flatpak manifest, though I don't have that much experience and I haven't worked with electron or npm in flatpaks before. :)

(Responding to a three year old comment, but hopefully you found it helpful.)

[ludvigng]

Okay, so it's been around a year and I haven't been able to work on it as much as I wanted. I've created a basic flatpak manifest, but the tricky part is that flatpak doesn't allow npm to download modules during the package build, they have to be declared beforehand.

Here are the files, if anyone wants to continue: minbrowser-flatpak.zip

In short, I think the main blocker for this right now is the dependency on minbrowser/dragula. I've tried some ugly sed:ing to correct the URL to both the correct repo or even the upstream repo, but neither seem to work, and the build fails.

If anyone wants to work on this you need the flatpak node helper to generate a list of the required npm packages. You do this by running npm install --package-lock-only in the min source then running flatpak-node-generator npm package-lock.json to generate generated-sources.json, which is then used in the flatpak build process. This step is also where I think the current failure is, since it seems to generate some odd results for the dragula repo.

If you want to try building this yourself you do so by running flatpak-builder --user --install --force-clean build-dir org.minbrowser.Min.yml

[saccarosium]

Hi @ludvigng, I'm interested in making the flatpak myself. Is it something that the author is ok with?

To add to the reasons with flatpak is a great fit:

• flatpack as a format is decentralized and work with whatever remotes you want. For example the GNOME guys uses a separate remote for development and then upstream into the stable versions to flathub.
• basically in the moment you use a flatpak you can distribute on every linux distro that supports flatpak (basically any distro that matter).

[ludvigng]

Hi @ludvigng, I'm interested in making the flatpak myself. Is it something that the author is ok with? No idea, they haven't said much on the topic afaict. I figured I'd see if I got something working and then open a pull request to the min repo.

Or do you mean the flatpak stuff I posted? Go ahead, that's for anyone to continue working with if they'd like. Let me know if you can get it working! 🙂

[PalmerAL]

Is it something that the author is ok with?

Sorry for the late response. I am open to other package formats; I'm not super familiar with what the current situation on Linux is. Is Flatpak the best / most widely supported format currently?

I was having a discussion with someone ("yotio") on Discord about this a few weeks ago; they were interested in working on this also. Not sure what their Github username is or if they're still interested.

Our Electron build tool does have some Flatpak support, but it comes with a warning that it's incomplete: https://www.electron.build/configuration/flatpak.html. I'm not sure what exactly is required here to get it fully working.

[saccarosium]

Is Flatpak the best / most widely supported format currently?

To keep it short yes.

I've been tring to make it but for now I have a blocker tracked here. But I will try to make it work when I can.

I was having a discussion with someone ("yotio") on Discord about this a few weeks ago; they were interested in working on this also. Not sure what their Github username is or if they're still interested.

Good I like chanlenges :)

[PalmerAL]

Can we run npm install in a script in our own code, and then feed the result into the flatpak tool with all the packages already installed?

[ludvigng]

The idea is that you just upload the flatpak manifest file to the flathub build server, and it builds the package in a clean environment. So npm won't have any network access during build time, but the flatpak helper can create a list of npm packages and add it to the flatpak manifest to download the npm packages in advance, the same way it downloads other sources like the min source itself, so npm can install them from local instead. I think that's like what you're suggesting, but for me it failed on the dragula repo.

You can add upload files along with the manifest, but it's recommended that you use proper upstream channels instead (with specific commits or versions). We might be able to do this for the dragula repo if everything else fails maybe.

[PalmerAL]

Oh, I guess the issue is that it doesn't github repository paths, rather than simple package names? (Because we're using our own fork of Dragula, rather than the NPM version).

I was planning to remove Dragula at some point and replace our usage of it with SortableJS anyway; I could do that sooner if it's necessary for this.

[ludvigng]

Yeah I think that was the issue, npm really didn't like even after cloning the fork locally. I don't know if it's necessary to remove it, it's probably very possible to work around it, it's just that I never managed to solve it by myself and eventually I gave up since I don't have much experience with npm. 😁

[PalmerAL]

If you wanted to keep working on the flatpak package, you could just switch Dragula back to the NPM version for now; I think the only consequence would be that tab dragging would become slightly buggy.

[ludvigng]

That's a good suggestion, maybe I'll give it another after spring when things calm down a little for me!