Please be polite. If you don’t like a post you can downvote it. If you would like to comment please be more civil.

How is this faulty? The degree of damage is incredibly relevant. We don’t make everything that could ever cause damage illegal, because we have nothing left. Laws are a balancing act of pros and cons to society.

A car has far less visibility (they are inside a box with a few windows) will will do far more damage if they hit someone. A cyclist has dramatically better visibility (they have basically an unobstructed 180° view) and especially when going slow is very unlikely to cause significant damage (posing risk of significant harm only the the most frail and elderly).

If not requiring complete stops for cyclists leads to 1% more cyclists on the road (because their travel is easier) it almost certainly causes less harm overall due to how dangerous cars are and also their indirect health effects (both inactivity when driving and the pollution).

So no, the logic isn’t faulty at all and probably one of the most important arguments.

Misuse of /s.

It’s also super locked down. You are only allowed to use it if Google or Apple says that your device is authorized. So no root, no custom ROMs. Unless your phone is owned by a corporation and that corporation is blessed by Apple or Google you are out of luck. (There are currently ways around this but the gaps are slowly being closed as older devices are phased out.)

I’m also not familiar. But my understanding is that the package maintainers should prevent this situation. Because otherwise even if there are package version dependencies (I don’t actually know if pacman does this) it would just block the update which results in a partial update which isn’t supported. For example if your theoretical unmaintained Firefox blocks the update of libssl but Python requires new functionality you would be stuck in dependency hell. Leaving this problem to the users just makes this problem worse. So the package maintainers need to sort something out.

It is a huge pain when it happens but tends to be pretty rare in practice. Typically they can just wait for software to update or ship a small patch to fix it. But in the worst case you need to maintain two versions of the common dependency. In lots of distros very common dependencies tend to get different packages for different major version for this reason. For example libfoo1 and libfoo2. Then there can be a period where both are supported while packages slowly move from one to the other.

IF no dependency tries to update too. Off course in that case I would stop. Without pacman -Sy, I never do that anyway, only -Syu.

That’s all you need to know. As long as you always use pacman -Syu you will be fine. pacman -Sy is the real problem. The wiki page is pretty clear about the sequences of commands that are problematic https://wiki.archlinux.org/title/System_maintenance#Partial_upgrades_are_unsupported.

Right? What i don’t understand is, when I uninstall with pacman -Rs firefox, delete the cached firefox package (only that file), then the system is in the same state as before I installed it. Then -S firefox should be okay, right? And it even looks up the new version.

This isn’t correct. It won’t look up the new version. Assuming that the system was in a consistent state it will download the exact same package that you deleted. The system only ever “updates” when you run pacman -Sy. Until you use -y all packages are effectively pinned at a specific version. If the version that gets installed is different than the one you removed it probably means that you were breaking the partial update rule previously.

But that is my point. Just running pacman -S firefox is fine as long as you didn’t run pacman -Sy at some point earlier. It won’t update anything, even dependencies. It will just install the version that matches your current package list and system including the right version of any dependencies if they aren’t already installed.

But that means if you already have Firefox installed it will do nothing.

I think you are a little confused at the problem here. The issue is that partial updates are not supported. The reason for this is very simple, Arch ensures that any given package list works on its own, but not that packages from different versions of the package list work together. So if Firefox depends on libssl the new Firefox package may depend on a new libssl function. If you install that version of Firefox without updating libssl it will cause problems.

There is no way around this limitation. If you install that new Firefox without he new libssl you will have problems. No matter how you try to rules lawyer it. Now 99% of the time this works. Typically packages don’t depend on new library functions right away. But sometimes they do, and that is why as a rule this is unsupported. You are welcome to try it, but if it breaks don’t complain to the devs, they never promised it would work. But this isn’t some policy where you can find a loophole. It is a technical limitation. If you manage to find a loophole people aren’t going to say “oh, that should work, let’s fix it” it will break and you will be on your own to fix it.

Focusing on your commands. The thing is that pacman -S firefox is always fine on its own. If Firefox is already installed it will do nothing, if it isn’t it will install the version from the current package list. Both of those operations are supported. Also pacman -Rs firefox && pacman -S firefox is really no different than just pacman -S firefox (other than potentially causing problems if the package can’t be allowed to be removed due to dependencies). So your command isn’t accomplishing anything even if it did somehow magically work around the rules.

What is really the problem is pacman -Sy. This command updates the package list without actually updating any packages. This will enter you system into a precarious state where any new package installed or updated (example our pacman -S firefox command form earlier) will be a version that is mismatched with the rest of your system. This is unsupported and will occasionally cause problems. Generally speaking you shouldn’t run pacman -Sy, any time you are using -Sy you should also be passing -u. This ensures that the package list and your installed packages are updated together.

Of course nixpkgs has it. It was added a few years ago, I can’t vouch for if it is up to date or still working.

Maybe in some areas. But in downtown Toronto tons of restaurants are super busy, and delivery orders seem through the roof. But this also doesn’t really solve the tipping problem, it seems pretty orthogonal.

No, I don’t mean a law. I don’t even know how you would make this a law. You can already legally just walk away. Maybe you can have a law that the “no tip” option on card machines must be at least as easy as the tip option or something.

There is no such thing as “everyone”, but you only need a tipping point. Maybe 1/3 of people or similar. You just need enough awareness so that it isn’t considered incredibly rude or outrageous, that most retail workers will understand what is happening and the businesses will see it coming. It definitely wouldn’t be easy, that is why I would put the target date far in advance (maybe next January is actually too close). So that cultural knowledge could slowly be built and enough people to make a difference would switch at the same time.

IMHO if we want to get rid of tips the way to go about it is to pick a date (for example January 1st 2026) then agree to stop tipping on that date. Hard and fast stop doing it. Stores can raise their prices to compensate.

The problem is that it is very hard to make this change incrementally. Because individuals are considered assholes if they don’t tip enough. So we all sort of got to get together and agree to it. Of course it will be hard to publicize this because big media companies are all owned by the rich that benefit by paying minimum wage workers less with the excuse that they can get tips.

require a separate device that looks like a calculator to use online banking

To be fair this actually provides a very high level of security? At least in my experience with AIB (in Ireland) you needed to enter the amount of the transactions and some other core details (maybe part of the recipient’s account number? can’t quite recall). Then you entered your PIN. This signed the transaction which provides very strong verification that you (via the PIN) authorize the specific transaction via a trusted device that is very unlikely to be compromised (unless you give someone physical access to it).

It is obviously quite inconvenient. But provides a huge level of security. Unlike this Safety Net crap which is currently quite easy to bypass.

which is supposed to enforce to run apps in secured phones

The point of the Google Play Integrity API is to ensure that the user is not in control of their phone, but that one of a small number of megacorps are in control.

Can the user pull their data out of apps? Not acceptable. Can the user access the app file itself? Not acceptable. Can the user modify apps? Not acceptable.

Basically it ensures that the user has no control over their own computing.

Yeah, Beeper is kind of in a strange place now. I get why they wanted to make their own app to make the bridging experience (especially setup) more seamless. But now with a fully custom closed-source app they are even further off the open path.

What I really want from Beeper is to be able to connect to their bridges from a non-beeper Matrix account with a non-Beeper client. I would happily pay them for the service of managing bridges. I don’t have much interest in having a Beeper-owned account in a custom Beeper client.

Back in the day X was a great protocol that reflected the needs of the time.

1. Applications asked it to draw some lines and text.
2. It sent input events to applications.

People also wanted to customize how their windows were laid out more flexibly. So the window manager appeared. This would move all of your windows around for you and provide some global shortcuts for things.

Then graphics got more complicated. All of a sudden the simple drawing primitives of X weren’t sufficient. Other than lines, text and rectangles applications wanted gradients, rounded corners and to display rich graphics. So now instead of using all of these fancy drawing APIs they were just uploading big bitmaps to the X server. At this point 1/3 of what the X server was previously doing became obsolete.

Next people wanted fancy effects and transparency (like drop shadows). So window managers started compositing the display. This is great but now they need more control than just moving windows around on the display in case they are warped, rendered somewhere slightly differently or on a different workspace. So now all input events go first from X to the window manager, then back to X, then to the application. Also output needs to be processed by the window manager, so it is sent from the client to X, then to the window manager, then the composited output is sent to X. So another 1/3 of what X was doing became obsolete.

So now what is the X server doing:

1. Outputting the composited image to the display.
2. Receiving input from input devices.
3. Shuffling messages and graphics between the window manager and applications.

It turns out that 1 and 2 have got vastly simpler over the years, and can now basically be solved by a few libraries. 3 is just overhead (especially if you are trying to use X over a network because input and output need to make multiple round-trips each).

So 1 and 2 turned into libraries and 3 was just removed. Basically this made the X server disappear. Now the window manager just directly read input and displayed output usually using some common libraries.

Now removing the X server is a breaking change, so it was a great time to rethink a lot of decisions. Some of the highlights are:

1. Accessing other applications information (output and input capture) requires explicit permission. This is a key piece to sandboxing applications.
2. Organize the system around frames to avoid tearing except for when desired (X doesn’t really have the concept of a frame).
3. Remove lots of basically unused APIs like fonts, drawing and many others.

So the future is great. Simpler, faster, more secure and more extensible. However getting there takes time.

This was also slowed down by some people trying to resist some features that X had (such as applications being able to position themselves). And with a few examples like that it can be impossible to make a nice port of an application to Wayland. However over time these features are being added and these days most applications have good Wayland support.