For tasks that I know, I’m faster in the terminal. For tasks where I’m less familiar or that are very important (like disk partitioning) I prefer a GUI because with a GUI I can usually see a bit better what I’m doing.
Terminal tasks for me include copying stuff, setting folder permissions, uncompressing or compressing folders, quick edits in vim, etc.
I’m not sorry that the CIA is using your closed-source software you mistakenly thought you owned anything because you paid way too much for anyone else to actually control your shit, you ignorant slave.
Edit: You’re a bunch of ignorant fuckwads. You can’t read shit and know who’s on what side because your sensitive to sarcasm and blatant…nevermind. Fuck off.
There is no reason to “hate” Ubuntu but there are better choices.
What are those better choices then (for those who currently use the non-LTS Ubuntu releases and don’t want to move to rolling releases or LTS-only releases)?
Never touching Fedora again. It’s a corporate distribution. As much as people might say otherwise redhat has a lot of pull over it. Look at the lawyers getting involved over pulling out the codecs.
Your loss, it’s a great distribution and if you spent even a couple of minutes in our forums you’d see that the RedHat pull is due to them actually collaborating and being and active part in the community.
I was an Ubuntu person for a long time, and when reading criticism about the inability to upgrade versions, I realized that had been my entire experience. I decided to give a rolling release a chance, and it’s been amazing.
I use arch(installer)btw. 🐧 AURs are pretty ingenuous, which is just pulling and compiling a git. Maybe a little less secure, but look at what happened to the snap store this year.
If you want to try a rolling release but didn’t want to use Arch, there’s always Fedora, & OpenSuSE Tumbleweed.
Outside of that, for non Ubuntu distros you could do OpenSuSE regular, or for true LTS use Rocky. Or take the red pill and go with Hannah Montana’s Linux.
A lot of that data doesn’t actually exist, ostree hardlinks data blobs internally, so the actual size on disk is much smaller than most disk usage tools will show.
You: It’s a single user system
Also you: Tmpfs would have to be done for every user
And a /tmp/ symlink would have to be created for every user too, so I don’t get your point
Tmpfs is just as easy as making a symlink, but without the filename conflicts between files in ~/.config/ and /tmp/. You just need to add a line to /etc/fstab
<span style="color:#323232;">find /home/ -mindepth 1 -maxdepth 1 -type d -exec mount none {}/.cache/ -t tmpfs -o size=16G </span><span style="color:#0086b3;">;
</span>
for doesn’t work here because it uses spaces to delimit strings, which could cause issues with filenames that contain spaces
You can also create a systemd user service, which is useful if you don’t have root access. The above mount command requires root, but the following doesn’t and is more robust than symlinking to /tmp/:
Isn’t most of what’s in there just filters downloaded from the internet? Python packages, browser cache, etc? Your system confirms you to redownloading everything all the time, no?
JXL is the best image codec we have so far and it’s not even close. I did a breakdown on some of its benefits here. JXL can losslessly convert PNG, JPG, and GIF into itself, and can losslessly send them back the other way too. The main downside is that Google has been blocking its adoption by keeping support out of Chromium in favor of pushing AVIF, which started a chicken and egg problem of no one wanting to use it until everyone else started using it too. If you want to be an early adopter you can feel free to use JXL, but just know that 3rd party software support is still maturing.
Something you might find interesting is that the original JPEG is such a badass format that they’ve taken a lot of their findings from JXL and made a badass JPEG encoder with it named jpegli. Oddly, jpegli-based JPEGs are not yet able to be losslessly-compressed into JXL files, per this issue - hopefully that will be fixed at some point.
Give a kid the arch install wiki and a computer with the USB iso ready to go. Tell them they aren’t allowed food until they install it and run neofetch.
To be honest, Ubuntu likely has nothing to do with it and I find the headline therefore misleading. It’s mostly the Linux kernel from how it reads.
Ubuntu 23.10 was run for providing a clean, out-of-the-box look at this common desktop/workstation Linux distribution. Benchmarks of other Linux distributions will come in time in follow-up Phoronix articles. But for the most part the Ubuntu 23.10 performance should be largely similar to that of other modern Linux distributions with the exception of Intel’s Clear Linux that takes things to the extreme or those doing non-default tinkering to their Linux installations.
Proprietary snap store backend that is controlled by Canonical: that’s it.
I used Ubuntu for years: installed it for family and friends. I moved away around a year ago.
Moving packages like Firefox to snap was what first started annoying me.
If the backend was open source, and the community could have hosted their own (like how flatpak repositories can be), I might have been slightly more forgiving.
Did a quick Google to find if someone had elaborated, here’s a good one:
It is also a commercial distribution. If you ever used a community distribution like Arch, Gentoo or even Debian, then you will notice that they much more encourage participation. You can contribute your ideas and work without requiring to sign any CLAs.
Because Ubuntu wants to control/own parts of the system, they tend to, rather then contributing to existing solutions, create their own, often subpar, software, that requires CLAs. See upstart vs openrc or later systemd, Mir vs Wayland, which they both later adopted anyway, Unity vs Gnome, snap vs flatpak, microk8 vs k3s, bazar vs git or mercurial, … The NIH syndrom is pretty strong in Ubuntu. And even if Ubuntu came first with some of these solutions, the community had to create the alternative because they where controlling it.
Serving files over HTTPS is not difficult to implement If anyone cared. Even if the cloud backend was open source you still wouldn’t use it. Downvote now!
I’ll add one more grip: Amazon integration. It’s been resolved for like 7 years now, but I still hold it against them a bit for placing Amazon search results in my desktop all those years back. Not that I don’t have an Ubuntu server running as we speak, but it still does taint them a tad in my eyes (and probably acts as an anachronism to the “it’s a corporate distro” theme of dislike around here).
Ahh, okay, so nothing new under the sun: Hipsters hate normies and September never ended.
Although I’m under the impression that Mint and Pop have taken a bite out of the “beginner desktop” market, Ubuntu is most of what I observe in the office when everybody else is booting Windows.
I can understand selecting for novelty; I’m usually in that camp. But novelty shouldn’t come at the expense of an argument to IT departments that they should support at least one Linux distro.
Features include caching,[4] full file-system encryption using the ChaCha20 and Poly1305 algorithms,[5] native compression[4] via LZ4, gzip[6] and Zstandard,[7] snapshots,[4] CRC-32C and 64-bit checksumming.[3] It can span block devices, including in RAID configurations.
The main takeaway from the article is that the developer’s name is Kent Overstreet, who beat his bitter rival Surrey Underpath, who are both canonically related to famed developer Cornwall Midroad.
As someone else said, it’s similar to btrfs. bcachefs has a lot of functional overlap with btrfs, which is great. There have also been a few benchmarks showing that bcachesfs is faster for some situations (cold-cache warming, IIRC). One of the big advantages over btrfs is that bcachefs’s RAID is more robust - several of btrfs’s RAID levels have been marked as experimental and prone to data loss, for years. There’s been improvement in btrfs RAID lately; the skeptic in me believes this is directly a result of pressure from bcachefs, which is in a position to become a favored fs in Linux.
I really hope it would be a working one, not like xfs where your files may just disappear with no trace (never on Irix, never on any other fs) or like btrfs which may just suddenly go read only and be dead on reboot with no fsck and all data unreachable.
How hard is it to get the basics right? Doesn’t matter how much rice there is if it keeps blowing up.
Me too. I’ve run 30 years with ext and bsd filesystems with no failure. Many years with various UNIX native fs as well. But Linux xfs, reiserfs, btrfs all have resulted in catastrophic failure within a year on several machines. They’re permanently off my list, but I have some hope that someone will get a new fs right.
A lot of the time it obviously takes a little while for userland tools to catch up and for distros to include both the new kernel and userland tools for it into their latest versions but once that is done average users certainly do notice differences. Literally all the features that are talked about a lot like BPF or io_uring or all the features that make containers possible were introduced in a kernel release at some point.
I’m sorry, but what exactly do you mean by backwards compatibility? Like if I installed the latest version of say Ubuntu, it will automatically scale back the kernel to one that fits the specs of my computer?
Linux can be a hobby, not just a tool. If you want to have fun with a new hobby, distro hopping will have plenty to keep you busy. But if you just want something to run your computer and your current distro does it for you just fine, then you’re not missing out on anything but a headache.
It’s funny, I’m in an opposite situation. I don’t want to distro hop, but my current one has some issues that I’m getting a little fed up with (issues that are a result of my hardware and use case) so I am working up to swapping distros to find something with fewer issues. For me, I just want my OS to be transparent. I don’t want a hobby. That’s why it took me so long to swap to linux in the first place.
Anyways, IMHO, unless you’re really into the idea of playing with your OS as a hobby, don’t let FOMO trick you into making the mistake of throwing out what works in the hopes of greener grass.
This is a big issue with Snap. It may be like Flatpak, allowing devs to set their own dependencies for ALL distros, but its poor uptake outside of Ubuntu’s ecosystem means that it’s no different to yet another distro repackaging system.
Flatpak, or even Nixpkgs, are the future because they allow devs to have control over the distribution of their software. Snap being such a closed ecosystem in comparison only means it will replicate many of the problems we’ve found with traditional (re)packaging systems.
I can’t speak for Flatpak as I haven’t tried it but nixpkgs are beautiful to work with and configuration of my system has become completely reproducible in a clean format.
As a dev, you can just distribute a nixpkg with whatever build tool inside. That beats the current system of “native” packages where your software is repacked and then maintained by half a dozen teams for different distros that use different dependencies and update cadences.
Bottles has gone as far as to demand its fedora package be removed and now shows a warning if you’re not using the flatpak version because repackers just don’t properly test all their software (how can they? there are thousands of apps in these repos!)
nix is a “native” packaging format. Apps are compiled for your host OS and run in that environment with no restrictions, for better or worse.
Flatpaks are containers. They provide a virtual OS to the application such as the file system, and accessing host OS features is done through “portals” which just means you can give/revoke the ability of the app to access your host OS resources such as networking, file access etc.
Flatpaks are therefore much safer in theory. But Nix packages are lower overhead, and can interact like any built-in software binary that you’d have when you spin up a fresh install of, say, debian.
Nix packages are harder to use IMO thanks to their poor documentation and lack of GUI package manager support (not that it’s impossible, just that it’s been a niche system for most of its life) and since most people are accustomed to flatpaks and their permissions system (and the fact it comes preinstalled on most distros) so flatpak is still pretty ubiquitous, even for NIxOS users
linux
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.