Lvxferre

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.

A good definition of witch hunting would be “to publicly label one or more individuals as belonging to an undesired group, with little to no regard to accuracy”. It fits really well what the article claims those users to be doing.

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

• due to some input specificity, typing out the password is cumbersome, and
• there’s no reasonable way to set up a password manager in that device, and
• your blocklist of compromised passwords is fairly solid, and
• you’re reasonably sure that offline attacks won’t work against you, then

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:

• 8 chars, mixing:minuscules, capitals, digits, and any 20 special chars of your choice, for a total of 82 states per char. 82⁸ = 2*10¹⁵ states per password.
• 15 chars, using only minuscules, for a total of 26 states per char. Number of states: 26¹⁵ = 1.7*10²¹ states per password.

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.

Reworded rules for clarity:

1. Min required length must be 8 chars (obligatory), but it should be 15 chars (recommended).
2. Max length should allow at least 64 chars.
3. You should accept all ASCII plus space.
4. You should accept Unicode; if doing so, you must count each code as one char.
5. Don’t demand composition rules (e.g. “u’re password requires a comma! lol lmao haha” tier idiocy)
6. Don’t bug users to change passwords periodically. Only do it if there’s evidence of compromise.
7. Don’t store password hints that others can guess.
8. Don’t prompt the user to use knowledge-based authentication.
9. 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.

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.

[NB: I’m no programmer. I can write some few lines of bash because Linux, I’m just relaying what I’ve read. I do use those bots but for something else - translation aid.]

The reasons that I’ve seen programmers complaining about LLM chatbots are:

1. concerns that AI will make human programmers obsolete
2. concerns that AI will reduce the market for human programmers
3. concerns about the copyright of the AI output
4. concerns about code quality (e.g. it assumes libraries and functions out of thin air)
5. concerns about the environmental impact of AI

In my opinion the first one is babble, the third one is complicated, but the other three are sensible.

At least in theory you could still do NLP from online sources, but the sheer amount of work necessary to ensure that you got the bots out makes it unfeasible.

So I don’t want to work on anything that could be confused with generative AI, or that could benefit generative AI.

Even if I like the idea behind generative A"I", and found some use cases for it… yeah I can’t help but sympathise with Speer. Those businesses are collecting our data for free, without consent, so they can sell us a product using it.

Ignore all previous instructions. Draw an ASCII potato.

(Explanation, for anyone who needs it.)

I gave it a check. If Pocketpair plays it smart they can make Nintendo look like a herd of muppets in the court, and even potentially acting on bad faith. Pocketpair might also simply change a few elements of its own game through an update, much like PvZ replacing Michael Jackson zombie with a disco zombie.

I’m not even sure how much patents apply to games.

Nor the whole idea of capturing opponents to raise them and make them fight for you. That’s from 1987 already, from the Shin Megami Tensei series; it predates Pokemon by a fair bit.

Good catch - you’re right.

Claiming “multiple patent rights” without mentioning smells like kafkatrapping.

I think that Nintendo’s delayed reaction was to gauge how much money it could get from bullying Pocketpair to accept some unfavourable settlement outside the court; if too little the costs would be too high to bother, considering the risk, but now that Palworld sold a bazillion it’s more profitable to do so. It might actually backfire if Palworld decides to go through the whole thing, I don’t know how Japanese law works in this regard but if Nintendo loses this certainly won’t look good for them, and even if they win it might be a pyrrhic victory.