I guess it depends how you look at it. From my point of view the speaker isn't actually talking about themselves. That is the "royal" part. And I mean she does say "as if" to back up that yes, she is not actually including herself.
I use https://difftastic.wilfred.me.uk/ which is well, fantastic. I have it set up as the default diff for Git and it is really nice.
No, this is the right meaning royal we. If you say "we are going into battle" it is talking about the person being talked to not the person talking. So in this case "We don't eat that" would be implying that the cat doesn't eat that, not actually saying anything about the speaker even though "we" would imply they are included.
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 -Syuyou will be fine.pacman -Syis 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-yall 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 firefoxis fine as long as you didn't runpacman -Syat 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 firefoxis 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. Alsopacman -Rs firefox && pacman -S firefoxis really no different than justpacman -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 ourpacman -S firefoxcommand 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 runpacman -Sy, any time you are using-Syyou should also be passing-u. This ensures that the package list and your installed packages are updated together.- JumpDeleted
Permanently Deleted
I hear what you are saying. But our society is pretty fucked up if you "deserve" something bad because you bought a product without imaging how the manufacturer can make it worse in the future.
The owners should be able to return the product if something like this happens, no matter how long ago they bought it.
You are misunderstanding. They are forcing people to use LLMs at the cost of productivity so that they can hopefully find places where LLMs can improve productivity.
This isn't really unreasonable. They are basically trying to get ahead of the adoption curve by forcing pre-mature adoption and find use cases. Bezos loves firing workers so this is basically a win-win. If it works they offload more work to LLMs and fire workers, if it doesn't work other workers get a bad performance review and get fired.
Reverse DNS is different than static IP.
But yes for outbound email, if you can't control reverse DNS you will have pain. (Inbound is totally fine) You can in theory just use whatever hostname the ISP's reverse DNS resolves to however you will get some spam score (or be rejected) as it doesn't match your "from" domain.
Outbound email is a huge pain really no matter what. Unless you have a long-term lease on the IP and it isn't in a bad network you really have to pay someone else if you want reliable delivery.
Yeah, it is very important to consider how dependant you are on third parties. At the very least the more dependence the more power they have over you. But also how screwed you are if they just go under.
- If you use SaaS they can interrupt your use at any time and you can only react (for example demanding a reversal or lawsuits).
- If you host closed source software they can't interrupt service on an existing contract but can legally require you to stop using it if they don't renew the contract. (And if the company goes under you can likely get away with using the software as long as it doesn't need code fixes.)
- If the software is open source you can continue using the software indefinitely including making code fixes. (Maintenance may be expensive as it is now your problem but that can be costed and an exit plan made if required.)
Gotta wish for a 64-bit genie.
Yeah, I finally pulled the trigger and moved to my own domain from
matrix.org. Man, it is just so much faster. Which is sad, because the performance is pretty bad. (Element Web seems to do some per-room request as part of the initial loading screen which is obviously not scalable) but getting off ofmatrix.orgis a huge performance improvement.That being said there is nothing really wrong with
matrix.org. The problem is really public rooms. People will join and spam. It is true of any protocol (have you heard about email?) but Matrix definitely needs to (and they are slowly working on) make it more expensive for spammers.- JumpDeleted
Permanently Deleted
/favicon.icois the only "default" URL./favicon.icois usually not an actual "icon" type anymore but PNG or JPG (but with the same URL). Other than that you need to load the HTML and check forLinkheaders or<link rel=icon>elements. While URLs like/favicon.pngmay be popular they aren't part of any actual protocol. - JumpDeleted
Permanently Deleted
Sort of...
You can just hope that
/favicon.icoworks. But 1. it often doesn't and 2. it is often of low quality.To find a favicon on a modern site you need to load the HTML and check
Linkheaders and<link rel=icon>elements. However you likely can't do this client-side for most sites because of CORS. So you need some server (at the very least to strip CORS). That lets you get the URL but 1. you probably don't want to have connections to external domains for user privacy and 2. some domains will have hot-link protection so you need to fetch the image via your server. You will also want to consider different image formats and sizes to serve the right image to the right client. On top of all of this the site may be using some sort of bot protection which you will have to fight. Google is almost always whitelisted. The site may also have temporary outages so having a cache would be nice, especially if that is almost always populated before you even know the domain exists.At the end of the day you do want some sort of API. And while it isn't complex it isn't trivial. So it is nice to just let Google handle it. (Other than tracking risks, but you could proxy Google's API.)
Only rail. Toronto has an excellent bus network that is not pictured here.
There is not even enough money for proper maintenance let alone new construction! Of course new construction looks good politically so it will get separate budgets while the existing infrastructure slowly crumbles. Look at the "reduced speed zones" that have lasted for years because the rails can't properly be maintained.
Selfhosted @lemmy.world LDAP to UNIX user proxy
Programmer Humor @lemmy.ml Haunted House
Linux @lemmy.ml Attempting to use bcachefs
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.