I'm glad to see this change. This was already the case for GUI password prompts, and I'm happy to see terminals following suit.
This wasn't someone seeing Chesterton's fence and deciding to knock it down thoughtlessly. This is a change that someone can in fact think all the way through and say "yeah, this should be changed, it's an improvement and doesn't cause any meaningful reduction in security".
Think of it this way: there’s a button to show your actual password in the majority of applications nowadays.
`sudo` and `login` are I think the only two tools I use that don’t provide any feedback.
Otherwise my entire life is behind a password database that lets me see my password in plaintext and otherwise shows the length of it as it’s typed. KeepassXC.
If knowing how the length of your password makes it easy to crack you probably have other problems
It saves 1/Nth of the total time taken to brute force an N character password compared to starting from length 1. So any password where this is a significant fraction is so short that the time saved isn't really relevant.
So yes, "easier", technically. But not in any meaningful way.
No, not really. If you have people watching you so closely, there’s a good chance they can watch your fingers on the keyboard, too. Maybe you’re sharing your screen for a presentation, this might be slightly ill advised, but then, you should run such things in a VM or container and use silly demo passwords.
It really isn’t. The threat model is someone who can watch you type a sudo command, and has physical access to your computer to try to brute force combinations, or a way to access a backup of your hard drive or passwords file.
Knowing the length narrows down the search space some, but a meaningfully long password basically makes that knowledge useless, and again, it’s only useful if the approach they take is to try to physically possess your computer or obtain an encrypted backup.
A far more likely effort is going to be a spear fishing email, especially since if they have physical access to you they probably know a lot about you, and what services to spoof to get you to give them passwords, and so on.
Correct, it is not a meaningful reduction of security. In terms of information theory, the search-space reduction will not take make a strong password tractable. And that's leaving aside that you could already get that information via sound, or visually by looking at the keyboard. And GUIs already gave the length of the password, it was only some text-based applications that gave zero password feedback.
Conversely, making people more comfortable with security measures may well improve security; for instance, some people will have an easier time typing in longer and more complex passwords thanks to password feedback.
If your password is long enough it doesn’t matter if they know it is say 16 characters and if it isn’t long enough it also doesn’t matter because they can just brute force all the potential lengths up to it. So yes it is just security theater.
That's an argument for telling people the strength of their password, and warning them when setting a weak password. It's not an argument for decreasing usability in a fashion that will make people less comfortable typing long, complex passwords.
There's a great piece of software called "molly-guard", which intercepts calls to "poweroff" and "reboot" and similar. It checks if it's being invoked via an SSH session, and if so, it asks you to type the name of the system you're shutting down. That way, you never accidentally shut down a remote server when you meant to shut down your own system (or a different server).
I once accidentally rebooted the reverse proxy for all our production traffic. We got some very quiet two minutes while it came back up.
After that we installed molly-guard with a check for the number of active connections. Made it painless to reboot standby proxies and difficult to reboot active ones.
(We also instituted pairing on production proxy maintenance. I'm not a fan of pair programming but pair maintenance is great.)
I like telling junior hires about this incident because it teaches them that (a) anyone can make mistakes, (b) even serious mistakes usually aren't that dangerous, (c) you can learn a lot from mistakes with the right mindset, (d) we cannot prevent mistakes but with the right system design we can reduce their consequences.
> (We also instituted pairing on production proxy maintenance. I'm not a fan of pair programming but pair maintenance is great.)
It's a great opportunity to share knowledge and techniques and I very much recommend doing so. It's an important way to get people familiar and comfortable with what the documentation says. Or, it's less scary to failover a database or an archiving clutser while the DBA or an archive admin is in a call with you.
Also reminds me of an entirely funny culture shock for a new team member, who was on a team with a much worse work culture and mutual respect beforehand. Just 2-3 months after she joined, we had a major outage and various components and clusters needed to be checked and put back on track. For these things, we do exactly this pilot/copilot structure if changes to the system must go right.
Except, during this huge outage, two people were sick, two guys had a sick kid, one guy was on a boat on the northern sea, one guy was in Finland and it was down to 3 of the regulars and the junior. Wonderful. So we shoved her the documentation for one of the procedures and made her the copilot of her mentor and then we got to work, just calmly talking through the situation.
Until she said "Wait". And some combined 40 - 50 years of experience stopped on a dime. There was a bit of confusion of how much that word weighed in the team, but she did correctly flag an inaccuracy in procedure we had to adress, which saved a few minutes of rework.
I was using my company dev machine via Windows RDP remotely during Covid and installed Glasswire which by default blocks all traffic so I lost access. No one was there to uninstall it so I continued development in my personal machine.
Another fun one is disabling the network interface on a remote server. An acquaintance did that by mistake on a cloud VM running some core services, and the cloud provider had no virtual console for some reason. Ended up having to write off the VM and restore from backup. Fun day at the office.
Long ago, I succeeded once to cut my own access through SSH to a remote server, after some firewall changes. That of course has required a long trip to the server, for physical access.
However that was good, because after that I have always been extra careful at any changes that could affect the firewall in any way. (That is not restricted to changes in firewall rules, because there are systems where the versions of the firewall program and of the kernel must be correlated, so an inconsistent update may make the firewall revert to its default state of denying all connections.)
I previously managed a firewall via scripts which would automatically revert your update in 20 seconds unless interrupted. So if you botched it and lost access, you just had to sit tight for 20 seconds.
Hah, I once did “netplan try” on a prototype production machine. The new config wasn’t quite right (although not catastrophic in any respect) so I told it to roll back. Bye bye new machine.
Fortunately this was an exercise and we had BMC access, so no big deal. Except that we got yet another datapoint suggesting that netplan is not a high quality piece of software.
Last I checked, if you non-forcibly reboot a GCE instance via console or API and it does not shut itself down in a timely manner, there was literally no way to force it to turn off or hard-reboot so that your block storage instances get released. IIRC the last time I encountered this the process timed out eventually after some silly long wait.
And when you do that, you lose access to your bank, because bank apps routinely refuse to run on devices that leave the user in control (e.g. unlocked bootloader, rooted phone). Graphene and similar would be a much more acceptable solution if remote attestation of a locked bootloader were banned.
I really don't see the issue with waiting 24 hours. These protections in general seem very likely to help unsophisticated users. It really seems like a nothingburger to me personally. I was going to make an analogy to the ethics of getting vaccinated (and getting mildly ill of a day) to protect the immunity compromised members of the community, but even that is laughable because it underscores what a nothingburger this is (far more of the community is technologically unsophisticated than is immunocompromised, and what sophisticated users are being asked to do is closer to wearing a mask once for 24 hours).
You can always find justifications to erode all civil liberties. I think it's a major gap in the way history is being taught that people think that the reasons to remove liberties sound like overt evil mustache-twirling slogans. In reality they always talk about a danger that the benevolent overlord will keep you safe from.
All these changes are attacks on general purpose computing and computing sovereignty and personal control over one's data, and one's digital agency.
More and more apps won't run, again allegedly to keep you safe. You can't run your bank apps on your rooted and custom software. TPMs of desktop, everything needing approval. Yeah you may say tough luck, just use the web. But more and more banks sunset their web UI. It's apps only. And then you'll say "tough luck, start your own bank and offer this feature if you think there is customer demand". Or tough luck, win an election and then you can change the laws etc.
Yeah I'm aware that we can only watch from the sidelines. At least we can write these comments.
The new world will be constant AI surveillance of all your biosignals, age and ID verification, only approved and audited computation, all data and messaging in ID attached non e2e encrypted cloud storage and so on. And people will say it keeps you safe and you have nothing to fear if you are a law abiding person.
This would be less of an issue if there were an explicit regulatory mandate saying "businesses larger than X may not limit any consumer capabilities for interacting with their business in such a way that it can only be accessed by proprietary applications running on locked-down systems that a user cannot modify, control, or install their own software on. Offering to have a person handle that functionality on their behalf does not constitute an alternative to functionality made available via such an application". (With appropriate clear definitions for "locked-down", and other appropriate elaborations.)
I don't know that sounds pretty dumb on the whole. The key challenge is determine who is at fault in the event of a breach. I don't think it's reasonable to hold companies responsible for privacy while also requiring them to allow privacy to be invaded.
The current situation is that banks regularly require the use of an unmodified, unrooted Android or iOS device, which reinforces the duopoly and makes it impossible for anyone to compete. (Even emulating Android doesn't help, as emulated Android won't pass the checks banks do to make sure you don't have control of your device.)
That situation is not acceptable. Got something better than insults like "pretty dumb" to say about how to resolve this abuse of the two-player oligopoly in the mobile phone market?
You are uncritically repeating the party line from banks who claim it is necessary for security, without giving any rationale or supporting evidence, and coupling it with an insult.
> But they also failed to learn any lessons from X
Why do you believe that the developers of X failed to learn lessons from X when developing the replacement of X? Perhaps they learned lessons from X and decided to build it differently as a result?
Which is exactly what they did, as I understand it.
For example Wayland supports far more than just “generic computer screen”. I’ve heard it was designed to be able to handle systems either multiple very different displays. Like maybe a normal screen and an e-paper display.
I remember reading an article that mentioned the mess of screens in current cars would actually fit Wayland well.
Anyway, turns out computers really didn’t do that. We’re all still using one or more monitors that are mostly the same, with a couple of common aspect ratios.
Maybe they’ll be proven right. Maybe it’ll just be some extra stuff in the code forever.
Of course one of the ways you find out that you did something wrong was by doing it. So many comments online seem to just assume that the developers should’ve had the foresight to know everything they did that people don’t like or care about was wrong.
I feel real sympathy for both the developers and people with serious accessibility issues it has been a problem for.
But “beat up on Wayland” is practically a meme. An easy way to score points without looking at the big picture of how we got here.
> For example Wayland supports far more than just “generic computer screen”. I’ve heard it was designed to be able to handle systems either multiple very different displays. Like maybe a normal screen and an e-paper display.
The other common example is that wayland is well-suited to AR/VR 3D compositing, and X... isn't.
> I remember reading an article that mentioned the mess of screens in current cars would actually fit Wayland well.
It had better be well suited to cars, seeing as how it was significantly made for and by car companies. (I hear, at least; I'm told that it was significantly pushed forward precisely by companies developing automotive displays)
> Once you’re acquired you have to do what the boss says.
Or quit, and take the (Open Source) project and community with you. Companies sometimes discover this the hard way; see, for instance, the story of how Hudson became Jenkins.
The types of folks who make reimplemented game engines often do it as a labor of love towards the original. And the best companies often have great appreciation for their modding communities and preservationists. (Witness the good collaborations between some companies and SCUMMVM, for instance.) This may well have been a conversation that was entirely reasonable and respectful.
I just can't believe that given the outcome and the wording of the posts from the project. If there was respect here there would have been no threats. If there were no threats there would be no talk of "balancing commercial interests"
No, they don't. They own the game data, and the original game engine. They don't own the reimplemented Open Source game engine.
OpenTTD did not have to do anything here. It sounds like they had a very positive interaction with Atari, in which Atari is providing them with some support and collaboration, and in exchange for that, OpenTTD agreed to formalize the requirement for "you need to own the original game data" by having people on game stores purchase the original game through them before getting OpenTTD through them.
That seems like a pretty reasonable approach. It should be held up as a good model for collaboration. But it shouldn't be treated as "they have every right to [demand a] cease and desist".
Though it's no longer a clone, it literally was a clone when it first started (you were even supposed to supply your own totally legitimately acquired asset packs).
So it'd be pretty much impossible to claim the engine came about as a clean room implementation. And of course, even if maybe they could win a court case (honestly don't think they could) the mere threat of one would likely make openttd quit.
> you were even supposed to supply your own totally legitimately acquired asset packs
I don't have the impression that OpenTTD encouraged or sanctioned obtaining those assets illegitimately. They talked about how to extract them from the original game that you owned.
CorsixTH requires Theme Hospital assets but we didn't clone or otherwise steal anything that we ship, we require you to supply the assets precisely because we aren't. I presume that's true of OpenTTD as well. In the United States copyright protection for games covers the art and text but not the rules and Oracle vs. Google established reimplentations being fair even when exposing the same api. Truely novel game rules can be protected by patents per Nintendo.
Reverse engineering for compatibility, and implementation of a compatible system (as long as you don't copy the original) are not just legal, they're explicitly legally protected in many jurisdictions. You'll get in serious trouble if you copy the original, but there is specific case law supporting things like emulators. See, for instance, Sony v Connectix and Sega v Accolade.
But OpenTTD is explicitly a faithful copy of the original. It replicates the original product in appearance and behavior and is open about it. If you were to dig into source code history, mailing list archives, chat logs etc. I'm certain that you could find a lot of evidence to support this position.
Show a set of random persons gameplay video clips from TTD and OpenTTD in its default settings and ask them which one of the two games they are watching. They'll be struggling.
It is about the entirety of the product, not its parts.
That's the point of game engine reimplementations, but again OpenTTD has no original TTD worlds.
Simcity 2000/3000 and Lincity-NG can look pretty close at a distance too, the same with FreeCIV and Civilization 2000.
If the issue it's due to the menu layout and such that can be set with ease, GUI presets from original TTD and a 'new' one (as default) and call it done.
Arx Fatalis itself it's a Ultima Underworld inspired clone. It's more than obvious. Deus Ex it's a weird Shadowrun retelling with better hacking depictions replacing the magic shadow ruling overlods with a panopticon AI and ripping off every US conspiracy from the XFiles.
Both RPG's can be played in pretty much the same way: half stealth/half run and gun depending on your mood, augmentations, hacking to retrieve useful info, doing secondary errands, the cyberpunk theme...
Halo does the same with Marathon and Bioshock borrows a lot from System Shock.
It's... complicated; they own Transport Tycoon Deluxe, its code, its assets and its IP.
Back when OpenTTD first released, it was a decompile (?) of TTD that loaded the assets of the game itself. This was... legally dubious, since reverse engineering.
But over time they Ship of Theseus'd the game - all code rewritten from assembly to C/C++ (I don't know), open source asset packs, etc. It's still the same base game, same feel, etc but nothing of the original code or assets remain.
I don't know enough about IP law etc to judge whether Atari would have any leg to stand on in a court of law, but it would be Complicated to say the least.
You don't. This is the kind of problem created by vibe coding.
Escalate upwards, challenge the policy, cite this as an example. Also cite things like https://arxiv.org/abs/2511.04427 : "transient increase in project-level development velocity, along with a substantial and persistent increase in static analysis warnings and code complexity".
If the policy doesn't change, find a new company.
Now, all that said: it would also be a good idea to have better testing infrastructure that actually tests the services in concert and not just individually. That testing infrastructure will be useful for the humans who take over from the vibe coding and start cleaning up the mess.
This wasn't someone seeing Chesterton's fence and deciding to knock it down thoughtlessly. This is a change that someone can in fact think all the way through and say "yeah, this should be changed, it's an improvement and doesn't cause any meaningful reduction in security".
reply