I wasn’t having many issues to begin with, but with the introduction of explicit sync into Kwin, and driver improvements throughout the 555 beta series, it’s been just about perfect for me.
The only issue i’ve encountered so far is the panel freezing sometimes. Submit a bug report to both KDE and Nvidia, they’re working on it.
Is there a DE with an onscreen keyboard that can be used in the terminal?
The onscreen keyboard used with Plasma (steam deck as well) is missing CTRL and other keys needed when navigating a terminal. It also fails to pop up on electron apps.
I don’t use VRR, but I meet the rest of your criteria Electron apps were the biggest pain pont - I will be typing in discord and there was noticeable lag and letters would disappear until I have several characters beyond them. I worked around this by using discord on their website in a browser tab.
Not sure which update resolved this, but it’s now working as I expect it to, so I think if you choose to use a Nvidia GPU, you should have an okay time. I would just say to consider a beefier AMD GPU as well, since they tend to have much better driver support in Linux
Using free software to create free software is already a good reason.
But if you need more:
owned by Microsoft, it is a US-based megacorporate product with value to deliver to shareholders first
never forget EEE as we see a new form of it with Microsoft trying to control the entire developer experience from the server hosting to the editor/AI on folks’ machines; under-litigation Copilot is a straight exploitation of the Commons selling our hardwork back to us
proprietary means you can’t fork or fix the numerous bugs in the platform nor is there a real issue tracker so you beg on their forums for fixes (anti-free software mentality)
lock-in issues since aside from specifically the Git part, every one of those proprietary features you buy into will dig a further trench to make it hard to migrate elsewhere
yes, privacy benefits of not just you but all potential contributors as well since it is a locked ecosystem that requires an account
not everyone thinks software forges should double as a social media platform with upvotes, FOMO, commit anxiety with employers imploring you have metrics on a closed platform with knock-on issues like star-hacking where projects try to inflate their star numbers in this popularity contest instead of judging projects on merit
related, the README used to be a file you could read without rendering but now instead they are full of trash markup, emoji, & the repository is filled with binary blobs of images or worse videos for your demo ballooing cloning all wrapped in a Microsoft UI not your own; setting up a separate site isn’t hard (nor is it easy either) but at least you get to own your look & keep assets out of your repository
there are literally ads & upsells all over the platform
you can’t use search or see the collapsed comments without authentication
censorship is not uncommon–especially when it mess with the corporate status quo (see Nintendo Switch emulator dev, youtube-dl, etc.)
being US-based & big enough for scrutiny, MS GitHub is required to follow US sanctions which prohibit some of your potential users/contributors from even accessing your code (and/or issue tracker and/or forum and/or wiki and/or donations if using MS GitHub)
…& there already is a host of good alternatives out there for code forges with better performance & features, some of them aren’t locked to Git either; ‘network effect’ be damned
So, everything you mentioned are reasons I’ve heard for people to switch from GitHub to GitLab, which is why I explicitly mentioned them both in the question.
So far no one has given me any advantage specific to codeberg. (Keeping in mind that GitLab is already open source, self-hosted, and federated via ActivityPub).
Well, if you’re self-hosting GitLab, there might not be much of a difference. Codeberg is hosted by a non-profit organization, so you don’t have to self-host it.
The open-source software that it uses, Forgejo, is also more so developed by the community, rather than just one corporation, who could change the license for future updates at any point.
If ForgeFed gets up & running you should be able to self-host your own compatible VCS repository & send pull/merge requests from it instead of needing to create an account then for & use up space on another’s forge. The Forgejo lineage has a strong interest in this technology. Currently the only decentralized+popular way to send patches is via email so this will help put the D back in distributed version control system (DVCS). This would not only be great for users getting to keep their private data, but the distributed nature adds a layer of resilience for downed Microsoft servers (happens often) or censorship/sancations as with even a little momentum, your project will have mirrors in multiple jurisdictions.
GitLab is open core, which is a step up from fully-closed, but isn’t fully open (nothing inherently wrong with that, but it is of note). The bigger issues with GitLab to me are twofold: 1) it’s https://forgeperf.org built on Ruby & React (I think) where it can’t run on a potato requiring both excessive CPU as well as data usage while also requiring JavaScript & 2) GitLab is publicly traded which means there are shareholder requirements for them that can easily get in the way of what is good for users (or even what will be or continue to be licensed with a free software license).
Codeberg is ran by a German nonprofit which means they aren’t trying to put profits in the way of users, but also being in the EU, they will have strict requirements for user data which means it’s safer. As far as I can tell, there are no ads & it runs fast & works well enough without JavaScript. I would rather see more self-hosting personally, but if it isn’t practical for you, this is a good option. With it being built with Forgejo, it should in theory introduce a lot less friction migrating from Codeberg to self-hosted Forgejo in the future.
Forgejo isn’t without flaws tho. One of the goals of Gitea (forked from Gogs) vs. Forgejo (forked from Gitea) is trying to be more compatible with Microsoft GitHub even moving its continuous integration (CI) to Forgejo Action to be compatible with all the bugs & YAML spaghetti that MS GitHub uses. They copy the generally-bad pull request model too which only is optimal in certain uses cases, bottlenecking review & having a UI that leads maintainers more to commenting on how to fix something rather than saying “thanks”, merging, then fixing small nits themselves to not waste the contributor’s time in review if they just want a small bugfix, not to learn your entire codebase + style + process. By copying MS GitHub too closely, you can up being a clone that is just FOSS while risking having something that is technically differentiating which is ironically counter to inspiriting migration since while it might be easier, the benefits seem moot (maybe even just philosophical) instead of providing something users want to leave for (which is what I think you might be getting at). Additionally being Git-based as well means Forgejo (& others) are stuck with snapshots that factor in time & patch order causing unnecessary merge conflicts with multiple users which is solved by choosing a better version control system (VCS).
You hinted at a possibly better version control system at the end there viz merge conflicts. Can you let us know which ones you think are better at this? The amount of time I waste on that at work is bonkers.
Gerrit is probably the poster child for branchless, stack-based diffs in Git. It takes some get getting used to, but once adjust your thruput is really ramps up. In some sense tho, this is a hack by tagging changelist values in the commit message to help reconstruct what the heck is going on due to Git limitations, but it’s old & robust enough to trust that system & many of its users absolutely swear by it (I have limited exposure but have used it more recently I can feel the appeal). You should be able to slap it in front of any Git server—even just straight host HTTP if not something lightweight like cgit, gitweb, or Ayllu. (Jujutsu is the same commit hackery in a different package & I don’t think it moves the needle as much as folks think being ultimately shackled to Git’s design decisions).
If you look outside of snapshot-based tools like Git, Mercurial, & so on, patch-theory-based options offer refuge. Darcs & Pijul are the leading (D)VCSs in the space. Darcs is very mature & shows its age in many ways (but is still developed & works good enough). Pijul is largely based on Darcs but meant be faster (& is), but it is immature; some features are missing on purpose to avoid the swell of Git commands, but I am personally surprised theres no good story for sending patches nor rebase. That said its identity system is how VCS should do it. Both VCSs have a lot less tooling built around them. Darcs is still supported by tools like Nix (but not Flakes) as well as Opam for OCaml with darcs hub & Smederee for maintained public forges. Pijul isn’t supported by much at all unfortunately & while Nest is a public forge, its lacking in features & basic usability like being able to fetch a tarball (despite pijul archive). All the latter negativity may sound bad, but all tooling requires momentum. They would be prime candidates for the Gerrit workflow–just without the hacks needed. With the two being similar, I hope we see more tooling pop up to support them & just like trying a new paradigm of programming gives you insight on the ones you know, a new way to do VCS will teach you about version control. Do recommend.
GitLab isn’t open source, and certainly isn’t an open project first — they have a sales team, a marketing team, and a budget who does not account for getting new dev users
This usually happens when Manjaro doesn’t carry a package that Arch does carry (and that the package you’re trying to install from the AUR depends on).
This is always a risk when combining Manjaro with the AUR, as Manjaro is a few weeks behind Arch when it comes to packaging. You can try if the beta repositories have the package, but otherwise you’ll just have to wait for Manjaro to update its packages. It’ll probably resolve itself, eventually.
You can try looking on the Manjaro forums (I don’t see a workaround other than switching to testing/unstable) to check if there’s a fix, but please don’t bother the Arch/AUR people, they can’t help you.
The AUR is for Arch and trying to use it on a different distro will have mixed results at best.
You can either wait for Manjaro to catch up and add the glib2-devel package which was created over a month ago, or edit the plgbuild and change it to glib2
You can always use Endeavour OS. It’s Arch with a nice installer and some utilities already installed to make it easier to use and maintain. It uses Arch repositories, so for all intents and purposes, it is Arch. Manjaro is not.
Normally you don’t even need AUR for that since it’s a core package for Arch. Unless Manjaro did something weird, you should be able to install it via pacman.
However I checked Manjaro packages and glib2-devel is the same version with Arch. Maybe try a whole system update before adding new packages?
Honesty I found gentoo more easy to install then arch. Mainly because the Gentoo handbook is soo good and is in laid out in a good order. Compare that to the arch wiki that has a ton of sub pages and redirects. Which is just a load harder to follow.
PS. This is before their was a guided installer for arch.
I only use a Windows VM For our ancient (in computer terms) Canon LIDE 60 scanner which seems to work best there (linux produces highly grey contrasted scans).
For all of our scanned documents from the scanner, I have it mapped to a network drive via Samba Shares. Since you are using Fedora, I think you may already have Cockpit installed. This makes it a lot easier and is a web gui to manage servers. You can usually access it on your Desktop via https://localhost.9090 Then you would need to install 45 Drives File Sharing plugin and setup a SAMBA share.
From the Windows VM, just map to the same workgroup you set in the SAMBA Share you created and give it a drive ID such as F:
First, confirm if you can access Cockpit by going to the localhost:9090, If not, follow the Fedora instructions here: Having some familiarity with Command Line is essential. Your graphical package manager may or may not include Cockpit.
Cockpit does sometimes allow you to install “plugins” from the web GUI, but in my experience (both on Debian and Arch), it doesn’t do it to well. If you can’t install plugins for 45 Drives file sharing plugin, you will need to do it manually:
For the 45 Drives plugin to enable sharing: github.com/45Drives/cockpit-file-sharing(I believe it’s the “Direct from .rpm” section if you scroll down in the Readme)
I think that it’s definitely a good case for overlaying with install. They say to use it sparingly because it increases the chances of something breaking, but that doesn’t mean it will. Something like a VPN usually needs liw level access that container isolation makes difficult.
I’ve only had 1 issue on silverblue years ago where I couldn’t update because I had vim overlayed and they fixed it within a day or two.
Ah, okay. Yeah, I only need to install OpenJDK and this client, and I don’t think either of those are likely to be included in future Bazzite images, since it’s gaming-focused and not development- or workstation-focused.
Look at Bluefin or Aurora. They are also made by Universal Blue and have developer versions that come with Tailscale VPN. They’re built on Fedora Silverblue just like Bazzite. I personally just moved to Bazzite two weeks ago, and then switched to Aurora.
Aurora is really nice, and I should see if I can get it working better in a VM to try it out. The main differences between Aurora and Bazzite that I can tell are the suites of preinstalled packages and the particular ujust recipes included.
Tailscale is probably not something I can use, unfortunately, since my employer has set up connectivity via SonicWall. I doubt they’re going to allow a change just for me. 😅
I may try that. They have OpenVPN for connecting to a different domain on the network, so maybe it’s possible a config could exist for the one I need to connect to.
Containers are great to keep OS separate from apps, but VPN seems pretty integral to OS, so I don’t see an issue using rpm-ostree. Containers often prove challenging because of not being able to get permission or share data between apps ( on purpose )
Judging purely on the dependencies I see in pacman, nsxiv depends on imlib2, which pulls in a lot of libraries, while imv links to a subset of those libraries directly.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.