lionirdeadman's recent activity

  1. Comment on What are your feelings towards achievements? in ~games

    lionirdeadman
    Link
    I like them to see how much of the game I've experienced and try to 100% game I like. I absolutely hate achievements which require a multiplayer component because they might be impossible to get...

    I like them to see how much of the game I've experienced and try to 100% game I like. I absolutely hate achievements which require a multiplayer component because they might be impossible to get if no one plays the multiplayer anymore and they're generally just pointless grinding with no reward.

    6 votes
  2. Comment on The free and open-source digital audio editor Audacity has been acquired by Muse Group in ~tech

    lionirdeadman
    Link Parent
    Could simply be management. From what I've seen, the Lead Designer of MusicScore (another project which got acquired by Muse Group in 2017), Martin Keary, wants to help with designing Audacity....

    Could simply be management. From what I've seen, the Lead Designer of MusicScore (another project which got acquired by Muse Group in 2017), Martin Keary, wants to help with designing Audacity. So, that's part of the acquisition.

    7 votes
  3. Comment on Share your linux desktop/setup in ~comp

    lionirdeadman
    Link Parent
    It has "deployements" which I think are similar to what you're asking. This is my current system : rpm-ostree status State: idle Deployments: ostree://fedora:fedora/34/x86_64/silverblue Version:...

    It has "deployements" which I think are similar to what you're asking.

    This is my current system :

    rpm-ostree status
    State: idle
    Deployments:
      ostree://fedora:fedora/34/x86_64/silverblue
                       Version: 34.20210501.0 (2021-05-01T02:43:16Z)
                    BaseCommit: abbcef71d901c2328098bf7d2480521f361cccf61ef1cb93ac4a9a9508269c2c
                  GPGSignature: Valid signature by 8C5BA6990BDB26E19F2A1A801161AE6945719A39
                          Diff: 2 added
           RemovedBasePackages: xorg-x11-drv-fbdev 0.5.0-8.fc34, xorg-x11-drv-evdev 2.10.6-9.fc34, xorg-x11-drv-qxl 0.1.5-19.fc34, xorg-x11-drv-openchrome 0.6.400-1.20210215git5dbad06.fc34, xorg-x11-server-Xorg 1.20.11-1.fc34, xorg-x11-drv-vmware 13.2.1-15.fc34, xorg-x11-drv-wacom 0.40.0-1.fc34, gnome-session-xsession 40.1.1-1.fc34, xorg-x11-drv-vesa 2.4.0-11.fc34, xorg-x11-drv-nouveau 1:1.0.15-11.fc34, xorg-x11-drv-amdgpu 19.1.0-8.fc34, xorg-x11-drv-ati 19.1.0-5.fc34, firefox 88.0-5.fc34, xorg-x11-drv-intel 2.99.917-50.20200205.fc34, xorg-x11-drv-libinput 1.0.1-1.fc34
          ReplacedBasePackages: flatpak-libs flatpak flatpak-selinux flatpak-session-helper 1.10.2-3.fc34 -> 1.11.1-1.fc34
               LayeredPackages: abrt adb dconf-editor docker-compose flatpak-builder gnome-abrt gnome-usage lm_sensors power-profiles-daemon zsh zstd
    
    ‚óŹ ostree://fedora:fedora/34/x86_64/silverblue
                       Version: 34.20210501.0 (2021-05-01T02:43:16Z)
                    BaseCommit: abbcef71d901c2328098bf7d2480521f361cccf61ef1cb93ac4a9a9508269c2c
                  GPGSignature: Valid signature by 8C5BA6990BDB26E19F2A1A801161AE6945719A39
           RemovedBasePackages: xorg-x11-drv-fbdev 0.5.0-8.fc34, xorg-x11-drv-evdev 2.10.6-9.fc34, xorg-x11-drv-qxl 0.1.5-19.fc34, xorg-x11-drv-openchrome 0.6.400-1.20210215git5dbad06.fc34, xorg-x11-server-Xorg 1.20.11-1.fc34, xorg-x11-drv-vmware 13.2.1-15.fc34, xorg-x11-drv-wacom 0.40.0-1.fc34, gnome-session-xsession 40.1.1-1.fc34, xorg-x11-drv-vesa 2.4.0-11.fc34, xorg-x11-drv-nouveau 1:1.0.15-11.fc34, xorg-x11-drv-amdgpu 19.1.0-8.fc34, xorg-x11-drv-ati 19.1.0-5.fc34, firefox 88.0-5.fc34, xorg-x11-drv-intel 2.99.917-50.20200205.fc34, xorg-x11-drv-libinput 1.0.1-1.fc34
          ReplacedBasePackages: flatpak-libs flatpak flatpak-selinux flatpak-session-helper 1.10.2-3.fc34 -> 1.11.1-1.fc34
               LayeredPackages: abrt adb dconf-editor docker-compose flatpak-builder gnome-abrt gnome-usage power-profiles-daemon zsh zstd
    
      ostree://fedora:fedora/34/x86_64/silverblue
                       Version: 34.20210430.0 (2021-04-30T00:39:49Z)
                    BaseCommit: 9b55a57e2ee6844408a199b833ec9ee5cac1b01563583ecc9aee26c139ad55b7
                  GPGSignature: Valid signature by 8C5BA6990BDB26E19F2A1A801161AE6945719A39
           RemovedBasePackages: xorg-x11-drv-fbdev 0.5.0-8.fc34, xorg-x11-drv-evdev 2.10.6-9.fc34, xorg-x11-drv-qxl 0.1.5-19.fc34, xorg-x11-drv-openchrome 0.6.400-1.20210215git5dbad06.fc34, xorg-x11-server-Xorg 1.20.11-1.fc34, xorg-x11-drv-vmware 13.2.1-15.fc34, xorg-x11-drv-wacom 0.40.0-1.fc34, gnome-session-xsession 40.1.1-1.fc34, xorg-x11-drv-vesa 2.4.0-11.fc34, xorg-x11-drv-nouveau 1:1.0.15-11.fc34, xorg-x11-drv-amdgpu 19.1.0-8.fc34, xorg-x11-drv-ati 19.1.0-5.fc34, firefox 88.0-5.fc34, xorg-x11-drv-intel 2.99.917-50.20200205.fc34, xorg-x11-drv-libinput 1.0.1-1.fc34
          ReplacedBasePackages: flatpak-libs flatpak flatpak-selinux flatpak-session-helper 1.10.2-3.fc34 -> 1.11.1-1.fc34
               LayeredPackages: adb dconf-editor docker-compose flatpak-builder gnome-usage power-profiles-daemon zsh zstd
    
      ostree://fedora:fedora/33/x86_64/silverblue
                       Version: 33.20210207.0 (2021-02-07T00:56:44Z)
                    BaseCommit: 14706469057c430ff7484aee7014bc44ceed975c2367c60da5b4927918aaaeab
                  GPGSignature: Valid signature by 963A2BEB02009608FE67EA4249FD77499570FF31
               LayeredPackages: compsize fish podman-compose
                        Pinned: yes
    
    1 vote
  4. Comment on Share your linux desktop/setup in ~comp

    lionirdeadman
    Link Parent
    My experience has been pretty good. There was a early bug about a month or two ago where it needed a hack for gnome but that's been fixed a while ago.

    My experience has been pretty good. There was a early bug about a month or two ago where it needed a hack for gnome but that's been fixed a while ago.

    1 vote
  5. Comment on Share your linux desktop/setup in ~comp

    lionirdeadman
    Link Parent
    You do! You can use toolbox or rpm-ostree to install things in a container or on the base system. The order in which you should install things should basically always be : Flatpak > Toolbox >...

    You do! You can use toolbox or rpm-ostree to install things in a container or on the base system.

    The order in which you should install things should basically always be :
    Flatpak > Toolbox > rpm-ostree

    Flatpak should work if it's a graphical application. If it doesn't or it's needed for development, toolbox is preferred because you can get rid of it easily and reproduce it. If that's not possible because it's a system-level thing like say, zsh, adb, lm_sensors or things like that, you use rpm-ostree. It may require a reboot but nowadays you can rpm-ostree ex apply-live to avoid that.

    1 vote
  6. Comment on Share your linux desktop/setup in ~comp

    lionirdeadman
    Link
    Joining late too, I use Fedora Silverblue 34. Audio is handled by Pipewire, Display protocol is Wayland, Shell is zsh. I don't use any GNOME extensions nor modified the GTK Stylesheet. I use...

    Joining late too, I use Fedora Silverblue 34.

    Audio is handled by Pipewire, Display protocol is Wayland, Shell is zsh. I don't use any GNOME extensions nor modified the GTK Stylesheet. I use Flatpaks for most if not all my applications.

    I think that's pretty much everything I'd really note about it.

    Here's a screenshot for it, the fox is Xenia, she was one of the choices proposed for a Linux mascot and I like her quite a bit. The wallpaper was made by my friend.

    3 votes
  7. Comment on Share your linux desktop/setup in ~comp

    lionirdeadman
    Link Parent
    Most of GNOME Shell is handled by Mutter which is C. The UI is JS (Shell Toolkit) and there's still some stuff there but I wouldn't call it a behemoth though. Although with extensions that...

    (GNOME is a JavaScript behemoth)

    Most of GNOME Shell is handled by Mutter which is C. The UI is JS (Shell Toolkit) and there's still some stuff there but I wouldn't call it a behemoth though. Although with extensions that obviously increases the percentage of JS.

    1 vote
  8. Comment on COSMIC is a GNOME-based desktop environment developed by System76 in ~comp

    lionirdeadman
    Link
    I honestly don't know what to think about this. As far as I'm aware, System76 was never a big contributor to GNOME (if at all) but forking GNOME (which seems to be what is happening) is...

    I honestly don't know what to think about this. As far as I'm aware, System76 was never a big contributor to GNOME (if at all) but forking GNOME (which seems to be what is happening) is essentially ensuring that never happens.
    Wasted opportunity, I suppose.

    It seems very clear though that Sys76 and GNOME designers don't have the same vision of the desktop so in a way, I guess it means that there will be less fighting over design decisions which is good.

    3 votes
  9. Comment on Microsoft enables Linux GUI apps on Windows 10 for developers in ~tech

    lionirdeadman
    Link Parent
    Well, you said : I assumed this included commercial software. The idea being dropping Windows support in favour of Linux support since it's possible to run through WSL2. It's also an idea that I...

    Well, you said :

    If anything, I think that this goal they are working towards will make developers drop support for the Windows versions of their applications, since users will be able to run the Linux versions directly, which I see as a benefit to everyone

    I assumed this included commercial software. The idea being dropping Windows support in favour of Linux support since it's possible to run through WSL2. It's also an idea that I think is supported by Microsoft giving WSL2 a DX12 driver which would make for WSL2-specific software which I don't know anyone but enterprise or commercial would use. My bad though, I thought that's what you meant.

  10. Comment on What should a lay user know about Linux app packaging? in ~tech

    lionirdeadman
    Link Parent
    Flatpak is not made for any distro in particular. You can totally use it on Arch. PKGBUILDs are not safe, it can totally just delete your entire system. You've said yourself that people should...

    Flatpak aims to solve this "not all software is available" for non-Arch distros like Debian or Ubuntu

    Flatpak is not made for any distro in particular. You can totally use it on Arch.

    while Arch just makes it safe for random people to take care of packaging

    PKGBUILDs are not safe, it can totally just delete your entire system. You've said yourself that people should read what they do so I find this a bit strange.

    That doesn't matter, anyway - you may have missed the part where I described Arch's system of version locking.

    Doesn't version locking result in other packages needing the same library being unable to update or does Arch have a modular system? It's my understanding it doesn't have one but I could be wrong.

    And I'm talking about Arch.

    I think there is a misunderstanding between our interpretations. You said it was that Flatpak was an answer to the AUR, I disagree with that. It's all I care about when it comes to Arch specifically.

    It seems Flatpaks maintained not maintained by the developer (these exist, before you say otherwise) could end up suffering the same problem.

    This is true. I am one of the maintainers so I certainly acknowledge that however Flathub tries to always go for the upstream development being involved whenever possible.

    how, possibly, could I make it any clearer that in absence of an official project statement, the specific ranked order of goals is left up to opinion?

    I guess I just don't think a project's goals are someone who's not involved in the project's opinion. I think it can be misleading to say that.

    My view on Flatpak's sandboxing stands - not restricting .bashrc writes and the like is not what I'd expect out of a project that has security as its primary goal

    Flatpak packages do restrict .bashrc whenever it is possible without being destructive to using the application. The discord package that I maintain for example only has access to "--filesystem=xdg-videos:ro", "--filesystem=xdg-pictures:ro", "--filesystem=xdg-download", and I plan to remove all filesystem access as soon as possible.

    I don't care that it's better than nothing. I don't care that fine-grain permissions can be tweaked. That's not what I said, and you know it.

    I don't believe I've said that you specifically cared about permissions but the flatkill article completely ignores that information and you showed it as proof of the sandboxing not being good enough so I thought I'd mention it because I believed it was relevant.

    I seem to recall having other conversations with you specifically that have gone down this non-constructive, intentionally-misquoting route, so I'm breaking it off here.

    I'm sorry if that's been your experience with me, it's definitely not my intention to misquote people and I try to be constructive. If you feel like it, please DM me to show me where you think I misquoted you, I want to be better.

  11. Comment on What should a lay user know about Linux app packaging? in ~tech

    lionirdeadman
    Link Parent
    But this is the reason it exists so you can't call flatpak an answer to the AUR if they don't solve the same problem.. This is not "very few", most if not all games do this hence why the steam...

    I am not claiming that the AUR solves Linux fragmentation.

    But this is the reason it exists so you can't call flatpak an answer to the AUR if they don't solve the same problem..

    for the (very) few programs that do

    This is not "very few", most if not all games do this hence why the steam runtime was made all the way back in 2013 and is being upgraded even today to make it impossible to rely on the host because some game developers relied on the host rather than steam runtime which resulted in game bugs. Most programs require specific versions for API/ABI compatibility. They just happen to work with newer versions.

    Distro-specific bugs are bugs.

    They are distro bugs. Developers should not have to deal with every bug that is specific to a distribution.

    I certainly don't think and haven't observed there being "tons and tons" coming from Arch

    I'm not only talking about Arch here, I'm talking about application distribution in general. Arch is just one way this may happen.

    Your Authenticator example is the exception, not the norm, and in fact has already been fixed by kind and constructive people.

    Wrong bug, I'm talking about this one where the developer was told that they were in the wrong for patching Gstreamer for their usecase and that they should "drink some baking soda".

    sandboxing is a secondary goal that built off of much of the structure that needed to exist to distribute packages in the first place.

    Sandboxing is not a secondary goal, the permission system and creation of portals proves that this is in fact, an important goal for the project.

    To be frank, I don't think the sandbox is good enough to warrant calling it a primary goal.

    This is literally FUD.

    Let's go through it quickly :

    The sandbox is STILL a lie

    Read the permissions and modify them as you wish. It's still a major improvement compared to traditional packaging. The goal is to remove all those permissions over time as people transition to portals more and more but for now, certain programs don't make sense without those permissions. It's not hard to modify the permissions either, you can use Flatseal.

    Flatpak apps and runtimes STILL contain long known security holes

    So like basically all distribution models. Completely useless commentary. This is not a flatpak bug, this is a flathub and packaging software bug.

  12. Comment on What should a lay user know about Linux app packaging? in ~tech

    lionirdeadman
    Link Parent
    No. The AUR does not solve Linux fragmentation nor does it have "all the software". Software compatibility is not being solved on the AUR. If the package requires old libraries or specific...

    No.

    The AUR does not solve Linux fragmentation nor does it have "all the software". Software compatibility is not being solved on the AUR. If the package requires old libraries or specific versions of software, you're screwed.

    From the perspective of a app developer, the AUR will screw you over. You may not want to support every distro and fix tons and tons of distro-specific bugs but I guess forcing them to do so is a "solution".

    There's also moments where the AUR just ships broken shit. For example, the "Authenticator" application was packaged for the AUR but it's broken because it requires patches on top of GStreamer and the package maintainer doesn't want to do it. Who gets the blame? The application developer. This is hostile to developers.

    Furthermore, no, security was not a secondary goal. It is core to the design. You don't accidentally create a sandboxing system and permission system and push for dynamic permissions like portals if it was never your goal.

    People deserve to be able to protect their files, to be secure, to be able to have newer software than your distribution supports. Developers deserve to not have to fix tons of distro bugs they never intended to support.

    2 votes
  13. Comment on What should a lay user know about Linux app packaging? in ~tech

    lionirdeadman
    Link Parent
    As knocklessmonster says, this is not about the binaries. This is about Free Software ideals and power. People want to be able to run their own repositories if they want to. People want to not...

    As knocklessmonster says, this is not about the binaries.

    This is about Free Software ideals and power. People want to be able to run their own repositories if they want to. People want to not rely on a specific company for their package to survive and for the time they invest in the technology. People want to hack on the code to improve things.

    For people who believe in Free Software, this is never going to be acceptable and for most if not all distributions, this is a threat of corporate takeover.

    1 vote
  14. Comment on What should a lay user know about Linux app packaging? in ~tech

    lionirdeadman
    Link Parent
    Flatpaks are not a response to the AUR at all nor are they made for Fedora or Debian. Flatpaks are a response to Linux fragmentation and security concerns. They're made to distribute once, for...

    Flatpaks are a Debian / Fedora answer to not having a distribution model like Arch, with some sandboxing thrown in.

    Flatpaks are not a response to the AUR at all nor are they made for Fedora or Debian. Flatpaks are a response to Linux fragmentation and security concerns. They're made to distribute once, for everyone.

    2 votes
  15. Comment on Microsoft enables Linux GUI apps on Windows 10 for developers in ~tech

    lionirdeadman
    Link Parent
    For Free Software project and people who want a very specific piece of software, maybe, but I don't think the mainstream cares about Evince or any of the projects which don't do Windows anymore....

    For Free Software project and people who want a very specific piece of software, maybe, but I don't think the mainstream cares about Evince or any of the projects which don't do Windows anymore. They'll just another piece of software that accomplishes their needs.

    For commercial interests, they'll never do that. Giving people a lot of work to setup your program is not something a lot of people want to do.

  16. Comment on Microsoft enables Linux GUI apps on Windows 10 for developers in ~tech

    lionirdeadman
    Link Parent
    Until I see them integrate programs running in WSL2 in their store or something of the like, I don't believe this will happen outside of the enterprise. Telling people to setup WSL2 for your...

    If anything, I think that this goal they are working towards will make developers drop support for the Windows versions of their applications, since users will be able to run the Linux versions directly

    Until I see them integrate programs running in WSL2 in their store or something of the like, I don't believe this will happen outside of the enterprise. Telling people to setup WSL2 for your program is too high a barrier at the moment. I do think that would be very cool though.

    1 vote
  17. Comment on Microsoft enables Linux GUI apps on Windows 10 for developers in ~tech

    lionirdeadman
    Link Parent
    Does .NET core even integrate well with Visual Studio? There's nothing stopping people from making IDEs which support .NET core. I don't know if I agree with this logic.

    You do .NET development? Eventually you're going to want full Visual Studio, which costs big bucks, only runs on Windows.

    Does .NET core even integrate well with Visual Studio? There's nothing stopping people from making IDEs which support .NET core. I don't know if I agree with this logic.

    1 vote
  18. Comment on Microsoft enables Linux GUI apps on Windows 10 for developers in ~tech

    lionirdeadman
    Link Parent
    While I am scared of that acquisition, I don't think Red Hat will succumb to IBM. It seems that IBM wants to change its company culture. They even put the founder and ex-CEO of Red Hat as IBM...

    IBM is still IBM...my employer is currently exploring alternatives to RedHat because of that acquisition.

    While I am scared of that acquisition, I don't think Red Hat will succumb to IBM. It seems that IBM wants to change its company culture. They even put the founder and ex-CEO of Red Hat as IBM president. For the moment, I've not seen anything that would indicate Red Hat's downfall.

    2 votes
  19. Comment on Microsoft enables Linux GUI apps on Windows 10 for developers in ~tech

    lionirdeadman
    Link Parent
    They are working on DX12 on WSL2 iirc. The mesa driver for it essentially just pushes the dx12 calls to the host so it doesn't benefit Linux in that way. I don't think that this would enable...

    Extinguish - Windows only utilities? Proprietary codecs? Gotcha tricks and "bugs" and "workarounds? All of this and more once devs decide Windows is best of both worlds and they can't change? Watch this space.

    They are working on DX12 on WSL2 iirc. The mesa driver for it essentially just pushes the dx12 calls to the host so it doesn't benefit Linux in that way. I don't think that this would enable extinguishing, if anything, it makes them more reliant on Linux as a guest.

    3 votes
  20. Comment on What should a lay user know about Linux app packaging? in ~tech

    lionirdeadman
    Link
    IMO, the important parts are capabilities and trust. Distro packages : Likely no delta updates (DNF has them, I'm not sure if apt does) Only runs on the distro Doesn't offer sandboxing for better...

    IMO, the important parts are capabilities and trust.

    Distro packages :

    • Likely no delta updates (DNF has them, I'm not sure if apt does)
    • Only runs on the distro
    • Doesn't offer sandboxing for better security
    • You have to trust them otherwise your system is compromised already
    • May require a system reboot to properly use the package because moving libraries from under apps may result in bugs

    Flatpak :

    • Has delta updates so updates are less bandwidth expensive
    • Runs on essentially any distro
    • Offers sandboxing OOTB and pushes for more dynamic permissions to replace the static ones that can be configured
    • As it doesn't use system libraries, a restart is all you need to benefit from an update with no risk
    • Release schedule is much more flexible
    • May not have access to everything (/proc for example is not available), the default configuration may be too restrictive to someone's taste but that can be overridden
    • Trust is based on the repository, I would recommend always looking at the permissions.

    Snaps :

    • Relies on AppArmor for sandboxing, this means anything outside of Ubuntu, Debian and SUSE has sandboxing issues
    • It may require changes on the system so it's not truly distro agnostic
    • uses Loop devices which will affect application performance
    • The Snap store is proprietary and solely owned by Canonical
    • You have to trust Canonical

    AppImage :

    • No sandboxing at all
    • No delta updates
    • No central update mechanism
    • Not truly distro agnostic as it may require system libraries
    • You have to trust the packager of the AppImage

    So with these facts in mind, I personally much prefer Flatpak, I think it's the future of Linux packaging. If not available or possible within the restrictions (for example, a system library or terminal utility), I'd go for distro packages. I avoid snaps and appimages at all cost.

    13 votes