Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's awesome that the Linux version is distributed right on the website as an AppImage next to the Windows and MacOS downloads. I very much appreciate software that doesn't require me to wait for a third party maintainer to get around to building it for every distro or require me to add a new repo to a config file somewhere just to use the latest version.


I've become a big fan of AppImages. I found a project on Github called AppImageInstaller which will create a Gnome/KDE integration shortcut for you and move the AppImage file to a "programs" directory of your choosing.

I usually just "Open with AppImageInstaller" when I download them, it pops up and asks if you want to run once or integrate. When you get a new version you can right-click the old one's shortcut/icon and AppImageInstaller's integration give you a "remove from system" type option.

I use Cura as an AppImage, FreeCAD, Lens (Kubernetes "IDE") Zettlr, and a few others as AppImages. It's really clean and convenient.

It really upsets me when I find tools I want only have snaps, because like any sane person, I kill snapd the second I install an Ubuntu system (Laptops) and I run Manjaro on my desktop so snapd isn't going anywhere near it.


I think Plasma automatically integrates AppImages on the first time you launch one.


Interesting, I'll have to see whether I really need the AppImageInstaller on my desktop then. Thanks for the note.


You are in the target group for Arch Linux. Highly recommended.


Not if you want to run more versions side by side including betas, if you are a professional you don;t update your tools mid-project and pray it will be fine.


That's what Nix(OS) is for :)


Great, so I'll just go ahead and learn a new language just to install software, that's totally reasonable.


You don't really need to do that though. You can also use nix-env to install software.


[flagged]


In fact, I think Linux's package management is too inflexible. You always need to wait for maintainer to package it for you, and it is not as fast as upstream. To have multiple version of a same package usually require to compile yourself, use a PPA or download a package and install it. Compiling a software not always easy, and it takes times. The PPA and install a random package from Internet isn't really securer than Windows's way of software distribution IMO.


Linux has the advantage of many choices so you can use what fits you best.

If your hardware has good Linux drivers and if the software you need has a Linux version then IMO you can find a distribution that will match your needs. Arch could be great for some people but an LTS will be more popular with other people. For example in my case I use Intellij for work and it comes in a tar.gz file format that I can use and I can keep the old version around when updating. The only time I compiled things was when I modified stuff to add my own changes to open source software.

If you are gaming I think you should still use Windows or a console, even some will claim Proton works with most games the experience can be frustrating with many of the games that are claimed to work.


Which is why I use Windows much more than Linux despite in principle preferring FOSS. It's a shame the Linux Desktop community is so hostile to criticism, otherwise maybe I could use Linux more.


The specific criticism I think that generates the hostility you're experiencing is something like "Linux should be easier to use / easy to use for the everyday computer user". In general I think most people would agree with you, but it comes across as an ignorant comment given the well-known economics; and especially in the context of a conversation about someone who is unwilling to contribute or at least build their own software.


Where am I saying that? I have a specific criticism, that package management is unnecessary complexity that introduces more problems and limitations than it solves. It has nothing to do with being easy.

> but it comes across as an ignorant comment given the well-known economics

What the fuck does economics have to do with it?

> and especially in the context of a conversation about someone who is unwilling to contribute or at least build their own software.

I do both of those things. Your condescending conclusion otherwise is emblematic of my problems with Linux Desktop as a community.


Why didn't you just build Krita and then come here to leave some relevant feedback instead of complain about package management in general?


Because I didn't have to build Krita myself just to use it, and I appreciate that fact and wanted mention it.


Consider: it's not that Linux users are hostile to criticism, it's that your criticism is of the laziest, least-intelligent part of the spectrum of criticism.


While Nix is great - don't forget the venerable portage :-)


Self contained apps like app images and .tar.gz also work most of the time.


I don't see how. Arch still heavily relies on a repo and volunteer package maintainers.


Arch's Krita was updated to 4.4.0-4 at 2020-10-13 18:23 UTC, approximately 18 hours and 52 minutes ago.

While I can't see when the original blog post was submitted, I know this forum post was posted 2 hours ago. Are you sure you would benefit from updating even faster?

EDIT: In any case, you could use the AUR package that points directly to the git repo.


Would the AUR let me have the current Krita and the old one installed simultaneously? My experience with repo/package models suggests it very much would not.


I don't think so. It should be possible to install the older version in different prefix (e.g. `./configure --prefix=/opt`) but I don't think AUR supports multiple slots (like portage does) out of the box.

My cursory search on the interweb did not yield any promising results on the Arch wiki either. Happy to be corrected, of course.


> Would the AUR let me have the current Krita and the old one installed simultaneously?

I doubt it.

> My experience with repo/package models suggests it very much would not.

The Nix package manager would. However, I have no idea if their packages are kept up-to-date like that.


If you comment out that your aur build provides and conflicts with krita and install it under /usr/local or some such you can do parallel installs.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: