I’m here to stay.
This would complicate the code behind Inkscape and the user interface a lot. It’s not just having an option to enable raster editing, the entire program must be rewritten, because its not designed to do raster editing. If they started with raster editing, it would be lacking too and the horrors from users would never end. I rather want Inkscape stay focused to what its doing best.
Either use GIMP or Krita. There are already excellent or good enough image editing tools.
AMD is ruining Intel.
Two nogos combined makes nonogogos. Why do they need host name, MAC address and disk serial numbers? Why can’t people set how much they want to send in, like KDE Plasma does? Will the data be shown to the user before its send in? Steam does that perfectly (show data and its opt-in) and that is even a proprietary application. Telemetry is okay if its done right, without user identification, opt-in and not hiding whats sent, preferably in multiple levels of what is being send.
I used Manjaro before and switched to EndeavorOS because I was not happy. Now I am. Manjaro can’t stop being stupid (not the users, I’m not attacking any user here, only the maintainers or developers of Manjaro).
I have RX 7600 on EndeavourOS. The installation is 2 years old or so, so I don’t remember everything. Normally for gaming you don’t need any extra packages, because Mesa (which contains the Open Source AMD GPU drivers) is in the Kernel. Usually that’s all you need for gaming. However I do have installed some vulkan related packages. The package info says this is required by steam, so you might have it already. yay -Qi vulkan-radeon to see your information about the current installed package (which tells me what installed package requires it) or lookup from repository with yay -Si vulkan-radeon. You can read more here: https://wiki.archlinux.org/title/AMDGPU
I always recommend people learning by doing. But playing around with system tools to see and learn how it works is a bit risky. However in a virtual machine this is probably a good idea to see how things work.
The official website has ton of documentation and external links: https://systemd.io/
And here some tutorials:
Serious answer? XFCE doesn’t support multiple monitors with different refresh rates. So that.
That’s more of a limiation because of X11. KDE and Gnome do not support different refreshrates on multiple monitors as far as I know. Its the main reason why I never used multiple monitors. But on Wayland, this issue is solved. So if XFCE is ported to Wayland, they should also get this support for free I guess.
Technically he or she has access to the AUR, but through website.^^ On a more serious note, one could install https://github.com/89luca89/distrobox and manager multiple package managers. Because each package manager is in a container, they do not interfere. I never used it, but imagine it like Flatpak, but actually using the package manager from the distribution (including access to AUR). And specific applications and programs can be “exported” to install them like a normal application, so you can access it with a single appname.
Not all new users should be treated the same. There are technical new users and those who don’t care the technical details or updates. Arch based distributions are good for new users too, especially if we are talking about gaming. WE shouldn’t treat every new users like it they are the dumbest people on earth (generally speaking). Instead these blind recommendations, we should talk with the new users what type of user they are, what they want and what they are willing to do. We should utilize the strength of Linux instead just recommending the same distribution all again.
/rant over
Are you sure we are talking about the same thing. I’m not talking about an universal Bluetooth adapter? The official Wireless Adapter from Microsoft uses a proprietary driver. Xpadneo supports only Bluetooth (as stated in the Github, unless I misunderstand something). To use the official Microsoft dongle xone is needed. The Xbox One S controller supports both, Bluetooth and Proprietary drivers.
Xpadneo only supports Bluetooth, not the official wireless adapter.
Or install the working fork instead: https://github.com/dlundqvist/xone
Short: xone driver fork
Long:
I use Xbox controllers for years on Linux. And my current one is Xbox One S controller with the official Microsoft dongle (not Bluetooth, but the proprietary connection). Linux does not support this driver, but there is a community driver: https://github.com/medusalix/xone And for whatever reason the newest Linux Kernel 6.11 and upwards broke this driver. That means this driver does not work on Linux Kernel 6.11 or newer, until it is patched. And I believe Fedora 41 ships with 6.11. But wait! There is an alternative fork that fixed the driver: https://github.com/dlundqvist/xone You only need to install this one.
Why is it that complicated in Linux? That’s because the Microsoft driver and dongle are proprietary and do not provide an official driver for Linux. Look it this way instead being complicated: It still works, because of the awesome community! Some people prefer using the Bluetooth connection. I personally don’t like Bluetooth in general for any device. So cannot assist with that.
EDIT: Alternative way with xpadneo. Apparently this works too with the official wireless dongle from Microsoft: https://beehaw.org/comment/4056781 The installation might be more involved.
Maybe you are right. Its something I repeat it myself, after doing a research back when it was new. Given Neovim is available on Flathub, maybe its possible. Maybe it was true at some point. Good catch, I’ll make sure not to repeat that anymore, as I don’t want spread misinformation.
I don’t like Snap too, but it has some advantages over Flatpak. And unfortunately the most popular distribution still uses Snap. In example it is easier to create Snap packages and Flatpak does not support CLI only applicatoins ( Edit: my bad ) , but Snap does (something like grep in example). Also some may like it more that Snap relies on AppArmor instead using the custom solution of Flatpak.
All in all, its not like black and white which is better. I still wish only one of the formats would exist, because this is not the kind of fragmentation I wish to have. But both exist and the end user should decide which of them to kill.
Not all. Red Hat started this by naming their immutable distributions with “atomic” (but then not consistently…). Some people agreed, but not everyone.
Immutable does not mean “not changing”, but rather that you don’t have the rights to change. If you take the immutable option away, then its changing again, like when you update your system. People who have a problem with the term say, “see its not immutable, the term is a lie!”. Which I kind of agree, but somewhat conflicted.
Atomic is an attempt to create a new “meaning” with a word, that cannot be misunderstood. Its trying to avoid the situation of “Free” in example. But I don’t like the term Atomic either, because it just suggest to me that everything is split into many little parts and is not self explanatory like Immutable. I’m conflicted here too.
I’m always conflicted.
deleted by creator
Said the person who maintains Hyprland. This post reads like an ad for his own project.
Isn’t this the toxic dev, who dislikes any other Wayland Compositors? This guy is also banned from contributing to Freedesktop here and here. And here is a post from Drew Hyprland is a toxic community.
I’m not surprised about this blog post. I argue we need more compositors. More means, more to choose from and being less reliant on the few that are available right now. What if someone does not like Hyprland in example or any of the current available compositors? Having more to choose from is a good thing, not bad. I’m so thankful that Hyprland is not the only one we have. One example is the programming language that the project is written in. Why does it matter? Maybe because people want to contribute or understand the code or want to make changes. In example Qtile is written in Python and its configuration language is in Python too.