The weird part is that password managers provide no way for you to copy and paste your passkeys.
The main feature of passkeys is that they can't be pasted into a website they shouldn't be pasted in to. That means you can't copy them, by design.
HN user
The weird part is that password managers provide no way for you to copy and paste your passkeys.
The main feature of passkeys is that they can't be pasted into a website they shouldn't be pasted in to. That means you can't copy them, by design.
Yes, that would be good! I got to 86, and on a macbook trackpad, and those fake scores are making my RSI flare up.
True. I think there are two new issues this cycle:
1. They are testing what the market will bear. Ubisoft's silly "quadruple-A game" rhetoric and executives saying "people will have to get used to $100 games" is them testing the water. This should pull back, as most people don't want games that cost that much, unless they're really amazing. They aren't (currently). I imagine this same thinking is going on in hardware-land.
2. Current RAM/GFx card prices are driving up prices all round. It should still be true that for the same spec, console components should get cheaper over time, but I can imagine it's less of an effect at the moment with all the AI data centres hoovering up manufacturing capacity.
That's one thing. The other is price. Consoles can be sold at a loss, particularly early in their 10-year cycle, when early on the loss is high, but close to the end of the cycle the loss is minimal, and so they appear much cheaper.
I've had a few OnePlus phones - currently a Nord 4 - and have always found them good value for money. Early OnePluses (I think I had a 2 or 3 originally) were incredible value. Also, very fast charging and almost stock Android are lovely features.
I don't understand why you don't like them, because you haven't said!
Any idea why they implemented it like that?
3D-Secure long predates apps, including in the UK. I had to work on a Government Gateway integration for local council payments in the mid 2000s that included 3D-Secure. I still see it today, although it normally now results in a ping to an app approval.
Indeed. It's the same principle[0] the other way too - start a timer from user typing for an autocomplete function and only refetch after the timer expires.
[0] https://developer.mozilla.org/en-US/docs/Glossary/Debounce
I've used Proton for a couple of years and have never had problems before today, so I think their engineering is of a high standard.
In fact, I applied for an Engineering Director role there not too long ago and they rejected me, so they must have extremely high standards!
Oh - that's interesting too! But I meant more as a frontend across various integrations a business might have. E.g. having a bot that tells you if your CI failed is currently likely surfaced inside Teams or Slack. Having an internal chat service feels like a big win so companies don't need to integrate private companies' tooling so deeply.
I like this article, but I would take some issue with the concept of the percentage of time taken up being a major issue.
If you go from taking 2 days to write some code and 20 minutes to type check (which does seem long, don't get me wrong, but still) to 10 minutes to prompt some code and 20 minutes to type check, that percentage increase to me isn't enough to justify switching.
You're still almost 2 days ahead, and converting those 20 minutes to 20 seconds are not going to make you ship a feature appreciably faster. But those types stand strong and I don't believe they can yet be replaced by an LLM believing they're correct.
Having said that, I also think that Haskell should massively speed things up. Having strong types if nothing else should surely produce some amazing type-checking speed wins.
Very good. I was wondering about this a while ago - lots of companies want something to aggregate notifications and perform simple bot actions, but don't necessarily want to lock into a chat provider. Having this as the frontend to a load of integrations (or even just internal chat) would be really interesting.
and can have access to an increasingly vast back catalogue of older games
By this I meant via a subscription.
I see what you mean, but I think gamers on a budget will cancel. Other gamers would've paid full price for 12 games and instead paid $15 each for 12 games.
So if you put your new game that you would have sold for $60-80 dollars to me directly and it translates to three weeks of engagement on your $15-ish/month (depending on level) subscription, it's hard to see how that is an economic win. Put that game on Gamepass in a year or two, sure, that can make sense, but on release?
I think that's what I thought it would be, too. XboX has a really good track record of backwards compatibility. I can (and do, occasionally) play 360 games on my series X.
A model where people can buy the latest games, can not only keep them but play them forever on future consoles, and can have access to an increasingly vast back catalogue of older games, seems like a huge win. And maybe each full price new game gets them a bit of a discount on their next month's game pass, to make it slightly better value than the playstation equivalent full priced game.
But they didn't seem to want to do anything like that.
Very interesting! How are those garages coordinated? Who designs and who commissions?
Some people will exaggerate one way, and some the other way. The internet is big and you can say, and substantiate, "people said" for any opinion you choose, and show that it was wrong later.
I think it's an 8% drop on the previous usage, not 8% of total compute drop.
That's fair enough - I see what you mean. I think I read the case I was thinking into the article. Now I re-read it, it is saying what you're saying, which does make a lot of sense.
Using types like this also means you can more easily avoid assignment errors, as everything will have a very specific type (e.g. Age instead of int).
This feels right, and I also have never done it (or had the guts to get others to do it).
The reason I've not is - say there's an optional field. Currently we call that null, probably, and check each time if it's there or not. I could instead make a type, like User and UserWithPhoneNumber. Should we be making types for each combination of present/absent fields? That can't be right.
The classic answer is to move the logic inside the domain object, or have a helper function outside the object, so you aren't constantly checking for field presence/absence, but are instead writing the logic once and calling some code.
I'm not sure in practice types can help with this. But I'd love to be proven wrong.
Thank you - great blog post.
Will Self[0] is going to love this.
Thanks - interesting. Very odd, though.
Forcing hand written should really not be necessary. It would be very cheap in terms of old computing hardware to set up a test room with old desktop PCs that have wired only NICs (with a network connection that goes to a switch in the same room with no uplink, connected to a decent size laser printer only), running something like lubuntu and libreoffice writer as a basic word processor.
Exams that only require paper, tables, and chairs can be done anywhere, and require minimal setup/set down, transport, or power, and no tech support.
I tried this with my CV, and it somehow scored me bonus points for GSoC!
BONUS POINTS: 5.0
------------------------------
Google Summer of Code (GSoC) participation: +5
Even though I've never done this, and don't claim to have done it in my CV.That is a very confusing state of affairs!
Why would you need to pay $40 for a PDF of a paper published almost a hundred years ago? What makes the paper not public domain?
I'm not saying that we shouldn't do security review of open source libraries, just saying that this situation puts a lot of pressure on the maintainers.
This is true, and worth saying, but it is also a problem of the OSS philosophy. All software is used at your own risk, so if maintainers want their software used they need to keep up, and the (true) promise of "more eyeballs means more secure software" has this downside built in.
But then "meant to" is doing the heavy lifting here. You could (and should) say that a JWT library is meant to default to secure.
I'm not the previous poster, but in my experience you can get a lot of mileage out of having dev teams (tediously, at least the first time) go through all potential vulnerabilities, decide how risky each one is based on likelihood and impact, and then get them to address the high/highs somehow (e.g. by upgrading a dependency, or writing extra code to guard against the issue, or fixing the issue if it's a home-grown vulnerability).
I'm not sure that's true. Jobs have moved overseas at a rapid rate in the past. What careers have been eliminated, and over what time period?