What browser do you use?

[swh]

Running it from Terminal in the directory I can call ./floorp -P and that works as well.
Just as ./floorp --profilemanager

[swh]

Cool. Just uncheck the box and I can select the profile every time I start floorp

Thanks @pebcak

[pebcak]

Arkenfloorp! Sounds great! You got your own fork now!

[swh]

Arkenfloorp…sounds cool, eh

[anon93652015]

I currently use a WM and I actually use hotkeys to launch my profiles. Maybe this would be better?

Example:

super+F = firefox <- this would be the default profile
super+Shift+F = firefox -P profileName2
super+Alt+F = firefox -P profileName3

[swh]

@anon93652015

Maybe this would be better?

I’ll give it a try. That is certainly interesting but I don’t know if that works for me. I have only unpacked Floorp and start it from the directory. Actually it works quite well now, the profile manager opens as soon as I start Floorp and I can select a profile.

Nevertheless, I’ll take a closer look at your suggestion.

Many Thanks

[dalto]

@pebcak

Please correct me if I am wrong, a PKGBUILD from AUR just describes how some binary is build from some source code and installed on your system.

Yes and no. For a source package yes. But for a browser, most people will be downloading the binary.

A binary package is much simpler. It basically just has how it is downloaded and installed. All you really need to see is where is the binary coming from. It should always be an official source. Then how/where is it being installed.

@pebcak

doesn’t a user need to audit the code from the source?

That is a different issue and is true(or not) no matter what format you choose. If you don’t trust the software itself, it doesn’t matter which format you use to install it.

The issue with containerized software is that it isn’t only the software that matters, but what else is in the container.

[anon93652015]

You’re welcome. It’s all about what’s better for you in the end.

[pebcak]

@dalto

@pebcak

Please correct me if I am wrong, a PKGBUILD from AUR just describes how some binary is build from some source code and installed on your system.

For a source package yes.

This was mainly what I had in mind.

@dalto

@pebcak

doesn’t a user need to audit the code from the source?

That is a different issue and is true(or not) no matter what format you choose. If you don’t trust the software itself, it doesn’t matter which format you use to install it.

The AUR might be a bit more transparent that something like a flatpak or appimage, but at the end of the day, for the uninitiated user, incapable of reading the source code, no matter what format they will use there is always an element of “blind faith” involved.

[dalto]

@pebcak

The AUR might be a bit more transparent that something like a flatpak or appimage, but at the end of the day, for the uninitiated user, incapable of reading the source code, no matter what format they will use there is always an element of “blind faith” involved.

But it isn’t “apples to apples” blind faith. In one case we are trusting the software. In another we are trusting the software, the packaging and the packaging of a bunch of loosely related stuff.

The idea that AUR packages are only more transparent if you review the source code is fundamentally silly. It has nothing to do with reading the application source code.

[pebcak]

@dalto

@pebcak

The AUR might be a bit more transparent that something like a flatpak or appimage, but at the end of the day, for the uninitiated user, incapable of reading the source code, no matter what format they will use there is always an element of “blind faith” involved.

But it isn’t “apples to apples” blind faith. In one case we are trusting the software. In another we are trusting the software, the packaging and the packaging of a bunch of loosely related stuff.

I agree! If blindness could have degrees, one could say that that, without really knowing what the binary is build upon, one needs to have “less blind” faith when installing from AUR than the other formats.

@dalto

The idea that AUR packages are only more transparent if you review the source code is fundamentally silly. It has nothing to do with reading the application source code.

We need to keep two concepts separated here: transparency and trustworthiness

The transparency of AUR becomes less relevant when at the end, you don’t know the code from which the binary is build.

The PKGBUILD shows “how” a binary is build, from “what” source and “where” it gets installed in your system. In this regard it is transparent.

But when it comes to “trustworthiness” that is where the transparency becomes less relevant.

For the binary build with the transparency of the AUR to be trustworthy, you need to trust the source code. Either you can audit the code yourself or trust others who have done so. If you can’t then the element of the “blind faith” is at play.

[dalto]

@pebcak

But when it comes to “trustworthiness” that is where the transparency becomes less relevant.

For the binary build with the transparency of the AUR to be trustworthy, you need to trust the source code. Either you can audit the code yourself or trust others who have done so. If you can’t the the element of the “blind faith” is at play.

The challenge with this is that there is more than one thing to trust.

When considering between different packaging options for the same software, the trustworthiness of the software(and it’s source code) isn’t really relevant. There is an equal risk there in all cases.

However, the packaging is what I am worried about trusting in this case. In this situation the AUR packaging is completely transparent. For a binary AUR package, it is also very easy to review.

Now consider a flatpak. Not only is the packaging a bit more complicated, there are actually additional things bundled with it where you need to consider their packaging as well. On top of that, there is no in-band way to review all that like there is with an AUR helper.

That being said, my real concern here is the fundamental idea that because a flatpak/snap/appimage comes from the software developer, it is trustworthy. The reality is that most application developers aren’t experts at packaging and security. Even if they have good intentions, it is easy for something problematic to end up on your system and stay there without being noticed. Not many people highly scrutinize the bundled applications inside a flatpak.

Is a flatpak from the developer more trustworthy than a flatpak not from the developer? Absolutely, yes.

Is a flatpak from the developer more trustworthy than an AUR package not from the developer? I would say no.

[pebcak]

You make some good and valid points when it comes to the “opaqueness” of packaging formats like appimage and flatpak. I agree.

But my concern here is something else.

My impression is (or has been) that, oftentimes, when installing packages are discussed, the transparency of the process of building the binary and packaging it “the AUR way” is emphasized in a way as if it could be equaled with trustworthiness.

I would say that this is a misconception.

One could ( I am not saying would) end up running a malicious binary from some malicious source code but build in a perfectly transparent AUR manner.

And I would add that a large majority of GNU plus Linux and FOSS users who are not capable of auditing the codes running on their system must have some degree of “blind faith”, either in those who have done so or in the developers of the code.

[dalto]

@pebcak

My impression is (or has been) that, oftentimes, when installing packages are discussed, the transparency of the process of building the binary and packaging it “the AUR way” is emphasized in a way as if it could be equaled with trustworthiness.

Yes. As it relates to packaging that is true. The packaging of an AUR package is fully transparent.

Installing a package from AUR doesn’t make the software itself more trustworthy. But that isn’t what people are implying. Those conversations almost always come up when we are comparing packaging formats.

@pebcak

And I would add that a large majority of GNU plus Linux and FOSS users who are not capable of auditing the codes running on their system must have some degree of “blind faith”, either in those who have done so or in the developers of the code.

Again, we are conflating two very different things. The trust in the application and the trust in the packaging. Nobody, no matter how savvy, validates the source of every application running on their machine. That isn’t practical. Validating the source isn’t even relevant to the conversation.

[pebcak]

@dalto

As it relates to packaging that is true. The packaging of an AUR package is fully transparent.

I agree.

@dalto

Installing a package from AUR doesn’t make the software itself more trustworthy.

No it doesn’t.

@dalto

Nobody, no matter how savvy, validates the source of every application running on their machine. That isn’t practical.

No it isn’t.

@dalto

Validating the source isn’t even relevant to the conversation.

Let’s put it differently:

Who would want to run an untrustworthy code on their system packaged in a perfectly transparent way?

I would say that the question of trustworthiness of the code should be, if not of more relevancy, at least of equal relevancy of the trustworthiness and transparency of the packaging.

That is why I asked the question to begin with a bit further above.

With the risk of repeating myself and regardless of who prefers what packaging format, their pros and cons, when it comes to AUR and its transparent packaging, there is a possibility that

@pebcak

One could ( I am not saying would) end up running a malicious binary from some malicious source code but build in a perfectly transparent AUR manner.

Unless one cannot be assured of the trustworthiness of the code using the transparent AUR packaging, some degree of “blind faith” is at play. As it is for most of us common mortals doing our best to keep at GNU plus Linux, FOSS and what not.

So let us all pray to some digital divinity to keep our systems free from the “Mal”

[dalto]

@pebcak

Who would want to run an untrustworthy code on their system packaged in a perfectly transparent way?

Unfortunately, probably a lot of people.

But yes, nobody should do that.

@pebcak

I would say that the question of trustworthiness of the code should be, if not of more relevancy, at least of equal relevancy of the trustworthiness and transparency of the packaging.

Of course it should. But that has nothing to do with choosing between a flatpak/snap/appimage/repo/AUR package.

We should first consider if we should install something. If yes, then we can determine how to install it.

[pebcak]

@dalto

We should first consider if we should install something.

True that.
With time, I have come to put in practice, more and more, the idea of “Less is More” (or translated into the Arch jargon “Keep It Simple Stupid”).

My most trusted system is build as minimal as possible to just run a terminal, a browser, a file manager and a text editor.

@dalto

If yes, then we can determine how to install it.

On other more “casual” systems, I do run some flatpaks and a couple of appimages in which I have absolute “Blind Faith”

[LDC]

I agree with @dalto, there are pro and cons for every choice, in this specific case I prefer pulling from the AUR, compiling each and every time. It may just be personal bias, but I am not particularly fond of the flatpack technology, and thus limit its use to the bare minimum possible on my system.
However, again, it would be nice to have an appimage version…