Unfortunately not. The major difference between an honest bot and a regular user is a single text string (the user agent). There’s no reason that bots have to be honest though and anyone can modify their user agent. You can go further and use something like Selenium to make your bot appear even more like a regular user including random human-like mouse movements. There are also a plethora of tools to fool captchas now too. It’s getting harder by the day to differentiate.
Topical answer: Bots going around scraping content to feed into some LLM dataset without consent. If the website is anything like Reddit they’ll be trying to monetise bot access to their content without affecting regular users.
deleted by creator
When I say upstream that’s technically upstream of upstream - I mean the application repositories. Manjaro has in the past applied their own patches on top and broken functionality. The example that comes to mind is the most heinous one where a Manjaro maintainer patched in three pull requests (including CLOSED ones) and pushed the result to their stable repo: https://source.puri.sm/Librem5/chatty/-/merge_requests/986 https://source.puri.sm/Librem5/chatty/-/merge_requests/1035 https://source.puri.sm/Librem5/chatty/-/merge_requests/1060 https://forum.manjaro.org/t/manjaro-arm-beta25-with-phosh-pinephone-pinephonepro/116529/11 . Applying patches to upstream is not unheard of, but you don’t do it without contacting the developer, because they are the ones going to get the bug reports. Manjaro did not notify the developers. It’s this recurring trend of unprofessionalism which has tainted Manjaro’s reputation, whether it’s letting their SSL cert expire FOUR separate times (once, maybe twice is understandable, but more speaks to underlying issues in structure), or applying patches to applications without developer’s knowledge and shipping it to users, or the two separate times they DDoSed the AUR servers with a poorly thought out pamac feature, etc…
I give no concrete examples because this all occurred almost two years ago for me at this point. I’m not out to capsize Manjaro or bring about it’s demise, so I don’t write down every package that breaks for use as ammunition in internet debates. I just want a distro that works for me. Manjaro wasn’t that for me so I moved on. You asked why some people don’t like Manjaro and I’m simply explaining why.
The AUR issue happened often enough for me to consider it frequent. It happened most often with niche packages, like the various MSP430 toolchain packages which I often needed, but I explicitly remember it happening at least once on fairly mainline packages like cemu (or was it yuzu?).
The problem is not that Manjaro allows you to pick whichever major release kernel you like, but rather that it doesn’t account for this in the packaging system. You could be running kernel 6.4 (i.e. not officially supported anymore) and update your packages, resulting in a broken system with no warning. By decoupling the kernel version from the package system Manjaro unleashes a whole new failure mode. This would be fine if they accounted for this in their packaging model, but they don’t (because Arch doesn’t and it would be too much work to implement and support it themselves, presumably. It sounds quite tough). This tool, which is designed to make the system more stable as you say, actually can make it less stable!
Manjaro was sold to me as ‘Beginner Arch’, so I don’t know what to tell you on that front. I don’t think this is at all related to why people dislike Manjaro though: Nobody hates Ubuntu because it’s based on Debian, they hate it because of their decisions, like Snaps. Likewise nobody hates Manjaro because it’s Arch based, they hate it because of the decisions they’ve made. Manjaro isn’t the only distro getting hate, but it is probably the lowest hanging fruit due to all of the administative fumbles.
My DE broke because Manjaro added untested/beta patches from upstream, sometimes even against the developer’s word. This is something that Manjaro is known for. Guess who inspired dont-ship.it?
Also I would appreciate you not calling my statements on the AUR false. I have personal experience on the matter so we can play my experiences against yours if you like, or we can listen to the official Manjaro maintainers reccommending that it not be used, as it is incompatible with the Manjaro repos. By design Manjaro holds back Arch packages, which means AUR package dependencies often do not match what is expected. This is not false. Can you use the AUR? Sure, but you must keep in mind that Manjaro was not designed for it and it will break AUR packages sometimes. Sometimes it’s as simple as waiting a couple weeks for Manjaro to let new packages through, but sometimes you can’t just wait several weeks and you need to fix it yourself.
And yes, Manjaro does hold kernels back because you have to specify when you want to move off a major release. You can accidentally be using an unsupported kernel and not even notice. Ask me how I know. Manjaro literally requires more maintenance than Arch on this front.
I can’t comment on what maintenance Arch requires that Manjaro doesn’t, as I run EndeavourOS. I’ve found it to be everything Manjaro wishes it was - a thin, user-friendly wrapper around Arch.
Just remember that Manjaro’s official response to them forgetting to update their SSL certs was to roll back your clock, putting everyone at risk of accepting invalid certs in the process.
During my six month usage of Manjaro (my introduction to Arch-based distros), my desktop broke four times and booted me to the terminal. Almost once a month. I told myself this was the price you paid for living on the edge, using a rolling release. I switched to EndeavourOS and have not had a broken desktop in two whole years.
Manjaro’s handling of AUR packages is fundamentally wrong and with their design decisions it cannot be fixed. You either give up the AUR entirely, or resign yourself to constantly breaking AUR packages and having to try and fix them.
Manjaro’s handling of kernels via a GUI sounds good until you realise it’s entirely manual and if you don’t keep checking you will end up running an unsupported, out of date kernel with Arch packages that expect a newer one. Again, Manjaro violates Arch’s golden rule of avoiding partial upgrades by holding your kernels back until you manually update them in their GUI. If you’re running an Arch-based distro 99% of the time you want the latest kernel and an LTS kernel as a backup, but these are already in Arch as packages (and are thus updated in lockstep with your packages, as designed) so you don’t need Manjaro’s special GUI. Now if you wanted a particular kernel for some reason then sure, but Manjaro’s GUI doesn’t even let you pick the exact version you want anyway! All you can pick is the latest version of each major release.
If you’re anything like I was at the time, you think you like Manjaro but what you actually like is Arch. Manjaro just gets in the way.
I was surviving with Ubuntu, I had my complaints but I figured ‘that’s just how it is’ on Linux, that it was the same everywhere. I didn’t even realise what I was missing until I switched.
I got a hardware upgrade at one point, so in order to get those new drivers ASAP I tried an Arch-based distro, with plans to switch back once drivers became available. I never moved back.
The two big reasons I stayed was ironically enough the lack of good Ubuntu documentation, and the PPA system. Ubuntu is used a lot, but there’s not really formal documentation anywhere, only random tutorials online (most likely out of date and never updated) and people on forums talking about their problems. By contrast the Arch wiki is the gold standard of Linux documentation, there’s just no comparison. Even on Ubuntu I found myself using it as a reference from time to time.
Regarding PPAs, the official Ubuntu package list is strangely small so if you’re like me and find yourself needing other software, even mainstream software like Docker, you’ll be faffing about with PPAs. So if you want to install Docker, instead of typing
sudo apt install docker
You instead have to type:
# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
# Add the repository to Apt sources:
echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt-get update
These are the official install instructions, by the way. This is intended behaviour. The end user shouldn’t have to deal with all this. This feels right out of the 90’s to me.
Instead of PPAs, Arch has the Arch User Repository (AUR). Holy moly is the AUR way nicer to work with. Granted, we’re not quite comparing apples to apples here since the AUR (typically) builds packages from source, but bear with me. You install an AUR package manager like yay (which comes preinstalled on my flavour of Arch, EndeavourOS). yay can manage both your system and AUR packages. Installing a package (either official or AUR) looks like yay packageNameHere. That’s it. A full system upgrade like sudo apt update; sudo apt upgrade is a single command: yay -Syu, a bit cryptic but much shorter. The AUR is fantastic not just for the ease of use, but for sheer breadth of packages. If you find some random project on github there’s probably an AUR package for it too. Because it builds from source an AUR package is essentially just a fancy build script based on the project’s own build instructions, so they’re super easy to make, which means there’s a lot of them.
You might argue ‘but building from source might fail! Packages are more reliable!’, which is somewhat true. Sometimes AUR builds can fail (very rarely in my experience), but so can PPAs. Because PPAs are often made to share one random package they can become out of date easily if their maintainer forgets or simply stops updating it. By contrast AUR packages can be marked out of date by users to notify the maintainer, and/or the maintainer role can be moved to someone else if they go silent. If a PPA goes silent there’s nothing you can do. Also, since an AUR package is just a fancy build script you can edit the build script yourself and get it working until the package gets an update, too. PPAs by comparison are just a black box - it’s broken until it gets updated.
Moral of the story? Don’t be afraid to just give something a go. Mint will always be waiting for you if you don’t like it.
Selective enforcement is one of those concepts that isn’t talked about much outside of legal ethics circles unfortunately, but I think it’s an important concept to be aware of and the potential issues with it. I first heard about it from The Dictators Handbook, which explores many behaviours of politicians and those in power, including how and why corrupt nations often employ selective enforcement. It’s an interesting read, would recommend. It definitely changed how I looked at the world.
I have no strong feelings on which particular weapons should be legal to carry, even if it’s just pepper spray or brass knuckles or something. The main thing is that it should be legal to carry something.
Also, selectively enforced laws are a terrible, HORRIBLE concept and should be avoided at all costs. It gives police and those in power the ability to selectively punish (or pardon) whomever they choose, often at the whims of their personal biases. Passing and exploiting selectively enforced laws is a common tactic used by corrupt nations and can be used to silence political opponents, target selected groups, promote agendas and so forth. The law should not rely on cops ‘being nice’ and choosing not to arrest you.
For a start it shouldn’t be a crime to merely carry something for self-defense. The current laws say that carrying anything for the express purpose of self-defense is illegal. There’s a bizarre cat and mouse game where the law says ‘its fine to defend yourself’ while simultaneously expressly forbidding you from carrying anything that you might be able to use for self-defense. It puts anyone actually in a life threatening situation at a supreme disadvantage: An attacker is already breaking the law so they’ll be armed to some extent, but under the law the victim is designed to be defenseless. If they do decide to arm themselves against the law and use it to defend themselves they can be prosecuted for carrying a weapon after the fact.
I never said anything about changing gun laws.
New Zealand. Gun laws are pretty strict, though we have lots of farmers who have guns for defending livestock. You can own guns with a valid reason (e.g. recreational shooting, not self defense) but essentially the only two places they can be is in a locked safe or (being transported to) a gun range.
In addition any and all tools and weapons are illegal to carry for the purpose of self defense (knives, pepper spray, tazers, clubs, screwdrivers, etc.). There’s a crime epidemic here at the moment, corner stores being robbed by people with machetes, jewelry stores ram raided with trucks, but if you dare even carry pepper spray to defend yourself you can be jailed. Don’t bother calling the cops either, they won’t be there until at least half an hour later. Cops don’t care about robberies. We literally once had the dispatcher tell us that no police would be coming. It’s ridiculous.
I wish self defense laws were less crazy here, if someone enters your home or property armed with a weapon you should be able to respond appropriately without fear of going to jail yourself.
GTA online took ages to load, like 10+ minutes on some machines. One guy got really annoyed and investigated. It turned out to be loading a single 10MB JSON file in an incredibly inefficient manner. The JSON file contains about 60,000 items and they need to extract each item from it, but every time they look for the next item they start from the beginning of the file again, despite already knowing where they found the previous item! All the entries in the JSON list are unique, but the code also checks for any duplicate entries, of course it’s also done in the least efficient way possible requiring 1,984,531,500 comparisons for something that has no effect. Not only did this one person find these problems but he also implemented a fix that reduced load times by 70% as a result, shaving off more than 7 minutes of load times for some machines. The fact that Rockstar didn’t notice this is frankly shocking and speaks to the fact that they really just don’t care.
https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times-by-70/