These posts should be disallowed on this forum. For that there should be /c/distrorecommendations or something like that instead. And I guess pin a post linking said forum, so that people who just search “lemmy linux” know where to go.

This is not really about time savings. It’s more about “I want to spend as little time as possible doing this crap.”. But I agree the switch is not super worth it. IMO tiling WM vs a floating WM one is kinda like putting your toothbrush in the bathroom instead of the bedroom. Having it in the bedroom is inferior to putting it in the bathroom but in the end the more efficient option won’t really make your life different.

Number 2 is an implementation issue. Dialogs should be floating by default.

Number 3 is funny to me, because that’s exactly the experience I have when using a floating WM.

It does actually hurt something — my time. If the windows are on top of each other, that means I cannot see the one on the bottom. Which means I either have to click between 2 windows or make them tiled like you described (aka using a tiling WM but shit). Both options are inferior experience to a tiling WM which handles this automatically.

I don’t think tiling WMs are some mega productivity boost. But I also think that floating WMs are just a worse workflow with almost no benefits. The only exception is if you want to see only a part of a window, which is easier to do on floating WM. But that’s a rare situation and you can do it on a floating WM too, it just takes like 5 seconds more to set up.

The only potential downside is that software is not handled by your package manager, so uninstalling or upgrading can be pain. But there are ways around it like source based package managers or manually building binary packages and then installing them.

Not OP but the answer is that having windows on top of each other is mostly useless. 99% of the time, when you’re working with multiple windows, you don’t want to see just part of the window. So either your window is minimized or somehow tiled. At that point you are using a worse version of a tiling WM. The 1% of the time, you can just make the tiled window float.

Yeah I feel like this is an even bigger issue. Phones are basically a hardware ID card. Companies and (EU) governments use phones as a way to run “hard to tamper with” kind of software — banking apps, digital transport ticket, etc.

This kind of software is not compatible with Software Freedom, so if we want Linux phones, we first need regulation to get rid of this toxic software. Such regulation should allow the use of cryptographic keys (example) in place of crappy Android apps for things that are basically mandatory to live in current society (have a place where to store money, being able to travel, etc.). EU Linux phone can come after.

Could not have said it better lol. I dislike their overall mentality that they don’t care about proprietary code if it’s baked into hardware. But at least I can sort of understand how they got that idea. But with the microcode part, I just cannot even fathom how did they come up with such stupidity.

Nope, the permission bit is preserved if you share the pdf in an archive like zip. The “looks different” won’t help. There is always at least a single user who accidentally falls for a trap, which looks like an obvious trap to others.

FSF did not create Libreboot

Indeed (as I said) they did not create it, they made a shittier version of it, called GNU boot. Or I guess maybe not “the FSF” but devs under their umbrella. I think Linux Libre would be a better example. Or all the crappy “FSF approved” distros listed on their website.

it’s hard to create a chain of trust without trusting the hardware

That’s true but that’s not really their stance. They trust the hardware and the software running on said device, as long as they don’t have access to the software. Microcode updates are an example of this. They don’t like microcode “blobs” in the kernel but trust the outdated vulnerable microcode running on their CPU.

I would rather use a deblobbed device than wait for obscure security features that provide no real-world benefit to my use case.

I would not. I would prefer not to get hacked by spectre type attack. I also don’t like broken virtualization on my CPU and don’t want my CPU to destroy itself by high voltage.

But yes, I agree that to trust the software, we need to trust the hardware first. This also means that there is basically no “Respects Your Freedom” hardware. Every such hardware runs proprietary software which the user cannot see. And even if it ran no such software, it’s still just proprietary hardware, which we cannot study, create derivatives, etc. If I ran the FSF, I would acknowledge that there is nothing but grey area, instead of drawing an arbitrary line through the grey area.

Going back to phones, I am just worried that the Librephone project will focus too much on moving the proprietary parts from software to the hardware instead of actually helping users to get more freedom.

Brodie Robertson made a video about malware which pretends to be a pdf but is actually just an executable with a .pdf file extension. So if you double click it, you get pwnd. I think some desktop environments ask you for confirmation before running such thing but I would not count on it.

So we even have an example of Linux specific malware.

You should probably tell people why is this release newsworthy, otherwise people might as well just subscribe to the Pipewire changelog.

The issue is that for the FSF, what they call “software freedom” is their number one goal. So what’s likely to happen is that they create some kind of “deblobbed” firmware that breaks many features and security of the device, which Graphene OS will refuse to use.

I hope this project will be useful but am worried that they’ll just make a shittier version of someone else’s work like they did with e.g. Libreboot.

Cool! I might install something like this someday.

Do you use secure boot? What device is your server? I would use my laptop for that, but not sure if that’s how it should work.

I guess you can’t really convince the ones on the other side of the political spectrum. You only have a real chance to convince the “in the middle” people. But when doing so, it’s better not to give free munition to the opposing party to be more convincing than you.

Also I am kinda hoping that it (not using hyperbolic labels and overall being “nice”) helps create a place where people can be nice to each other even when they don’t agree on politics.

Some politicians or activists unfortunately use hyperbole too frequently and sometimes even maliciously. It gets them attention but at the cost of deepening the trenches in the political discourse. Drew thought he’s doing the right thing by calling a fascist out, but realistically this will be remembered as “The woke activists are calling us fascists for saying that nobody should be killed for their opinion.” in the right wing circles. Where the term “woke” is basically the right wing equivalent term to the left’s “fascist”.

just because you are active in some internet circle, does not mean you are active in every internet circle. I’d say the Right to Repair movement or Cloudflare are more “worldwide” than Kirk.

If it were properly modular, systemd would be built from universal components, which could be used by other init systems. But it’s the other way around. Meaning the universal components are created by taking them out of systemd. For example elogind is “extracted” from systemd to be a standalone daemon.

I am not knowledgeable enough to answer your question. But if it were an open standard, it would be more like Xorg than Wayland. There is only one X server implementation, just like there is only one systemd implementation.

Here Gnome is kinda like the websites which only work with Chromium based browsers. “Everybody is using Chrome anyways, right?” In a sense it’s also not really systemd’s or Chromium’s fault, that some devs decided to only support their platform.

I feel like Void devs will first wait it out. Perhaps Chimera Linux’ devs will come up with some workaround by then. A possible workaround could be to make Duncaen’s systemd fork official. Though I’m not sure if maintaining 2 init systems would be less work than to patch the systemd API specific stuff.