I think it makes more sense than what we use for browsing internet. Just like date format, it goes from biggest to smallest. TLD.domain.subdomain.
Just as god intended.
And is just happened to be like this because of email. https://www.rfc-editor.org/rfc/rfc805.txt:
The major conclusion reached at the meeting is to extend the "username@hostname" mailbox format to "username@host.domain", where the domain itself can be further structured.
I don't know how helpful that is. Who really gives a shit if it's a .com or .org?
In the date example that is pretty relevant- I don't see how it's super relevant here. It's necessary of course but not very important for a user. Can you imagine using auto complete having to specify com.BBC or com.espn?
In any case, having it user facing instead of a simple "Firefox" style name seems dumb anyway. It's fine for just development.
For those who aren't familiar, it's the org.mozilla.Firefox instead of "Firefox".
It's awful.
- Signed, someone who maintains 4 Flatpaks
That's kind of used in apps everywhere… I can see why.
But not creating a symbolic link to 'firefox' when you install it, is a PITA. Apparently by design…
hmm idk what you mean. this looks delicious: https://en.wikipedia.org/wiki/Pita
Idk with all that news about hummus lately.
Doesn't flatpack use
dpkg'supdate-alternativesor something like it?It is pretty easy to automate this. Flatpaks cant do that if they are running really isolated. The flatpak app would need to do that.
deleted by creator
aah sorry I'm using lemmy for the first time
I maintain a flatpak aswell and I found it very strange that I'm not allowed to pick my own name. What do you hate most about it?
That it is not common everywhere.
As an internal implementation detail, it's fine and pretty standard. Exposing it to the end user so that they have to know whatever janky-ass domain and capitalization you picked to run your application is braindead.
It’s how dns should have been.
And it is perfect. Now at least I can fork Firefox and not cause issues with the one maintained by mozilla, but have both on my system!
It is very typical of package management schemes for various software platforms. Java is like this, and so is Android. Prior to Gtk v3 (I think) the GConf Manager utility also organized app configurations this way. The DBus inter-process communication mechanism also uses this scheme to create a namespace for all possible applications in the system that might want to use the bus service.
It is what it is, I neither like it nor dislike it.
I don't care but it's annoying that they won't put a normal application name into
$PATH.There is a denied GitHub Issue for it but I can't be bothered finding it. It'll never happen so it doesn't matter.
Neither: I am not aware of it.
While we're whining (alias to executable please), what's with 'flatpak run' needing an instance ID instead of the domain of the running program, here's me parsing 'flatpak ps' so I can access the app's command line flags programmatically. Not a big deal, but, as @deong says, braindead.
I think it's dumb. Software only hosted on Github without a dedicated website shouldn't use com.github.appname. If Flatpak adopts parts of Android's security system, all com.github.* applications could access each others data. That's awful but I don't think it's going away. It's too late for that.
Now that I think of it, what I would wish for is for an the Flatpak published a guideline how to deal with developers who don't have a domain name, eg. flatpak.devname.appname instead of com.github.appname
I'm curious about what you mean by the issue with Android's security model. Apps can have whatever package name they want (… Well, I am sure you can't publish a
com.googlepackage on the Play Store) so that doesn't make sense.The only thing I can imagine you're referring to is data sharing between applications signed with the same key, but that's not the package name.
From what I've read, applications by the same vendor can automatically log into the vendor's services after one app is logged in because they share the same name space. What else would name space be if not com.facebook., com.google., com.microsoft.*, etc.?
I'm pretty sure they have to be signed with the same keys only
See the 3rd bullet point here https://developer.android.com/studio/publish/app-signing#considerations
Huh. Maybe it was different before or whatever I've read was just wrong. Good to know.
It’s not android so that’s not how permissions work.
It’s not android
Which part of "If Flatpak adopts parts of Android’s security system" don't you understand? Do you need help with conditionals in the English language?
Flatpak already has an established security model.
Your statement is pointless and you are rude.
Flatpak already has an established security model.
You are not a Flatpak core developer, so you have absolutely no idea whether they decide if different applications from the same vendor will at some point be allowed to access each others data.
Your statement is pointless
It's not pointless to think about possible future decisions a crucial piece of software might have to make. I also replied to a question from OP, so it's not your decision what is pointless and what isn't anyway.
and you are rude.
If you think that being an uninvited "But actually" comment isn't rude, you have a skewed sense of reality. I was answering a question from OP, not yours. You're the one who engaged with that attitude. Look in the mirror before making accusations.
Edit: Blocking you now. Not engaging with a brat any longer.
Looks you're talking about flathub, not flatpak…
So flatpak itself does not enforce the use of the reverse DNS naming scheme?
Flatpak uses a . separator for namespaces. Mostly because DBus does.
The association with a real domain is a Flathub policy.
