I write English / Escribo en Español.

Vidya / videojuegos. Internet. Cats / Gatos. Pizza. Nap / Siesta.

This user’s posts under CC-BY-NC-SA license. Ask me if you need a different permission.

  • 0 Posts
  • 34 Comments
Joined 1 year ago
cake
Cake day: July 26th, 2023

help-circle

  • If you are using Gnome distros: you can feel exactly what it feels like getting back to working in a restricted, overhyped, overbranded environment like Windows.

    If you are using Ubuntu: you can get advertising during your system’s software upgrades. No, really.

    If you are using Arch: you can post aroudn the internet saying you use Arch btw.

    Depending on the distro, you can use some alternative software stacks, but that’s mostly the backend (eg.: systemd versus openRC, Apache vs Nginx, X vs Wayland); most “desktop app” level is mostly the same for each desktop environment, is kinda the point.









  • Think about it, do you really want to have X11 going forward the next decades?

    If the alternative is a new system that literally does nothing? Sure!

    Want to present a menu for windows? Wayland: “lol, do it yourself”.

    Want to position a window? Wayland: “lol, do it yourself”.

    Want to remember that a window has a position? Wayland: “lol, do it yourself”.

    Want to add a global keyboard shortcut? Wayland: “AAAAHAHAHAHAHAHAHHAHAHAHAHAHAHA!”

    X11 may be old and whatever you want, but it works and it’s battle-tested. Wayland can’t even launch a full desktop session in my machine, which is even less than the failure Pulseaudio was back in its day and that’s saying something. And even if it did somehow launch, I probably would not be able to use anything serious like a media player or multiple workspaces on it.





  • I ask for some method that prevents the file to even be copied through a disk clone

    Oh that’s quite simple! Just don’t have the files on the first disk in the first place. Make them a remote mount from a server, for example via sshfs, webdav, etc. Heck, even ftp if it comes down to it. That way, even though you can clone the disks, you can not get to the files if you don’t also have the full authentication requirements for the remote server (such as a password).

    At a conceptual level, you can’t do anything via root to prevent someone who clones the disk from… well, cloning the disk. Having physical access to a disk is a much higher level of access than even root, so if what you are looking for is for your content to not be cloned, you need to fortify physical access to the device.





  • And no, it wasn’t just the favicons feature that was removed (which like … is that really such a big privacy issue that you need to remove it from the binary?)

    Fetching a favicon means raising a network connection with a predictable endpoint. That’s already three concerns (four on the modern internet) to handle security-wise, and it’s absolutely an unneeded feature. Favicons could just be shipped on something like keepassxc-data or keepassxc-contrib to handle locally, no need to raise a network call.


  • Storm in a teacup, as tends to be the norm on the internet.

    Not only this is nothing new and nothing unexpected to happen in Sid of all places, but it’s also something that helps bring keepassxc more in line with packaging guidelines on Debian. They already have lots of packages, both of the mutually-exclusive kind and of the complementary kind, with “foo-full”, “foo-minimal”, “foo-data” etc naming. p7zip and nginx of all things are quite interesting examples.

    Plus, the author of the post sensationalizes the title to brigade the issue.

    All that said:

    • If the maintainer wishes to do this, “only” having two packages is a half-assed measure and that causes more issues in the long term. I’d expect three packages: keepassxc-minimal, keepassxc-full and the retained name keepassxc as a virtual package name.
    • Furthermore, a direct upgrade path should go from (previous) keepassxc to (proposed) keepassxc-full.
    • I don’t know enough of KeePassXC to know if something like keepassxc-data would be needed. Are there potential cases where one would want to switch between “-full” and “-minimal” or viceversa without the system seeing a software uninstallation in the meantime?
    • The “crap” rationale is definitively something we all can do without, but given how people tend to brigade developers who try to do things, I can completely understand and support raising shields and looking defensive because some damage is already going to be done.
    • Most responses are right in that the right place to discuss this is in the opened Debian bug report. The entire point is to see Debian (not KeepassXC) handle this before things get to Next Stable.

  • lambalicious@lemmy.sdf.orgtoLinux@lemmy.mlThe cost of maintaining Xorg
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    5
    ·
    1 year ago

    But keeping around X isn’t the solution - iterating on Wayland is. Adding protocols to different parts of the stack with proper permission models, moving different pieces of X to different parts of the stack, etc. are a long term viable strategy. Even if it is painful.

    The problem is, that’s always used as an excuse to force people to be gratis beta testers. I’ve been around for the wrecks that were (and still are) Pulseaudio and Systemd. Wayland is even worse: it doesn’t even fully start a session in my machine. If as devs you want to “iterate”, sure, go ahead; but leave it in the dev branch; as a user, don’t try to sell me Wayland again until it’s actually over.