The catarrhine who invented a perpetual motion machine, by dreaming at night and devouring its own dreams through the day.
That seems sensible.
Even a hypothetically true artificial general intelligence would still not be a moral agent, thus it cannot be held responsible for its actions; as such, whoever deploys and maintains it should be held responsible. That’s doubly true with LLMs as they aren’t even intelligent to begin with.
I’m not suggesting Arch, but Arch-based distros. Manjaro doesn’t break anywhere as often as Arch does.
…or alternatively go with Mint and re-learn how to handle the packages. pacman vs. APT is not a big deal anyway.
Its all just to play games.
Ditto - that W3.11 install is just because of the Windows Entertainment Pack, I love a few of the games in it (like Pipe Dream). I don’t even know if it’s able to connect to the internet!
Sorry, I couldn’t resist.
I started with a Knoppix-based distro, called Kurumin. KDE 3 was the rage back then!
On your main point: the shell might be hard in the beginning, but for most things that you need to use the shell with, people on the internet already had the same issue and shared how to do it. Unless you’re actively trying to make something different, like I did with my audio switching script.
And even the sort of situation that you need to use the shell for decreased by a lot from back then to now.
Besides what other users said: if you feel comfortable with SteamOS you might want to give EndeavourOS and Manjaro a check - all three distros are based on Arch Linux, and while Arch is geared towards experienced users the later two try to “sell” it towards a wider audience.
Repeated the test now (Friday, 18:30); same lang settings as above. Couldn’t find a single post in Portuguese after rolling across ~30 of them.
x.com and twitter.com are still inaccessible here.
This reminds me of that “all mushrooms are edible, at least once” thing.
What you’re proposing is effectively the same as "they should publish inaccurate guidelines that do not actually represent their informed views on the matter, misleading everybody, to pretend that they can prevent the stupid from being stupid." It defeats the very reason why guidelines exist - to guide you towards the optimal approach in a given situation.
And sometimes the optimal approach is not a bigger min length. Convenience and possible vectors of attack play a huge role; if
min 8 chars is probably better. Even if that shitty manager, too dumb to understand that he shouldn’t contradict the “SHOULD [NOT]” points without a good reason to do so, screws it up. (He’s likely also violating the “SHALL [NOT]” points, since he used the printed copy of the guidelines as toilet paper.)
I don’t think that the entity should be blamed for the shitty manager. Specially given that the document has a full section (appendix A.2) talking about pass length.
They might mean well, but the reason we require a special character and number is to ensure the amount of possible characters are increased.
The problem with this sort of requirement is that most people will solve it the laziest way. In this case, “ah, I can’t use «hospital»? Mkay, «Hospital1» it is! Yay it’s accepted!”. And then there’s zero additional entropy - because the first char still has 26 states, and the additional char has one state.
Someone could of course “solve” this by inserting even further rules, like “you must have at least one number and one capital letter inside the password”, but then you get users annotating the password in a .txt file because it’s too hard to remember where they capitalised it or did their 1337.
Instead just skip all those silly rules. If offline attacks are such a concern, increase the min pass length. Using both lengths provided by the guidelines:
I think so, based on the original: “Verifiers and CSPs [credential service providers] SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant.” With “shall not” being used for hard prohibitions.
That stipulation goes rather close to #5, even not being a composition rule. EDIT: see below.
I think that a better approach is to follow the recommended min length (15 chars), unless there are good reasons to lower it and you’re reasonably sure that your delay between failed password attempts works flawlessly.
EDIT: as I was re-reading the original, I found the relevant excerpt:
If the CSP [credential service provider] disallows a chosen password because it is on a blocklist of commonly used, expected, or compromised values (see Sec. 3.1.1.2), the subscriber SHALL be required to choose a different password. Other complexity requirements for passwords SHALL NOT be imposed. A rationale for this is presented in Appendix A, Strength of Passwords.
So they are requiring CSPs to do what you said, and check it against a list of compromised passwords. However they aren’t associating it with password length; on that, the Appendix 2 basically says that min length depends on the threat model being addressed; as in, if it’s just some muppet trying passwords online versus trying it offline.
If you speak Portuguese maybe.
I did some tests here, setting up my browser config to show content preferably in Italian, then German, then Portuguese, then English. It showed something like 5~10 posts in English for each post in Portuguese. (No content was shown in either Italian or German, so odds are that Bluesky doesn’t even take the browser config into account.)
Granted, for most Portuguese speakers it should be 7:00 now, so it might be worth repeating the test for the later afternoon, dunno, 18:00 or so. Or in the weekend.
Reworded rules for clarity:
- Min required length must be 8 chars (obligatory), but it should be 15 chars (recommended).
- Max length should allow at least 64 chars.
- You should accept all ASCII plus space.
- You should accept Unicode; if doing so, you must count each code as one char.
- Don’t demand composition rules (e.g. “u’re password requires a comma! lol lmao haha” tier idiocy)
- Don’t bug users to change passwords periodically. Only do it if there’s evidence of compromise.
- Don’t store password hints that others can guess.
- Don’t prompt the user to use knowledge-based authentication.
- Don’t truncate passwords for verification.
I was expecting idiotic rules screaming “bureaucratic muppets don’t know what they’re legislating on”, but instead what I’m seeing is surprisingly sane and sensible.
I can’t believe I’m considering moving away from Ubuntu after 20 years…
The good news is that all distros are pretty much similar to each other, so you can transpose most of those two decades of experience to any other distro that you might want to use. Typically the key differences are
The problem is that Ubuntu overuses snaps, even when there are completely acceptable .deb alternatives, that will perform consistently better; typically distros using appimage and flatpak don’t do the same.
That said if this isn’t a big deal for you Ubuntu might be still an option. As the saying goes, better the devil that we know.
Since your main priority is stability, I’d suggest either Debian Stable or Mint. Debian Stable is rock solid, but the software is ancient; Mint is a good compromise. They both have a nice package selection.
The reason why I don’t recommend Ubuntu itself is snaps. Huge downloads with lots of wasted disk space, wasted memory, less user control, mismatching themes, larger loading times… urgh.
Desktop environment is such a personal matter that it’s hard to say which one would be the best for you. I’m a big fan of MATE - it’s small, it’s nice, you can reasonably customise it without new extensions or applets. Xfce would be also a good performance-focused choice.
And that’s why means matter, not just the ends. If Twitter was banned under the premise of being a Nazi nest (as it is), it would be still banned. But for that you’d need solid legislation to force platforms to identify and kick out the Nazi. Not just an “ackshyually you need a representative, you don’t have one so Twitter isn’t operating here any more”.
“A poor person’s happiness never lasts” - local saying.
Pretty much. Once speakers start using the word, and expecting others to understand it, it’s already part of the lexicon of that language. Specially if you see signs of phonetic adaptation, like /ø/ becoming /u:/ in a language with no /ø/ (see: “lieu”) - and yet it’s exactly why people complain about those words.
And this sort of complain isn’t even new. Nor the backslash agianst it, as Catullus 84 shows for Latin and Greek.