5 ms·

How did you get your web browser to work in DOS?

by genter 3y ago

creshal 3y ago
Polkit is entirely redundant (dbus has its own permission system, not that you need it) and it's trivial to build a linux desktop without it. (None of my systems have it installed, e.g.) Dbus is harder to replace, since the complexity addicts at Redhat and KDE decreed it to be The Default Linux IPC, but realistically, most programmers who think they need could do with a solution 10% as complex and 10x as fast. (dbus-broker is a step in the right direction, but not radical enough.)
- Scarbutt 3y ago
  What do you use as alternatives to xdg-desktop-portal and its backends which require rtkit/polkit?
  - bandrami 3y ago
    I can't speak for polkit, but in the absence of rtkit the gid/uid limits set in limits.conf work just fine even over a portal. I honestly never understood what was allegedly gained by moving that logic from one place to another. (For that matter the analogy with polkit and group permissions works for a lot of things.)
  - creshal 3y ago
    Wayland and snaps/flatpaks were more overly complicated mistakes, the alternative will be to go back to drawing board and not come back until there's a solution less stupid.
- _factor 3y ago
  It’s hard to sell enterprise support if your product is simple and easy to understand.
- bluGill 3y ago
  The problem is everyone's 10% solution is different and so the complexity is easier than the sum total of all the others you would have.
  - creshal 3y ago
    DBus is really quite a magical place, I'm sure if you actually dig through how open source projects use it, you'll find that the vast majority of projects don't really interact with most of its features and just do the bare minimum the protocol forces them to declare (object paths vs object class hierarchies, dbus perms vs polkit perms, ...), or they're stuff that sounded like a good idea 20 years ago and hasn't been for 15 (defining its own data serialization layer, incompatible to everything else).
    - SSLy 3y ago
      Finally some actual feedback. Which alternative IPC + capability delegation protocol do you wish linux used instead?
      - enriquto 3y ago
        > Which alternative IPC + capability delegation protocol do you wish linux used instead? Why "alternative"? Aren't file-based operations good enough? A program reads and writes data to files/devices, which it can or cannot do according to the permissions that it sees. From the point of view of the program, nothing else is needed beyond fopen,fread and fwrite. If finer control is needed, it's not for the program to implement, but for the OS to expose. An improvement to the dbus+polkit mess would be something that programs don't link to, something that is entirely invisible to programs beyond the possibility to open certain files at runtime.
        freedomben 3y ago
        > Why "alternative"? Aren't file-based operations good enough? For some things yes, for other things no. If you're just making a basic config, yeah writing to a text file can be sufficient. Though, that requires defining a protocol/standard and following that. You could use a socket, but similarly that requires a protocol, possibly at multiple levels in the stack. Besides adding unnecessary overhead, that also loses all the OS-level information such as which user/privilege level is the caller running as? Now suppose you need it to be highly and quickly reactive (or what we used to call "event driven"). Suppose you also need to impose authentication and access controls. You could use the built-in file stuff for authn/authz, but not really event driven and most solutions to that are slow and bolted-on, and there's no pre-defined schema (so back to protocol defining). You could use socket but no built-in authn/authz. I rejoice in simplicity, and strongly prefer it when possible. But limiting only to simple solutions means there's a lot of stuff you can't do, and when you need to do those things, this is not great. And if you have to learn and use multiple solutions based on the level of complexity of the use case, then it may be simple from the dev's point of view, but it's certainly not from the operator's point of view.
- kps 3y ago
  Some of it is… impressive. “These side effects are also in some sense shortcomings of the D-Bus configuration scheme, since developers of a specific D-Bus service don’t expect that their configuration file has a global influence.”

How did you get your web browser to work in DOS?

by genter 3y ago

How did you get your web browser to work in DOS?

Polkit is entirely redundant (dbus has its own permission system, not that you need it) and it's trivial to build a linux desktop without it. (None of my systems have it installed, e.g.) Dbus is harder to replace, since the complexity addicts at Redhat and KDE decreed it to be The Default Linux IPC, but realistically, most programmers who think they need could do with a solution 10% as complex and 10x as fast. (dbus-broker is a step in the right direction, but not radical enough.)

Scarbutt 3y ago
What do you use as alternatives to xdg-desktop-portal and its backends which require rtkit/polkit?
- bandrami 3y ago
  I can't speak for polkit, but in the absence of rtkit the gid/uid limits set in limits.conf work just fine even over a portal. I honestly never understood what was allegedly gained by moving that logic from one place to another. (For that matter the analogy with polkit and group permissions works for a lot of things.)
- creshal 3y ago
  Wayland and snaps/flatpaks were more overly complicated mistakes, the alternative will be to go back to drawing board and not come back until there's a solution less stupid.
_factor 3y ago
It’s hard to sell enterprise support if your product is simple and easy to understand.
bluGill 3y ago
The problem is everyone's 10% solution is different and so the complexity is easier than the sum total of all the others you would have.
- creshal 3y ago
  DBus is really quite a magical place, I'm sure if you actually dig through how open source projects use it, you'll find that the vast majority of projects don't really interact with most of its features and just do the bare minimum the protocol forces them to declare (object paths vs object class hierarchies, dbus perms vs polkit perms, ...), or they're stuff that sounded like a good idea 20 years ago and hasn't been for 15 (defining its own data serialization layer, incompatible to everything else).
  - SSLy 3y ago
    Finally some actual feedback. Which alternative IPC + capability delegation protocol do you wish linux used instead?
    - enriquto 3y ago
      > Which alternative IPC + capability delegation protocol do you wish linux used instead? Why "alternative"? Aren't file-based operations good enough? A program reads and writes data to files/devices, which it can or cannot do according to the permissions that it sees. From the point of view of the program, nothing else is needed beyond fopen,fread and fwrite. If finer control is needed, it's not for the program to implement, but for the OS to expose. An improvement to the dbus+polkit mess would be something that programs don't link to, something that is entirely invisible to programs beyond the possibility to open certain files at runtime.
      - freedomben 3y ago
        > Why "alternative"? Aren't file-based operations good enough? For some things yes, for other things no. If you're just making a basic config, yeah writing to a text file can be sufficient. Though, that requires defining a protocol/standard and following that. You could use a socket, but similarly that requires a protocol, possibly at multiple levels in the stack. Besides adding unnecessary overhead, that also loses all the OS-level information such as which user/privilege level is the caller running as? Now suppose you need it to be highly and quickly reactive (or what we used to call "event driven"). Suppose you also need to impose authentication and access controls. You could use the built-in file stuff for authn/authz, but not really event driven and most solutions to that are slow and bolted-on, and there's no pre-defined schema (so back to protocol defining). You could use socket but no built-in authn/authz. I rejoice in simplicity, and strongly prefer it when possible. But limiting only to simple solutions means there's a lot of stuff you can't do, and when you need to do those things, this is not great. And if you have to learn and use multiple solutions based on the level of complexity of the use case, then it may be simple from the dev's point of view, but it's certainly not from the operator's point of view.
kps 3y ago
Some of it is… impressive. “These side effects are also in some sense shortcomings of the D-Bus configuration scheme, since developers of a specific D-Bus service don’t expect that their configuration file has a global influence.”