The trump comments aren’t the issue, it’s Proton’s acknowledgement that they will turn over data to the swiss police when asked.

BTRFS and ZFS both use block compression, ZFS by default. It’s meant to increase both storage efficiency and access speed and has nearly zero impact on performance. The files aren’t compressed from the filesystem point of view, which would satisfy your requirement not to need any other tools.

I’m confused about your statement that you don’t want to save space with compression, but you indicated that you want to “make the most of your storage”. Are you looking for long-term archiving?

It’s not clear here if you mean block compression, file compression, or stream compression.

It would be nice, but the time it takes to do the work of validating package versions for LTS candidacy is either limited or not free, so this is the acceptable compromise.

Are you waiting for a kernel patch, or is this support simply not available yet?

Use ps -ef to find the source of the file.

Security is nice to have but it’s not the reason I’m using Linux, so handing over my photo ID to a third party I trust is an acceptable if disappointing risk.

And for us who don’t find it an acceptable risk? Will I need an ID to read a book next?

Man, I’m trying to soften on AI, but this post is just awful.

I’m not gonna say “don’t do it”, but I’ve dug into this deeply and I’ve turned away from RISC V.

RISC V is slowly being pidgeon-holed into embedded systems. This is not a bad thing, the embedded market (cars, tvs, industrial controls) is huge and diverse.

RISC V has had a very rough start to introduction into bridge-and-bus systems the way we know from Intel/amd because there have simply been too many iterations of CPU registers and capability flags for integrators to take the platform seriously enough to commit to piling a bunch of effort to design, produce, and lead sales on any RISC V platform. Even arm (especially v9) has settled some of these platform issues and is ahead of RISC V in adoption in the integrated platform space (as opposed to embedded).

Long story long, it is extremely difficult to write device drivers for RISC V because one would have to write half a dozen architecture versions, just for a niche platform that barely sells. Conversely, an embedded controller for, say, a vehicle gets a preliminary build and few revisions, ongoing support isn’t part of planning the same way.

Debian and alpine. Coming up on 27 years of linux for me.

What is “cross process rendering”?

Meh… There have been a whole lot of braindead “pls do it for me” posts going around since the influx of windows refugees.

I’m not one to be a prick about answering questions to help out, and we all start somewhere, but “help me get steam and my LLM working on Kali linux” where ppl get in way over their heads is becoming a real problem. Worse, they will call the linux community toxic for suggesting they need more fundamentals first.

I interpret the post title as a general “try your best, and come to us when you’re stuck”.

Honestly, incus.

I know it’s not strictly a utility, but holy cow, Stephane Graber and his team have put the work into that product, such that anything you can do in the ui can be done in the CLI, and more.

Tab completion entries for all the resource types (storage, instances, image repos, etc), help entries for everything, it brings a tear to the eye.

I once thought it was cool to have standardised man entries, but even better is context-sensitive --help entries that work well. Almost all the discovery I’ve made using incus, I’ve made using the commands themselves.

It’s a real testament to how putting in the documentation work might be tedious, but it is a boon to both users and devs.

Oh, come on. Pretending that foss devs have no connection to users or the community is not a take based in reality. The Linux world is full of changes made or reversed by community sentiment, even for bigger players like Canonical.

The very core of Foss is allowing popular and useful projects to gain momentum by appealing to users. Sure, you can fork a project or start your own, but that independence of the devs is rooted in community support to go do what you want.

And I’ll repeat myself: this is different, foss devs and users both will not have the option to just “go do their own thing” if these laws all become reality.

I was with you, particularly with your anti-violence stance, until this comment.

The answer to disagreements in the Linux world has been to fork a project or make your own. This is different, neither devs nor users will have a say if these various laws are instituted.

The majority of users do not care, and even if they did it’s still not the user’s place to demand the FOSS developers listen to them.

Linux is not a megacorporation. It is an array of different interests that still manage to get lots of interesting stuff done, even with those differences.

This was not a cool thing to say.

I haven’t run into any file managers that hide the path with no option to show it. Which one(s) are you talking about?

Do it in stages by shifting services one at a time from a google phone to a non-google device.

(In my experience):

Easy: pics, docs Intermediate: calendar, contacts, maps solution Most difficult: email

I’ve been trying to de-google for more than 5 years, and email is the surprise for me. It’s quite incredible how deeply interacted google and apple have made us. Once that’s done, google account will be terminated.

You can process these with bash string manipulation alone, but sed and awk will do this pretty easy.

All of this produces a feeling of anguish… Maybe I cannot stand knowing that this could be the standard everywhere.

I have similar feelings about the lack of alcohol taxation and the low rate of rice cooker adoption in the west.

You are struggling to accept the imperfect world as it is. You should stop introspecting on the symptoms and try to figure out why you are unhappy with other people’s choices.

Be careful.

Because it only formats stdin streams to into string(s), xargs can be very dangerous, depending on the command to which the arguments are being passed.

Xargs used to be a practical way to get around bash globbing issues and parenthetical clause behavior, but most commands have alternate and safer ways of handling passed arguments.

find -exec is preferable to xargs to avoid file expansion “bombs”, plus find doesn’t involve the shell, so it doesn’t care about whitespace problems.