[HN Gopher] Debian KDE: Right Linux distribution for professiona...
___________________________________________________________________
Debian KDE: Right Linux distribution for professional digital
painting in 2024
Author : abhinavk
Score : 137 points
Date : 2024-05-31 10:32 UTC (12 hours ago)
(HTM) web link (www.davidrevoy.com)
(TXT) w3m dump (www.davidrevoy.com)
| cies wrote:
| At this point I have only one app in XWayland (IntelliJ) and they
| are working on native Wayland support. I hope soon we cross the
| point where everyone is better off on Wayland.
|
| I'm quite glad it works for me now, and I feel bad for everyone
| who's usecase is not yet catered for.
| iamjackg wrote:
| I just got a Framework 16, installed Ubuntu 24.04 on it, and
| have been going through this exact struggle after avoiding it
| for many years. The screen DPI is just high enough that it's
| uncomfortable for me to use at 100% scale, so I set it to 125%,
| but any non-Wayland application would get artificially resized
| and look blurry.
|
| There's a pending Mutter MR[1] to allow XWayland applications
| to handle the scaling themselves (which IntelliJ IDEs can do)
| but it hasn't been merged yet, and I'm probably never gonna see
| it on 24.04 anyway. Apparently KDE already supports this, but
| the Gnome folks have been reluctant to adopt the same approach.
|
| I ended up going back to 100% scaling, increasing the system
| font size, and then setting `GDK_DPI_SCALE=1.25` in
| `/etc/environment` to tell all GTK programs to increase their
| scale. It's not perfect, but most things are the right size. I
| definitely would not have wanted to switch to Wayland any
| sooner than this though. Transitional periods are such a pain.
|
| [1]:
| https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3567
| spyridonas wrote:
| The new 13 laptop has a resolution that allows for 200% scale
| exactly!
| freedomben wrote:
| Dang, now I want one! I already have two of the 13s (11th
| and 13th gen Intel), plus a new 16 with GPU (which I
| absolutely adore btw) though and can't possibly justify
| such extravagance.
|
| Love that they're fixing the screen though. It's fine for
| me since I solved it the first time, but it's hard for most
| people at first. I just enabled "Large Text" in Gnome's
| accessibility menu and that gets it pretty good. If you
| want to really hone it in though, enable fractional
| scaling[1] and then tweak the scaling factor.
|
| What I do after a fresh install (with Fedora but should
| work with most any new-ish Gnome):
|
| [1]: `gsettings set org.gnome.mutter experimental-features
| "['scale-monitor-framebuffer']"`
| cies wrote:
| Here you can see the work being done on IntelliJ Wayland:
|
| https://github.com/JetBrains/JetBrainsRuntime/issues/242
|
| https://youtrack.jetbrains.com/issue/JBR-3206/Native-
| Wayland...
| iamjackg wrote:
| I saw that, very excited for it and hope it lands soon!
| toenail wrote:
| Interesting guide. I wasn't aware Wayland still had such
| shortcomings even for graphics professionals.
|
| > It's now up to each desktop environment project (e.g. GNOME or
| KDE Plasma) to develop their own full featured GUI for tablet
| configuration.
|
| That doesn't sound ideal.
| janosdebugs wrote:
| I had to switch back to X11 because both nVidia and nouveau
| would produce around 5 fps on my A2000 RTX on multiple distros.
| This is just for basic usage, not even painting-related.
| mjevans wrote:
| Wayland also doesn't have a video capture interface as part of
| the standard. E.G. for Remote Desktop style applications (you
| might even use such if part of a video conference). Instead
| that's left up to the compositors, and therefore potentially
| not supported or possibly every compositor could have their own
| standard.
|
| https://wayland.freedesktop.org/faq.html#heading_toc_j_8
| tombert wrote:
| I would like to move back to Linux (specifically NixOS), but
| I've held back because support on the T2 Macs is pretty bad
| still, and Apple is still providing updates to them for now.
|
| When I tried installing Linux on there, I had a ton of trouble
| getting Wayland to work in any capacity (it was very glitchy
| when I tried), and I had to go back to X, before nuking the
| Linux install and going back to macOS.
| exe34 wrote:
| did you have any problems specifically with X? It's worked
| flawlessly for my entire adult life, and a decade ago they
| made it so magical I didn't even have to write a config
| anymore. I think they will have to pry X from my cold dead
| silicon at this point.
| tombert wrote:
| No, not really, I just wanted to play with the shiny new
| Wayland stuff. Also I like the Sway window manager, I think
| more than i3? Obviously they're both pretty comparable.
| Rinzler89 wrote:
| _> did you have any problems specifically with X?_
|
| Every recent time I would daily drive Linux (Ubuntu and
| Antix) I had screen tearing out of the box. Not really an
| acceptable feature.
| guilhas wrote:
| Just go to github and search issues with 'Wayland support'
|
| I think is more probable that anyone will have a problem in
| Wayland than X
| Rinzler89 wrote:
| As much as the "Wayland is now ready since it's the default
| on big distros" meme goes, it's not _really_ ready if you 're
| having issues with it.
|
| Ready means if everything is flawless to MacOS/Windows
| levels, where you never have to think about display server
| compatibility, and that's where X11 is still king despite the
| performance shortcomings. At least it always just works(tm)
| and compatibility beats performance most of the days.
| blacksmith_tb wrote:
| That feels like a high bar for FOSS (maybe for any
| software...), but given how long Wayland has been getting
| worked on, you'd hope it's at least usable for most (but
| not digital painters, apparently).
| Rinzler89 wrote:
| Keep in mind Wayland has been worked on since 2008 when I
| was still in school. I think some young HN readers
| haven't even been born yet.
|
| I could excuse it if it had been 4 years old or so, but
| it's old enough already it can drink and smoke in Europe.
| exe34 wrote:
| Wayland is now way older than Xorg was when they decided
| that it needed re-inventing.
| Rinzler89 wrote:
| Fun fact, GTA Vice City is now further away (22 years)
| from its 2002 launch date than it was from its story
| setting of 1986 (16 years).
|
| If that game were to be launched today and feature a
| setting in the same time delta, it would be set in 2008
| when movies like The Dark Knight or the first Iron Man
| launched.
|
| How time flies.
| exe34 wrote:
| I remember the nineties when 30 years ago was the 60s.
| now 30 years ago is my flipping childhood.
| Rinzler89 wrote:
| So when you were a child, a 1969 Mustang was a "clasic
| car", but now an equivalent classic car would be a fourth
| gen Honda Civic that your local weed dealer drives.
| exe34 wrote:
| thank goodness I don't know what any of that means, I was
| never into cars!
| aidenn0 wrote:
| Maybe more a Camero IROC-Z?
| triblemaster wrote:
| Way-not-gonna-land as someone said some years ago. :-P I'm
| using Wayland for my work now for two years now, and it has
| been amazing. But then, I rarely do any graphics work.
| fngjdflmdflg wrote:
| Wayland is flawless for what it claims to do. The issue is you
| can't replace X Org with Wayland, you can only use Wayland
| combined with other software to replace X Org. This is the
| biggest issue with Wayland: "Wayland is a replacement for the X11
| window system protocol,"[0] but you can't actually replace x11
| with it. What they should have done is make sure all the features
| that x11 had were supported by Wayland. By this I mean user
| facing features like copy-paste and color management. (And if
| someone thinks copy paste is not secure or whatever, let there be
| a flag to disable it or something). But instead they wrote a
| specification that when implemented replaces 90% (lets say) of
| X11. And since there are multiple implementations of the Wayland
| server you cannot rely on the other 10% to be present on any
| given server. If they had not written a specification and just
| released x12, or if they sanctioned only one specification, or if
| they had added more features to the specification then the there
| would be no problem. They still have room to add more features to
| the specification which I hope they do.
|
| [0] https://wayland.freedesktop.org/
| rasengan wrote:
| This will introduce its own problems though, for example, X11 is
| insecure.
| cardanome wrote:
| I don't get why parts of the Linux community are so resistant to
| embrace AppImages and provide first class integration for them.
| Decent desktop integration isn't that hard.
|
| As a user I want to download the thing and run it. AppImages
| provide that.
|
| As an app developer I want to create one single package that
| works everywhere that users can just download. AppImages provide
| that.
|
| Snap and Flatpacks are solving problems that don't need solving
| for most people. Shitty sandboxing that doesn't even work and
| makes my app slower? I don't want it.
|
| Most software is best installed by the native package manager.
| For the few exception AppImages are perfects.
| triblemaster wrote:
| I disagree with you in that, only system software should be
| installed by the native package manager. Everything else should
| be AppImages.
| marcosdumay wrote:
| What is "system software"?
| red_trumpet wrote:
| What's the update story for AppImages? AFAIU you have to
| download updates by hand?
| cardanome wrote:
| Yes. Things that are critical to update regularly should be
| handled by the package manager.
|
| I use AppImages when I want a specific version of a specific
| app. I never want them to be automatically updated because
| doing so might introduce breaking changes that might mess
| with my workflow. Imagine complex software like Blender or
| Krita updating automatically while you working on a specific
| project, possibly even breaking your saves, absolute horror.
| freedomben wrote:
| There aren't centralized solutions that I know of, but there
| are projects such as AppImageLauncher[1] that can provide
| some automated management of that. It's not perfect but it is
| helpful.
|
| [1]: https://github.com/TheAssassin/AppImageLauncher
| c-hendricks wrote:
| Updating app images are solved if a few ways:
| https://docs.appimage.org/packaging-
| guide/optional/updates.h...
| throwaway38405 wrote:
| The Linux community is self-selected and highly opinionated on
| everything.
|
| Concerning AppImages: I have no interest at all in them and
| although Flatpak still has its share of problems, basically all
| important communities adopted it (but Ubuntu).
|
| Flatpak integrates in your system, has sandboxes, has automatic
| updates, shares dependencies etc.
|
| Is Flatpak perfect or running w/o problems? Certainly not.
|
| But IMHO AppImages add nothing over Flatpak, but lack the
| unified infrastructure and integration into packet managers
| etc.
|
| We all would benefit from agreeing on one standard, and by now
| it looks like Flatpak is that one standard. So, I don't want to
| download random AppImages from the internet, I want a certified
| Flatpak which integrates with my system.
|
| (Being a member of the Linux community for longer than most
| people using Linux are alive by now, of course and invetible,
| once Flatpak is working and established, it will be replaced by
| some broken other solution. :-P)
| freedomben wrote:
| I likewise love AppImages and wish more projects used them, but
| I also love Flatpak. The downside of Flatpak is the overhead it
| takes to learn what it does, how it works, and how to manage
| them. If you already know container stuff like docker/podman
| then it isn't too bad, but it's a non-zero cost and friction.
|
| I think most people don't like AppImages mostly because they
| don't provide any sandboxing. I think that's a silly reason
| myself, but I'm also an old, and us olds aren't terrified of
| using our computers like the youngs seem to be ;-). Though,
| other OSes are getting sandboxing for applications and Linux
| needs to not get left behind, so I'm glad it's being solved.
|
| I also think fragmentation is a (valid) reason people dislike
| AppImage also. It's nothing wrong with AppImage specifically,
| but that its existence harms adoption of Flatpak by making it
| easy for people to not use Flatpak. Personally I see them
| occupying different niches. I use App Images for things like
| Kdenlive, Logseq, Upscayl, and UHK Agent. Those could all be
| Flatpaks, but developer effort matters. If devs provide an App
| Image build I think we should be praising them from the
| rooftops for caring about Linux!
|
| Another reason is that it clashes with immutable OSes like
| Fedora Silverblue or SteamOS that are heavily container-based.
|
| What I'd love to see is a tool that takes an App Image and
| automatically builds it into a Flatpak (possibly with
| predefined metadata). Flathub could easily be populated this
| way so that it's easy for developers/distributors to package
| and ship, but also Flatpak is the standard.
| giancarlostoro wrote:
| Literally this. One thing both Apple and Windows have that
| Linux does not is, every software has an easy universal package
| for their respective platform. For Linux if its even in your
| main package manager its like whatever was "stable" in 2022 or
| whenever the last major version of Debian / Ubuntu came out,
| and that's all you get. It's annoying to no end. I now just
| download AppImage every chance I get.
| throwaway38405 wrote:
| ... sorry, this sounds to good to be true.
|
| Usually it works like this (forced to use macOS at work and
| Windows from time to time for special software): One installs
| some software from trusted websites (VSCode, VLC, Firefox,
| etc.) on macOS/Windows, and then when one just wants to get
| some work done: Update-PopUps, yay. They annoy the hell out
| of me, especially because there is no unified system for
| macOS/Windows. Break my flow, wait for download, privilege
| escalation, installation and starting again. Thank you very
| much. This happens multiple times a week especially for
| packages like VSCode, VLC, Office, Outlook, Firefox,
| KeepassX, Calibre... packages which you don't want to be
| outdated, ever. It is f*cking ridiculous that I have to take
| care of this BS in 2024.
|
| On my Linux boxes I login and work. Updates have been
| silently downloaded and installed for the packages and/or
| flatpaks and everything is up to date, no annoying update-
| popups which break my flow and I know that I have the latest
| version of all software especially security sensitive
| packages.
|
| At the end, you can pick your poison.
|
| Having integrated/working package management with silent
| updates is one of my killer features of Linux/Flatpak. I want
| to set it up one time (automatically) and never have to think
| about or deal with it again.
| _factor wrote:
| When combined with Flatseal as an easy to use privilege
| granting system, it really is hard to beat.
| jbstack wrote:
| Unless something has drastically changed since I switched to
| Linux around 10 years ago, Windows did not at all have a
| "universal package". Instead, installing software meant
| manually downloading an installer from the vendor's website
| and then manually interacting with that installer through a
| GUI. Windows installers come in a variety of different (even
| custom written) formats which essentially make it impossible
| to automate package management in a universal way.
| guilhas wrote:
| Although I like appimages more compared with flatpack and snap
|
| I think they are all worse than the other packaging methods
|
| With a NixOS configuration I can install almost all software I
| use in a single command
|
| Even in window I mostly use scoop/chocolatey
| mid-kid wrote:
| While I'd love to see good tooling for AppImages appear, it's
| just not made for it.
|
| The fundamental problem is that AppImages are literally just an
| archive with a bunch of files in them, including libraries and
| other expected system files. These files have to be selected by
| the developer. It's _really_ hard to tell which libraries can
| be expected to exist on every distribution, which libraries you
| can bundle and which ones you absolutely cannot due to
| dependence on some system component you can 't bundle either,
| or things like mesa/graphics drivers. There's tools to help
| developers with this, "linuxdeploy" is one, but they're not
| perfect. _Every single_ AppImage tutorial will tell you: Test
| the AppImage on every distribution you intend this to run on.
|
| At the end of the day, this situation burdens both the
| developer (have I tested every distribution my users will use?
| both LTS and non-LTS?) as well as the user (what is this weird
| error? why isn't it working on _my_ system?), and even if this
| all somehow works, newer versions of distributions are not
| guaranteed to work.
|
| Flatpak, for all its bells and whistles, at least provides one
| universal guarantee: Whatever the developer tests, is exactly
| what the user will experience. I think this is a problem that
| needed solving for many people.
|
| ...it hurts a lot to say this as a longtime flatpak avoider,
| still always prefer distribution packaging, but I've come to
| accept that there's a genuine utility to flatpak, if only to
| cover for letting users test different versions of software
| easily, and similar situations that distributions just cannot
| facilitate no matter how fancy their package manager.
| threePointFive wrote:
| AppImage is a good distribution format, but IMO is not
| comparable to your system's package manager or Flatpak for that
| matter. For starters, when you downloads an AppImage, you are
| just getting the binary. Documentation, Desktop and Service
| files, and update tracking are all things that are missing from
| a vanilla AppImage deployment that your system package manager
| always provides (Flatpak and Snap only handle some of those
| sometimes).
|
| The missing piece is perhaps some sort of AppImage installer
| which can be registered as the handler for the AppImage
| filetype. When ran it could read metadata (packaged as part of
| the AppImage?) and generate the support files. Ideally would
| also maintain a database of changes to be rolled back on
| uninstall and provide a PackageKit or AppStream provider to
| manage updates with your DE's store.
|
| Now none of that addresses dependency duplication, but thats
| clearly not in scope for AppImage.
| eikenberry wrote:
| IMO AppImage fell short by not requiring upgrading support in
| all appimages. I don't want to have to monitor random sites for
| updates to my applications. So after trying to use them for a
| time I moved on. Currently experimenting with both flox and
| flatpaks as they both handle this aspect reasonably.
| hamandcheese wrote:
| Personally I dislike AppImages, Snap, Flatpack, Docker, etc.
| for one main reason:
|
| If an app is so hard to distribute in any other way, that to me
| is a red flag that the app is not up to my quality standards or
| otherwise violates my sensibilities in some way. On my Linux
| desktop, I am very much in the camp of "that which exists
| without my knowledge exists without my consent".
|
| (I fully recognize that I am extreme outlier in general, and
| perhaps a slight outlier among Linux users. Just offering one
| perspective, I make no claims that this it the correct
| perspective for most Linux users.)
| burningChrome wrote:
| >> Snap and Flatpacks are solving problems that don't need
| solving for most people. Shitty sandboxing that doesn't even
| work and makes my app slower? I don't want it.
|
| After using Ubuntu for years, this change made myself and many
| others I know switch. I've been on MX for the past two years
| and love it.
| Eduard wrote:
| what is MX?
___________________________________________________________________
(page generated 2024-05-31 23:00 UTC)