8,217 karma · joined November 4, 2010
Or for that matter, that adding support for game controllers (something that has actually happened with Linux desktops) would led to curtailed development of non-controller parts.
I never said it was smart. Or dumb, for that matter. Just that many product teams have been made to merge testing responsibilities as an internal responsibility, in line with having end-to-end ownership of the product from development to its operational deployment. And usually without any dedicated test engineer member of that team to do this.
> It is only weird to have dedicated QA on your team if you don't give a fuck about releasing shit with bugs in it for the user to bump into.
Well, has the behavior of software companies led you to believe they care strongly about this? I always got the impression they cared more about either maximizing feature velocity given a certain team size, or minimizing labor cost for a given feature velocity.
But yes, before that it would be not at all unusual to have “test engineers” or other technical staff whose entire responsibility laid with setting up test environments and running QA of products. These people did not do product dev, though they may have been involved in writing supporting test platform libraries or even maintaining test infrastructure (like IBM Jazz).
Even today in the U.S. companies that haven’t fully jumped onto newer development practices probably still have QA and/or test departments.
It's not a command to compiler to stop generating code.
It's a permission slip that allows the compiler to assume that code that follows is dead code, eligible to be optimized out, including eliminating potentially dead stores and loads.
Which is to say, it's precisely what any other UB is, which is why deliberate use of UB is very bad idea.
This distinction exists, but not to the compiler. And the compiler is the thing building your binary. You can complain if you like about how UB that could potentially instead have been implementation-defined is UB instead.
But until then, the compiler will mangle your code either way, whether you feel it is fair or not.
Though, it would be better if programmers read deliberate instances of UB as if they literally said "std::unreachable()" at that point in the code, as that would better convey how the optimizer passes will see things after dozens of frontend and middle-end passes have run before it.
Agile manifesto coined a term for things that already existed. It didn’t create it from scratch, nor did it claim to. But W95 did employ methods we would call agile methods today.
Windows 95 significantly overhauled the desktop GUI metaphor, in a way that is still the skeletal structure of desktops today.
Its U/I design since Windows 3.11 came about because of agile, not in spite of it. https://socket3.wordpress.com/2018/02/03/designing-windows-9...
> We recognized that we needed much more opportunity to create a design, try it out with users (perhaps comparing it to other designs), make changes, and gather more user feedback. Our desire to abandon the waterfall model and opt for iterative design fortunately followed similar efforts in other areas of the company, so we had concrete examples of its benefits and feasibility.
You're right that you can't go start to finish on a design in a single 2-week sprint. But that's why you have a repeating series of sprints, you're not supposed to go from start to finish in a single sprint.
The Windows 95 team always had a shippable OS to demo internally to devs, QA, beta testers and users invited by the UX designers for usability testing. Just because you demo something to the product owner does not require that you then release the result immediately to end users. Decouple development from deployment and from release and you'll find agile methods can work just fine.
In this analogy, we human software devs are the artisanal homebuilders and the fancy LLMs are the robots.
And yes, there's quite a cost to build all the datacenters for all the AI that Big Tech believes that people will want. But as you mention, the cost savings are enormous for even despite that, and will make a much larger set of problems accessible to real software solutions, that previously either stayed on paper, in peoples' heads, or maybe an Excel sheet somewhere.
OK, so don’t buy their PR, and try it yourself.
But if you do this, you will find there is a lot of evidence for the economic argument.
I tested out Google Argon 4 release by having it build a Web app to replace a binder I have for reconciling payments with reimbursable expenses.
It did it, as well as I would have and in much less time. I just set it to high and supervised it, it cost about $2. Even if you throw in a “supervision cost” to account for the time I had to spend interacting with it, it was substantially cheaper than had I done it at normal salary rates. Probably 2 orders of magnitude cheaper, even.
But from the perspective of a potentially distributed ecosystem of apps and libraries as employed in practice in modern systems, it's actually harmful to interoperability.
Other libs/services/apps that touch the malformed JSON that this change would accept might be present in the overall system and crash on that data. The risk grows with the more components of the overall system that silently accept malformed data and allow the bad data to make its way deeper before it causes issues.
This is what “fail fast” was meant for, if something is going to cause problems in your system at some point in the future, make that “some point” happen ASAP, so that it is easier to identify and fix the source of the flaw.
In that case they made the right choice, as machines won't be inserting trailing commas or comments in the first place, and the risk of having consuming apps inadvertently accept invalid data would be high otherwise.
Turns out that tasks easily done by programming languages are best done by programming languages. Who knew?
JSON allowing frontends and backends to communicate in a way analogous to the "smart endpoints, dumb pipes" model for networking saved the Web. The XML adherents wanted the inverted model, which was always insanely difficult to reason about and led to entirely XML-specific security threats.
It would be one thing to stop shopping at Amazon because of how they treat their workers if you also stopped shopping at other companies whose workers are peeing in bottles behind the scenes. Do the things you buy get shipped at some point by truck-based logistics? If so, piss bottles are already involved, it is just that we were all blessedly unaware.
> Then you won't be able to use it with Netflix when they require attestation. How's that supposed to help?
That's my point. The issue is with Netflix forcing you to use passkeys + attestation, not with passkeys existing.
> The author explicitly compares passkeys with TOTP, and explains how relying parties cannot force you to use a specific TOTP provider, because TOTP providers are indistinguishable from the relying party perspective.
I used Okta Verify and MS Authenticator on purpose; they support “extensions” beyond their TOTP support which offer relying parties additional information about authentication events. If Netflix were willing to require atypical passkeys + attestation because passkeys were popular, they should logically be willing to require atypical TOTP + extensions because TOTP is popular. The apps to do this already exist.
I have government websites that already require me to use Okta Verify specifically, but I don’t go around saying this is the fault of TOTP for existing.
> In my 16 years on HN, this has been my most baffling conversation. I see your other comments on this same post, and you make good points there, I don't understand what's going wrong here.
We might just be talking past either other. I have been guilty of it before.
So the problem, then, is with Netflix, not with passkeys. Breaking passkeys to try to prevent some different harm from befalling you does not make sense. And the passkey provider can enforce the lack of attestation by refusing to support it.
Netflix could force you to use a chosen authentication provider to restrict that scenario. But, we already live in that world today, nothing in principle stops them from forcing you to use Okta Verify or Microsoft Authenticator in principle. Yet I do not see people using that as a reason to write articles about how OIDC 2.0 or TOTP is a trap.
I frequently do that myself on simple C++ programs just for compile time reasons alone, where I'll use stdio.h instead of std::iostream or std::format.
And I am not.
You’re trying to refute an argument I did not make.
They do not have to be cheaper than 2016. They have to be cheaper than what your business could otherwise string together paying current market prices. And they will be.
The invested time consistently into the things that were important to improve. If the art was good as-is (and it was), they didn’t waste time “perfecting” it further.
But as long as the gameplay itself still felt fuzzy or like there was friction, they spent time improving it up until their deadline. This was not a lack of project management, this was project management actually done well, for once.
In fact they accidentally optimized Super Mario 64 around its debug-mode performance, and shipped the game in that state, with debug symbols and everything. But they could get away with that because the game they shipped still landed in the performance budget they needed for the gameplay they were after.
They can negotiate better prices based on their scale, and even on their ability to internally source key components if needed.
E.g. if AWS/Microsoft/Google/Apple buy 80% of Micron's entire output it's probably at a much better price than the rest of us competing over the other 20% are going to get.
Yes you need to put thought into who you trust to provide password management but for most people having a professional third party help them improve how they use passwords will be a benefit to security overall.