I was surprised to see such a large performance improvement from shrinking the Object structure. What primarily drives this? My best guess is you can pack more Objects in a cache line
Every time this topic comes up I post a similar comment about how hallucinations in code really don’t matter because they reveal themselves the second you try to run that code.
That’s fascinating. I’d really enjoy hearing some more about that. Was this a team project? Were there tests? I feel like this would be really valuable as a sort of post mortem.
Lots of different teams and project. I am talking 30% of a 1k engineer department being feature frozen for months to try to dig out of the mess.
And yes there were tests. Tests do not even start to cut it. We are talking death through thousands deep cut.
This is btw not a single anecdote. My network of “we are here to fix shit” people are flooded with these cases. I expect the tech industry output to plummet starting soon.
Again, really interesting and I’ve love more details. I am at a company that has adopted code editors with AI and we have not seen anything like that at all.
That just sounds so extreme to me. Feature frozen for months is something I’ve personally never even heard of, I’ve never experienced anything like that. It feels kind of mind boggling that AI would have done that.
Nope. They had tested it. But to test, you have to be able to understand the failure cases. Which you have heuristics for based on how humans write code
These things are trained exactly to avoid this detection. This is how they get good grade. Humans supervising them is not a viable strategy.
I’d like to understand this better. Can you give an example of something a human reviewer would miss because it’s the kind of error a human code author wouldn’t make but an LLM would?
I’m with @Diana here. You test code, but testing does not guarantee the absence of bugs. Testing guarantees the absence of a specific bug that is tested for. LLM-generated code has a habit of failing in surprising ways that humans fail to account for.
I used AI primarily for generating test cases, specifically prompting for property tests to check the various properties we expect the cryptography to uphold. A test case found a bug.
“Those are scary things, those gels. You know one suffocated a bunch of people in London a while back?”
Yes, Joel’s about to say, but Jarvis is back in spew mode. “No shit. It was running the subway system over there, perfect operational record, and then one day it just forgets to crank up the ventilators when it’s supposed to. Train slides into station fifteen meters underground, everybody gets out, no air, boom.”
Joel’s heard this before. The punchline’s got something to do with a broken clock, if he remembers it right.
“These things teach themselves from experience, right?,” Jarvis continues. “So everyone just assumed it had learned to cue the ventilators on something obvious. Body heat, motion, CO2 levels, you know. Turns out instead it was watching a clock on the wall. Train arrival correlated with a predictable subset of patterns on the digital display, so it started the fans whenever it saw one of those patterns.”
“Yeah. That’s right.” Joel shakes his head. “And vandals had smashed the clock, or something.”
Hallucinated methods are such a tiny roadblock that when people complain about them I assume they’ve spent minimal time learning how to effectively use these systems—they dropped them at the first hurdle.
You imply that because one kind of hallucination is obvious, all hallucinations are so obvious that (per your next 3 paragraphs) the programmer must have been 1. trying to dismiss the tool, 2. inexperienced, or 3. irresponsible.
You describe this as a failing of the programmer that has a clear correction (and elaborate a few more paragraphs):
You have to run it yourself! Proving to yourself that the code works is your job.
It is, and I do. Even without LLMs, almost every bug I’ve ever committed to prod has made it past “run it yourself” and the test suite. The state space of programs is usually much larger than we intuit and LLM hallucinations, like my own bugs, don’t always throw exceptions on the first run or look wrong when read.
I think you missed the point of this post. It tells the story of figuring out where one hallucination comes from and claims LLMs are especially prone to producing hallucinations about niche topics. It’s about trying to understand in depth how the tool works and the failure mode that it produces hallucinations that looks plausible to inexperienced programmers; you’re responding with a moral dictum that the user is at fault for not looking at it harder. I’m strongly reminds me of @hwayne’s rebuttal of “discipline” advice (discussion).
Just because code looks good and runs without errors doesn’t mean it’s actually doing the right thing. No amount of meticulous code review—or even comprehensive automated tests—will demonstrably prove that code actually does the right thing. You have to run it yourself!
What does “running” the code prove?
Proving to yourself that the code works is your job. This is one of the many reasons I don’t think LLMs are going to put software professionals out of work.
So LLMs leave the QA to me, while automating the parts that have a degree of freedom and creativity to them.
Can you at least understand why some people are not that excited about LLM code assistants?
In a typed system, it proves that your code conforms to the properties of its input and output types, which is nice. In a tested system it proves whatever properties you believe your tests uphold.
So LLMs leave the QA to me, while automating the parts that have a degree of freedom and creativity to them.
QA was always on you. If you don’t enjoy using one, don’t? If you feel that it takes your freedom and creativity away, don’t use it. I don’t use LLMs for a ton of my work, especially the creative stuff.
In a typed system, it proves that your code conforms to the properties of its input and output types, which is nice. In a tested system it proves whatever properties you believe your tests uphold.
Which is at odds with the claim in the same sentence, that ‘comprehensive automated tests’ will not prove that code does the right thing. And yes, you can argue that the comprehensive tests might be correct, but do not evaluate the properties you expect the results to have, if you want to split hairs.
Evaluating code for correctness is the hard problem in programming. I don’t think anyone expected LLMs to make that better, but there’s a case to be made that LLMs will make it harder. Code-sharing platforms like Stack Overflow or Github at least provide some context about the fitness of the code, and facilitate feedback.
The article is supposed to disprove that, but all it does is make some vague claims about “running” the code (while simultaneously questioning the motives of people who distrust LLM-generated code). I don’t think it’s a great argument.
What did you think my article was trying to disprove?
It’s an article that’s mainly about all the ways LLMs can mislead you that aren’t as obvious as hallucinating a method that doesn’t exist. Even the title contains an implicit criticism of LLMs: “Hallucinations in code are the least dangerous form of LLM mistakes”.
If anything, this is a piece about why people should “distrust LLM-generated code” more!
Can you at least understand why some people are not that excited about LLM code assistants?
Because they don’t enjoy QA.
I don’t enjoy manual QA myself, but I’ve had to teach each myself to get good at it - not because of LLMs, but because that’s what it takes to productively ship good software.
I actually disagree a little bit here. QA’ing every bit of functionality you use is never going to scale. At some level you have to trust the ability of your fellow human beings to fish out bugs and verify correctness. And yes, it’s easy for that trust to be abused, by supply chain attacks and even more complicated “Jia Tan”-like operations.
But just like LLMs can be said to do copyright laundering, they also launder trust, because it’s impossible for them to distinguish example code from working code, let alone vulnerable code from safe code.
What I meant was something slightly different. Almost every piece of software that’s not a bootloader runs on a distributed stack of trust. I might trust a particular open source library, I might trust the stdlib, or the operating system itself. Most likely written by strangers on the internet. It’s curl | sudo bash all the way down.
The action of importing code from github, or even copy-pasting it from stack overflow, is qualitatively different from that of trusting the output of an LLM, because an LLM gives you no indication as to whether the code has been verified.
I’d go so far as to say the fact that an LLM emitted the code gives you the sure indication it has not been verified and must be tested—the same as if I wrote quicksort on a whiteboard from memory.
I think this post is more than just another “LLMs bad” post, though I did enjoy your response post as a standalone piece. The author ‘s co-worker figured out it didn’t work pretty quickly. It’s more interesting to me that the author found the source of the hallucination, and that it was a hypothetical that the author themselves had posed.
That’s why I didn’t link to the “Making o1, o3, and Sonnet 3.7 Hallucinate for Everyone” post from mine - I wasn’t attempting a rebuttal of that, I was arguing against a common theme I see in discussions any time the theme of hallucinations in code is raised.
I turned it into a full post when I found myself about to make the exact same point once again.
And that’s fair enough - in context I read your comment as a direct reply. I appreciate all the work you’ve been doing on sharing your experience, Simon!
asdf is a package manager dedicated to installing multiple versions of the same software and choosing which version is active. The packages it supports installing are mainly language runtimes like python, ruby, node, go, and so on.
In any particular terminal with a particular working directory, running a tool such as ruby will run only one of your installed versions. asdf doesn’t just have a global setting for which version this is: it can dynamically choose the correct version based on files in the source code of a project. It might find the version in an ecosystem-specific file that contains the language version, such as .ruby-version, or in asdf’s own file .tool-versions.
asdf was created to replace similar tools that manage multiple versions of only a single programming language. Examples of these tools: nodeenv, nvm, n, rvm, chruby, rbenv.
This asdf is a totally different project from the Lisp asdf, as discussed in this sibling thread.
It’s a package/version manager for various development environments. For instance, you can use it to install different versions of nodejs, and switch between them. There’s a pretty wide array of plugins for it; most things you can think of are installable via asdf.
We had some bad surprises with inconsistent data imports, where we thought the data was sound, but it wasn’t. Why did we think the data was good? Well we had foreign key checks in place to assure that, only to find out they are ignored by default.
That’s nice! However, that also means that it lets you generate an Index on a column which does not exists, it will just treat the column name as a constant string, creating an Index which matches none of the rows, thus is completely useless. We recognized our index not being used by using the excellent EXPLAIN QUERY PLAN.
That provides good resilience not only against software crashes, but even power interruption crashing your hardware (as long as your hard disk does not lie about syncing to the platter/flash). However, that comes at a tremendous performance hit for writes. Having an embedded database software crash resistant is good and important, but having it hardware crash resistant might not always be necessary. As usual, do your research, and make an informed decision what level of synchronous mode you need.
Finally: RTFM ;-). The SQLite documentation is one of the nicest, best written and best organized documentations I ever worked with. Its seriously great.
Not defaulting to STRICT and not enabling foreign key checks is purely for backwards compatibility. Maybe something like Rust editions should be there in SQLite, just for different sets of default values in SQLite. There could be “everything as it used to be” edition, and the “recommended things ’25” edition for example.
Don’t forget SQLite doesn’t support a load of ANSI standard commands with ALTER statements, so if you’re using a migrations framework, you need to do things like SQLAlchemy’s batch mode processing and COPY+MOVE migrations.
I have a tool to help with that: sqlite-utils, a CLI tool and Python library for implementing the “create a new table with the new structure, copy the data across, drop the old table, rename the new one in a single transaction” pattern:
I’ve had good luck with synchronous mode set to normal with WAL mode on. But again, may depend on your workloads. I use a pretty similar set of defaults as this person: https://kerkour.com/sqlite-for-servers
Edit: Didn’t realize someone posted that link further down. D’oh.
Notably, STRICT tables limit the data types you can use to just a handful. This may be fine for most cases, but you do lose some semantic power of using say, DATETIME columns.
But there’s a fly in the ointment: certain influential tech people really dislike them. According to DHH:
if you sign up for a service on Windows, and you then want to access it on iPhone, you’re going to be stuck (unless you’re so forward thinking as to add a second passkey, somehow, from the iPhone will on the Windows computer!)…
Disclaimer: I work at 1Password
People keep making this case, but this is only true if you cannot export/sync passkeys. There are password managers—1Password and even I think Apple’s Passwords—that will sync passkeys cross-platform. This shouldn’t be an issue in practice. And, yes, you can’t remember a passkey or easily write it down on paper but given the amount of work regular password management already is, “requiring” software to provide good UX isn’t the worst thing IMO.
1P definitely makes this experience better, but it’s certainly not the default experience for most people. There are people in my life who struggle with 2FA, especially around backing up tokens. I have a hard time imagining that I would be able to get them on board with passkeys, much less installing more software to make passkeys’ use easier.
On the contrary, passkeys require zero extra software and vastly simplify the experience for ordinary non-technical people. Now they don’t need to muck around with passwords anymore, they can just tap their finger or scan their face to log in. This is the first genuine usability improvement for online security in at least two decades.
Your post outlines what is essentially a way to coordinate (“sync”) passkeys using magic links. With that, yes, you can use multiple devices to your heart’s content.
Using magic links works in theory and likely in practice, but it isn’t foolproof either. I’ve seen setups where someone hasn’t yet signed into their email on a device or their email client opens up the wrong browser/etc. There’s rough edges with every approach.
My point is simply that the ideal UX is syncing one passkey across devices using, ideally, 1st party software with a great ootb experience. This is already possible. You’re absolutely right that in lieu of that, you could also use magic links as described to work around it.
A ‘foolproof in practice’ auth method doesn’t exist. So we must haggle about what is the best tradeoff between security and UX for the vast majority of end users who are non-technical, non-power users, and will never go for the hassle of maintaining password managers.
Magic Links are a great way to provide additional flexibility in your application’s authentication system. With Passage, you have the ability to create Magic Links that can be delivered in any way you like - custom email templates, in-app chat messages, or anything else you can think of. Embedding Magic Links in your marketing emails, reminder texts, or other mediums can greatly reduce user friction and increase conversion rates.
So we must haggle about what is the best tradeoff between security and UX for the vast majority of end users who are non-technical, non-power users
No. We can let the user decide. Instead, the arrogance with which some people and services (especially big cloud providers) push their agendas is precisely one of the reasons why people (including me) are very hesitant with passkeys. History has made us aware.
As I’ve said many times, for ordinary non-technical people, this is not the kind of decision that they care about nor want to make. Normal people just want secure accounts that are not extremely difficult to use. They are not going to set up password managers. Many don’t even bother to remember passwords; they just log in every time with ‘forgot password’.
For power users like yourself, you can just use a good password manager to store all your passkeys and never have to use magic links at all.
I personally don’t find it productive to engage in discussions about ‘arrogance’ and ‘agendas’. All the options are in front of you, you have complete freedom as a user. No one is locking you into anything. Not sure what ‘history’ you are ‘aware’ of, but if it’s something relevant to this discussion please feel free to make it instead of spreading FUD.
I personally don’t find it productive to engage in discussions about ‘arrogance’ and ‘agendas’. All the options are in front of you, you have complete freedom as a user.
Do I? Last time I checked GitHub forced me into 2FA, for zero increase in security since I already use a password manager, and I stored the second factor in my password manager for convenience.
Yes, but it’s zero increased security for you. For all the GitHub users who use the same password across N different sites, TOTP codes are a massive improvement to their security posture. Which, in turn, is good for everyone when you start to think about the supply-chain security risks.
It’s a 100% indisputable fact of life today that, if you have a user pick a password, some users are going to re-use passwords from other sites and/or use a very weak password. Passkeys bring the advantages of password managers to everyone else: it’s both way more secure because it’s a unique token for a single site (which is also significantly harder to phish for!), and it’s more convenient because it gets filled in for you. And, unlike, say, Chrome’s built-in password manager, it’s not something you can just ignore and do insecurely anyway.
Personally, rolling out passkeys has barely affected me at all (I’ll take a few seconds to set one up in 1Password if given the option on a site). But– hopefully– it’ll raise the bar for security for everyone else, preventing a lot of the actual practical attacks we’ve seen affect ordinary people.
It’s not black and white. Counterexample: person A uses github for their library X, person B relies on X. Now A loses access to their account and gives up. No further security updates for X unless B actively switches. Now you can claim that this is a rare scenario and I would agree.
Still, my feeling is that those pushing for passkeys are actively trying to talk down or hide the negative parts. The same for 2FA/MFA.
Furthermore, I suspect that the increased control and datamining is something those companies really like. That’s why so many companies only require a phone number. Or other data. Google employees dark patterns. When logging in, it ask you for your birthday and does not even allow you to reject just close the question. It seems like you are forced to give it to log in. However, you can actually just close the browser tab and you are already logged in.
Sorry, but these things take a away trust. At least for me, the burden is now on those services to proof that they are not having bad intentions. And right now, it looks to me like they have. Hence, I’m not willing to give them more power.
Well there you go. GitHub requires users to set up security factors, as is their right. And you the user can store the security factors in your favourite password manager, as is your right. Each party in the transaction has all the freedoms it needs to operate.
GitHub requires users to set up security factors, as is their right.
There’s a tension between their rights, and that of their users. I was lucky they even allowed TOTP, because from their UI I could clearly tell they preferred webauthn. And if one day they decide I need to use a passkey with remote attestation, where all the approved providers only accept an app that runs on an unrooted Android or Apple phone?
Call me paranoid, but since that’s currently the best way I know of to actually secure an account for most users, they have a justification for going this route. And then you could say I am totally free to use any other service instead of GitHub… if it wasn’t for the obvious next step: policies of not pulling in code from sources other than properly secured providers, where “properly” means MFA of the kind I’ve just outlined.
Feels like the old freedom/security tradeoff all over again.
You realize that even if passkeys didn’t exist, the policymakers would still exist and find other ways to make and enforce these policies, right? What you are arguing about has nothing to do with passkeys except in the most tangential sense.
What you are arguing about has nothing to do with passkeys except in the most tangential sense.
There is in the standard itself (Webauthn I believe?) support for cryptographic verification of the passkey provider (the entity/software/dongle that generated the key pair). Which means the standard supports remote attestation. While remote attestation has some legitimate uses, putting it right there in the standard facilitates abusive generalisation.
So there’s your tangent: the standard is an enabler, and I don’t like enablers.
So if I understand correctly you don’t like companies that manufacture kitchen knives? Because they are enablers of people who can do bad things with kitchen knives?
Irrelevant for ordinary users, and missing the point. Read my post, with my strategy backing up passkeys is an obsolete way of thinking when you just log in on any new device with a magic link.
So we must haggle about what is the best tradeoff between security and UX for the vast majority of end users who are non-technical, non-power users, and will never go for the hassle of maintaining password managers.
Does this require not providing any alternative for those who do use a password manager? Like, if there’s an alternative, then some non-technical users are gonna use it and get pwned, so we’d better not?
But this is just my design and recommendation. Others can obviously implement whatever they please. I just happen to think that the added complexity would not be worth it.
Oh I agree it’s far the the default experience, and I’d say far from the ideal experience. My early work on 1Password was its onboarding process and I’ve sat in on enough user interviews/user research that I’ll be the first to say there’s plenty users don’t understand.
Frankly, I think that assertion was an overreach. He explained later that RPs (Relying Parties, ie service providers) could block KPXC because it doesn’t properly verify the user when required to:
the lack of identifying passkey provider attestation (which would allow RPs to block you,
That is a choice that RPs can legitimately make for user security reasons. But I don’t see how they can block specific passkey managers by name.
Attestation existing in the protocol at all seems dangerous to me: inevitably, someone will start whitelisting specific providers “for user security” and then users start having to spread passkeys among providers and non-big-tech providers get frozen out.
someone will start whitelisting specific providers “for user security” and then users start having to spread passkeys among providers and non-big-tech providers get frozen out.
It is an allowlist. I have a FIDO2 level 2 token that is certified and not accepted because a-trust blocks it. There is also no browser or software implementation, only specific keys are allowed.
It allows for third party veto in case of missing required security attestation. Security standards sometimes need to be strict. This is no different from sites disabling TLS <1.3 for security reasons.
Can you explain to me how I can configure my TLS library such that it only allows connections from Google implementations of TLS 1.3 running on Android, and blocks any implementations written by someone other than Google?
This would be equivalent to attestation – instead of requiring a correct implementation of an open protocol, attestation requires a specific device or manufacturer.
That’s incorrect. Attention just says what level of verification was done and what the authenticator was. Attention in and of itself doesn’t require anything; it’s inert data. It’s up to each Relying Party (ie service account provider) to decide what attention requirements they want to enforce.
And if you think about it for a second, it’s obvious why. WebAuthn is a web protocol. The web is built on top of open access protocols where anyone is supposed to be able to participate. If passkey SDK providers start recommending that it be locked down to specific hardware, that will quickly break the web. And nobody wants that.
You seem to be projecting your incentives on to me. Like I said earlier, I don’t care either way because I think this ‘problem’ is way overblown and only a theoretical concern. Relying Parties ie account providers don’t have an incentive to go out of their way to block large swathes of potential users over which devices they’re using. That’s a great way to kill business. And in practice most people are using devices which will have certified authenticators anyway.
Close, but it’s actually ‘we reliably verified that the claimed user is the one making the request’. So actually the opposite of ‘not under end-user control’.
we reliably verified that the claimed user is the one making the request
This is advertisement.
We reliably verified which device model (and possibly which firmware revision) claims to have checked that the user intended to use the passkey.
This is probably close to the technical definition.
We are sure the user was forced to use a device where neither data availability nor user identification policies take user’s preferences, needs, and priorities.
Is how the accepted device list for attestations will be implemented 99% of time, and I would like to see the remaining cases.
Like I said previously, I don’t see how a specific passkey manager can get blocked. The attestation just says whether user verification was done or not. It doesn’t say what the password manager is (as far as I know).
“Attestation” sounds like the kind of remote attestation sometimes demanded of some specific services.
For instance, you get hired in this security company, and they mandate a second factor with a USB dongle. The dongle has 2 private keys: one for you, that could be changed or reset at any time, and one for itself, that comes with a certificate that the device had been manufactured by this or that company.
Remote attestation would be that when you plug your key, the IT system not only asks for your key, it also asks your dongle to certificate the public half, and since the dongle is configured to provide certificates only for keys that it generated itself (that’s a promise of the dongle manufacturer), your company knows for sure your private key can’t leave the dongle, and thus you’re really logging in with the dongle.
Now it makes sense for companies, because leaking employee credentials doesn’t just harm the employee, it may harm the company itself. In this case you may not want to rely on the goodwill or conscientiousness of the employee, and just mandate they use the company issued dongle. That is much less of an issue with public-facing services, where when an account is compromise, the damage tend to be confined to that account.
Now replace “dongle” by “ID provider”, point out that GitHub repository or NPM package compromise can easily have far reaching consequences, and you have your foot in the “oligopolies in the name of consumer protection” door.
(You can try it yourself, there is no way to enroll 1password or a similar thing, it needs to be one of those hardware tokens. They even denylist old yubikeys by firmware version)
someone will start whitelisting specific providers “for user security”
That’s not possible at scale. The ‘someone’ would have to go to every Relying Party and get them to accept the whitelist. The decision is up to each Relying Party ie account service provider what attestation/authenticator they will accept. So your bank might decide to accept only certain known and certified ones, while your ecommerce site might accept others.
But again, I think we are getting too bogged down in the weeds here. For the majority of ordinary, non-technical people, who will use their platforms’ built-in passkey management, all this will work completely fine.
Awesome work, this really fills a niche that I think is a bit underserved. Reminds me of my own nnote, which is even more minimalistic. I’ve bounced off vimwiki, Roam, Notion, Obsidian, Logseq (though I still use it for D&D notes), and I keep a paper bullet journal and have for almost ten years, but there’s just something awesome about being able to open a note, splat your context onto the page, and then be able to search and send it trivially forever after, without any ceremony.
An enabling factor is that I use Syncthing extensively, so adding another folder to sync is no trouble.
When I first wrote this, I definitely said to myself “man, I bet someone will see this and say ‘that could just be a bash script’”, and wouldn’t ya know, someone’s already gone and done it :)
Looking at your repo, I’m a bit curious: how do you decide whether a note is worthy of being “monthly”, rather than “daily”, for example?
It’s an interesting suggestion, and one I thought about. The reason I didn’t do this is that a hindrance to writing something down is having picked a name that collides with another note. This is why quicknotes open displays the date when two notes have duplicate titles: to help differentiate between them.
With that said, I can see why for some people that might be desirable, and I’d be open to considering it further if you really want it; feel free to open an issue. There are a couple of asterisks that come along with it.
When it comes to taking notes, I have found no better substitute than a notebook at my desk. (Please bear in mind I am not prescribing this for everyone. I am describing what works for me.)
There are several reasons I have found this to be better than taking notes in the shell, org-mode, random text files, and many other mind-mapping/note-taking software packages that exist out there. (I’ve tried many of them.)
My notebook is immediately present and easy to find. It’s always within reach.
Writing it down on paper helps me remember it. More often than not, once I write it down, I remember it reasonably well.
It makes me think about why I am writing it down and whether it matters. This sounds trite, but it’s really hard to express how many times the act of pausing my current work to write something down has resulted in me realizing that I could actually do something else to accomplish what I was doing.
Having either a small pile of notes on my desk or a collection of “notes to self” in my notebook clustered together gives me immediate feedback on the backlog of things I either wanted to do or had to follow up on.
I can’t speak for anyone else, but a notebook at my side has been one of the most useful tools when I’m working.
I too am stuck with this analog method. While I sometimes run into the irritating fact that I can’t copy/paste from a notebook, it’s the only way that has stuck around for the past years with me. All the digital variants get too spread out, are too much work to get organized or get lost during some migration or the other. There is also just too much choice for digital solutions (org-mode, neuron, obsidian, mac notes, google notes, onenote, …).
Writing things does come with the proven benefit that writing things down is better for remembering them than typing things.
Personally I have:
A5 notebook for work related notes
A5 notebook for my own “bullet journal” based note taking
Tiny pocket notebook that I basically carry with me everywhere.
I do also have the habit to use post-it notes to integrate some zettelkasten behavior into these notebooks.
Honestly, I wish I could do this My problem is that a) my handwriting is horrid, to the point the notes can be useless to me b) I need to copy/paste enough snippets that having a digital notes system is useful for me.
You sound like a younger me. If you wish you could do it, take it from me, you can.
I, too, tried building my own computerized notes system and failed — in the era of “GTD”. I remember the older folks at the startup at the time laughing at me a little. They’d all done it themselves. It’s a rite of passage.
Nowadays, I have my A5 notebook on me at almost all times and just do my thinking on paper. I had to learn some more things to get comfortable with it— not thinking too hard about it; caring less about mess (it’s just paper); etc — and one of those things was indeed my penmanship. It still sucks, but it sucks less now (and I don’t recommend this path necessarily, especially for your wallet, but it worked for me) by switching to fountain pens for a while.
(I could write a whole diatribe on why cursive sucks but cursive made sense in its time, and continuing its teaching absent a fountain pen is a cargo cult. See also two spaces after a full stop.)
You’ve done well with the code and the vibe; and if I’m fully honest, a thing by which I can best manage my code snippets (your second point) is indeed something I lack a bit. I’ve long wanted a nouveau searchable/personal pastebin but just haven’t gotten around to writing one — imho, with all these sorts of tools, the direct command tooling is super important: capture has to be free and (auto-)organization on the ingest side a complex problem. That’s why you’ve got a vibe with the command line, by the by.
Take this all with a full grain of salt— what works for you works for you and don’t change it. I think the thing my coworkers of old were laughing about is how personal it turns out to be (and that’s okay! No package, software or otherwise, is for everybody)
For what it’s worth, I do both. I write many notes on paper, but created a handwriting-friendly “link” mechanism that allows creating links between digital and paper notes. It works well, and I get the benefits of both worlds.
I assign a number to my spiral notebooks, and number all my pages. So if I want to create a link to notebook 005 page 47, it looks like this: [[005-0047 Optional Note Title Here]].
All my digital notes have a unique ID that looks like 2025-01-14 Some Title Here, so if I want to create a link to a digital note on paper I write that ID inside [[ ]].
And lastly, I have a digital note describing all my physical notebooks, so I have an entry there like,
005: spiral notebook on bedroom bookcase
This makes things very easy to find, both physically and digitally.
I appreciate the thought :) It’s been a point of improvement for a long time, but I have a diagnosed fine motor skills disorder that makes it difficult.
Thank you so very much for sharing. Xe have been toiling hard to rebuild xir task and project management systems for months and crunched hard on consolidating around index cards last week. Comforting to have that choice affirmed here.
The only way to ensure a lack of digital distractions is to get away from digital devices, after all.
Thus my surprise on some_list += x modifying some_list in place (unlike some_list = some_list + x)
Huh. I wasn’t sure I followed, but yup.
>>> x = [1, 2, 3]
>>> print(id(x))
4302531904
>>> x = x + [4]
>>> print(id(x))
4302529536
>>> x += [5]
>>> print(id(x))
4302529536
Does anyone know why, assuming x is a mutable object, Python doesn’t handle x = x + <whatever> by modifying x in place? Wouldn’t that be more efficient—at least in the sense of creating fewer objects for the garbage collector to deal with?
>>> x = [1, 2]
>>> y = x
>>> x = x + [3]
>>> x
[1, 2, 3]
>>> y
[1, 2]
I expect y to be [1, 2] here. And indeed, that’s precisely what I was expecting from x += [3], but it does modify in place:
>>> x = [1, 2]
>>> y = x
>>> x += [3]
>>> x
[1, 2, 3]
>>> y
[1, 2, 3]
Contrast with Ruby:
irb(main):001> x = [1, 2]
=> [1, 2]
irb(main):002> y = x
=> [1, 2]
irb(main):003> x += [3]
=> [1, 2, 3]
irb(main):004> x
=> [1, 2, 3]
irb(main):005> y
=> [1, 2]
Part of my discovery in this post was that it is possible to make Python work this way. Here’s a demonstration:
>>> class RubyList(list):
... def __iadd__(self, rhs):
... return self + rhs
...
>>> x = RubyList([1, 2])
>>> y = x
>>> x += [3]
>>> x
[1, 2, 3]
>>> y
[1, 2]
On the other hand, you couldn’t ask Ruby to behave like Python: x += y strictly means x = x + y, so you can only overload the x + y bit, meaning the closest you could get would be to change all additions to modify self, but that’s quite different to only changing add-and-assign.
Part of my discovery in this post was that it is possible to make Python work this way.
It’s hardly a discovery, it’s the default behaviour of the language. list has an override to __iadd__ specifically to do something else.
Also sadly the std team decided to do the same thing when they added | to dicts. Which makes at least some sense from the pov that it already did that on sets, but still…
From the article’s explanation, an implementation of += has the chance to return lhs or a new object to the lvalue. So + also has both options for its result. But naively I think = is unaware of the fact that its rhs was created from an expression involving its lhs.
I’m surprised this behavior on lists exists at all. Isn’t it unsafe to mutate that list in place if it’s not uniquely owned? Is there a check?
If by “unsafe” you mean “not thread-safe”, the GIL ensures you won’t produce a data race by mutating a list in one thread while reading it in another (though of course you’re not immune to race conditions). += is not defining a unique operation either, .extend() is also a method on list which does the same thing.
I meant more generally, in the sense of just changing a list someone else might be expecting to stay the same.
With an extend method I might guess that’s what happening and I could avoid it, but since some of us didn’t know that += isn’t the same as =…+ in this one type’s case, it struck me as some level of footgun.
That’s just par for the course in Python - shared mutability is everywhere, and usually hidden quite insidiously.
I think this is where a lot of the managed, imperative languages threw the baby out with the bathwater. Manual memory management and pointers are unsafe, so replace them with a GC? Good. Let’s also pretend to the user that indirection doesn’t exist at all while still having shared mutability? Very bad.
Indeed, that’s what I felt was footgun-y too. I was aware of extend()s behaviour, and I choose otherwise for a reason. Spelunking CPython a bit, we can see that the collections abstract base class MutableSequencedefines__iadd__ as self.extend(values); self, so it’s very clearly considered The Python Way to be like this!
Well for starters they do not hardcode root credentials for the database into the client :)
Mobile app APIs would typically identify the user from otherwise untrusted requests (via, e.g. a password, but more sophisticated methods are used in practice), validate the request on the server, and then use the server’s private keys to access a third party.
You cannot check that your client is really your app over the internet without really good remote attestation (that will eventually be broken), but you can check that our user is your user.
Edit: In this case however, the mobile R1 client was /not/ the issue and did not have hardcoded keys. Their backend applications, of which the source code was apparently leaked as per the story, however did. The proper approach would have been to isolate production keys to the production environment, and forbid dev access to them.
This is a poorly solved problem. OAuth was designed for server-to-server communications and then extended to support browser-based flows, but I don’t think we’ve ever had a good approach to doing this based just on software installed on end-user devices.
Back in the day I pulled apart the Flickr Upoadr and discovered that I could use it to get access to peoples’ accounts if they’ed previously trusted the Uploadr just by reusing their hard-coded keys. It’s been almost 20 years and while in theory we could use secure enclaves or something we generally just don’t.
I’ve seen patterns using short-lived direct access keys where the remote service allows issuing them. The client authenticates to the first-party service API, which then contacts the third-party service API for a temporary credential with limited authorization scope and passes that credential to the client. The client can then talk to the third-party API directly for a brief period of time. The client should never possess a shared key, except perhaps for unmetered, read-only services.
Heh, I’m in your camp that err != nil is good(tm), but I still prefer the use of Testify. I think this mostly comes down to the fact that I think the benefits of err != nil (i.e. obvious control flow, forced error handling), are not as necessary in small contained tests. t.fatalF already breaks control flow by doing a panic under the covers, so I don’t see an assert function as being very different.
I think it depends on what aspect of Context you’re looking for. Context.WithValue could likely be replaced with an ETS table (or a GenServer w/ a Map behind it). I’ve seen that done before, but I don’t know if I’d do it for request context.
Plug handles this by storing values in the Conn struct.
We’ve been trying to do this hand-rolled dynamic scoping for suspension/context in Scala with gears… it’s a small experiment right now, but with implicit parameters they seem to be fairly handy. (in short, implicit parameters are parameters that, when not explicitly passed, will be searched in the current scope based on the types of the values declared as “givens”)
A friend of mine once cautioned me against using a sequence as a synthetic key. “One day when the server crashes, it will be impossible to tell what rows belong to what tables.” He recommended I use GUIDs instead. This advice saved his bacon at least once but I can’t imagine the scenario he feared recurring today.
Sometimes a natural key arises that you want to leverage and you should. With cascade, updating a primary key isn’t the concern it once was, assuming the primary key didn’t leak outside your database—some do and some don’t. But I wouldn’t follow the academic advice of fishing around to generate a large compound natural primary key if there weren’t any good candidates.
At the same time, I do want the schema enforcing as much validity as possible. I don’t trust the applications to get it right, I would rather they explode when someone does something insane than the database accept it.
Different domains are different; most of my work is with a fairly small number of fairly sophisticated and forgiving users. I would probably do it differently if I were facing a large customer base of inexperienced users. All advice is contingent.
Whatever the fear (not quite sure either!), a GUID solves it since it will only appear as a key in one place, or not at all. I guess if you could link arbitrary objects ..? Contrast with your usual serial integer keys where you can have user 1, product 1, site 1, message 1, image 1, … I think a much younger me might’ve once or twice applied the wrong key to the wrong table, with some fun results.
I wish I could but it never made a lot of sense to me. He was a FoxPro guy in the 80s and early 90s; I assume the problem scenario had something to do with handling corrupt files where you found the IDs but couldn’t tell what columns they belonged to.
The only real option left was that my modem had been hacked, but who was the attacker? I queried the owner of the IP address and found that it belonged to DigitalOcean. Strange. That definitely didn’t belong to my ISP.
An aside, I’ve actually seen legitimate ISP pages hosted on DO IPs. My last job had a dev box on site, and used ATT as an ISP. Querying for a non-existent domain on it returned such an address.
I enjoy a good call-out of contemporary web design as much as anyone, but if a fussy registration form and slow navigation are the biggest complaints then this is probably not even the worst website launched this week.
The author is invited to try using TurboTax to fill out a complex US tax return[0], or navigate a Japanese government site that blocks non-Safari browsers and uses stateful POST for navigation[1], or use a smartphone to view a page with grey 8pt fonts that disables zoom[2].
[0] TurboTax is infamous for adding 5-10 second intermissions at arbitrary points to make it seem like their servers are thinking very hard about your tax calculations, with the occasional upsell sprinkled in. A moderately complex return can take an entire day of wall-clock time, most of it spent hunting some field validation error across the entire UI surface.
[1] Chrome’s auto-translation mode can switch back to the original page without a reload, but Safari’s can’t. Reloading a page that uses state-machine POST requests for navigation will result in an unrecoverable error state.
[2] The ability to disable core functionality, including zoom and right-click, is easily one of the most user-hostile “features” ever added to browsers.
TurboTax is infamous for adding 5-10 second intermissions at arbitrary points to make it seem like their servers are thinking very hard about your tax calculations, with the occasional upsell sprinkled in. A moderately complex return can take an entire day of wall-clock time, most of it spent hunting some field validation error across the entire UI surface.
Oh damn. I thought the hunting down some field validation error was just me being unlucky.
I don’t know why I keep using this piece of shit service. The only thing it has going for it that some of my data is already there, but entering them again somewhere else probably take less than just clicking “skip” on all the upsell BS.
Please recommend alternatives. It’s not even about the price. I just don’t want to be treated like trash by the tax filling company, while I’m already treated like trash by IRS which already has all these stupid forms and knows fully well exactly how much should I pay, but will fine me if I I screw up anything.
If you live outside the US, alternatives won’t let you use them. It’s a lot cheaper than paying a human, but boy does it suck to use. The UX cherry on top tho is when you go to pay you have 2 options: 1) pay out of your return or 2) pay with a credit card. Option 1 is straight not available if your address is outside the US (why?). Option 2 requires that your credit card is registered with a US address (why?). This was my second year calling my mother like I was a teenager 2 decades ago asking for lunch money to help pay the TurboTax filing fee. Naturally you don’t get shown the payment screen until after you have poured hours into filling out all their forms too.
It’s not the worst experience in the world if you have a simple to moderately complex return to just use Free File Fillable Forms. The worst part is data entry; the forms itself are better documented than any program.
This is awesome! I look forward to its development. To me, the killer feature of Insomnia was “request chaining”; it was super useful for hacking on APIs with timed tokens. Are you planning on that making a return (or is it there, and hiding)?
My only concern about */v2 is that those not “in the know” will continue to use the old version. I imagine it’s going to be a bit of a “which one do I use?” moment for new developers. I do hope that there’s some sort of static analysis that warns you to use /v2 packages when available (perhaps only for new code, but I don’t know how one would detect that)
I think the plan is to eventually mark the old package as deprecated at which point various tools will point it out. But they didn’t want to mark the old one as deprecated in the same release as introducing the new one, because that’s annoying for Go code that supports multiple Go releases.
It’s an interesting approach, for sure. I definitely like the idea of not necessarily introducing more tools than needed.
With things like this, I’m always a bit wary of “magic”. You may know how it works as the person who installed the package, but down the road when someone else inherits it, it may not be so obvious that csvbase-client is what’s providing this scheme to Python. Just my 2c
I suppose both the question of how much magic is being introduced by this - and how much is an acceptable level - is a matter of taste.
Any abstraction layer that is transparent is vulnerable to the same criticism really - whether it’s HTTP proxies, or DNS. If it can be enabled/disabled without a code change it’s never going to be clear from the code that it’s enabled/disabled :)
I learned from someone on mastodon that I’m not the only person to have thought of using fsspec this way. HuggingFace also provide a driver for fsspec. So there is that evidence, at least, to suggest that I’m not completely bonkers :)
I also try to avoid “magic”, especially in languages where there’s so much potential for magic like Python. I’d argue that the automatic registration of fsspec providers is too much magic. After all “explicit is better than implicit” is the second line of the Zen of Python.
This looks neat. I just picked up a small LiveView project and definitely felt myself running into the “is there a more idiomatic way to do this” barrier quite quickly, particularly around UX subtleties like the author mentions. I eventually came to the conclusion that LiveView isn’t mature enough to have anything that’s super idiomatic, but this does seem like an interesting compromise.
For now, I’ve just added a top-of-screen loader while state is changing, which for my little hobby project is likely more than sufficient
I was surprised to see such a large performance improvement from shrinking the Object structure. What primarily drives this? My best guess is you can pack more Objects in a cache line
They mention in the post that it ends up being able to fit into a register. That possibility is pretty huge, I’d imagine.
Makes sense! The high probability was a piece I was missing.
Every time this topic comes up I post a similar comment about how hallucinations in code really don’t matter because they reveal themselves the second you try to run that code.
This time I’ve turned that into a blog post: https://simonwillison.net/2025/Mar/2/hallucinations-in-code/
As the person that saw 6 months of copilot kill so many systems due to the accumulation of latent hallucinations… Yeah. No.
That’s fascinating. I’d really enjoy hearing some more about that. Was this a team project? Were there tests? I feel like this would be really valuable as a sort of post mortem.
Lots of different teams and project. I am talking 30% of a 1k engineer department being feature frozen for months to try to dig out of the mess.
And yes there were tests. Tests do not even start to cut it. We are talking death through thousands deep cut.
This is btw not a single anecdote. My network of “we are here to fix shit” people are flooded with these cases. I expect the tech industry output to plummet starting soon.
Again, really interesting and I’ve love more details. I am at a company that has adopted code editors with AI and we have not seen anything like that at all.
That just sounds so extreme to me. Feature frozen for months is something I’ve personally never even heard of, I’ve never experienced anything like that. It feels kind of mind boggling that AI would have done that.
Did developers spend six months checking in code that they hadn’t tested? Because yeah, that’s going to suck. That’s the premise of my post.
Nope. They had tested it. But to test, you have to be able to understand the failure cases. Which you have heuristics for based on how humans write code
These things are trained exactly to avoid this detection. This is how they get good grade. Humans supervising them is not a viable strategy.
I’d like to understand this better. Can you give an example of something a human reviewer would miss because it’s the kind of error a human code author wouldn’t make but an LLM would?
I’m with @Diana here. You test code, but testing does not guarantee the absence of bugs. Testing guarantees the absence of a specific bug that is tested for. LLM-generated code has a habit of failing in surprising ways that humans fail to account for.
This isn’t really my experience unless you just say “write tests”. ex: https://insanitybit.github.io/2025/02/11/i-rolled-my-own-crypto
I used AI primarily for generating test cases, specifically prompting for property tests to check the various properties we expect the cryptography to uphold. A test case found a bug.
“Those are scary things, those gels. You know one suffocated a bunch of people in London a while back?”
Yes, Joel’s about to say, but Jarvis is back in spew mode. “No shit. It was running the subway system over there, perfect operational record, and then one day it just forgets to crank up the ventilators when it’s supposed to. Train slides into station fifteen meters underground, everybody gets out, no air, boom.”
Joel’s heard this before. The punchline’s got something to do with a broken clock, if he remembers it right.
“These things teach themselves from experience, right?,” Jarvis continues. “So everyone just assumed it had learned to cue the ventilators on something obvious. Body heat, motion, CO2 levels, you know. Turns out instead it was watching a clock on the wall. Train arrival correlated with a predictable subset of patterns on the digital display, so it started the fans whenever it saw one of those patterns.”
“Yeah. That’s right.” Joel shakes his head. “And vandals had smashed the clock, or something.”
You imply that because one kind of hallucination is obvious, all hallucinations are so obvious that (per your next 3 paragraphs) the programmer must have been 1. trying to dismiss the tool, 2. inexperienced, or 3. irresponsible.
You describe this as a failing of the programmer that has a clear correction (and elaborate a few more paragraphs):
It is, and I do. Even without LLMs, almost every bug I’ve ever committed to prod has made it past “run it yourself” and the test suite. The state space of programs is usually much larger than we intuit and LLM hallucinations, like my own bugs, don’t always throw exceptions on the first run or look wrong when read.
I think you missed the point of this post. It tells the story of figuring out where one hallucination comes from and claims LLMs are especially prone to producing hallucinations about niche topics. It’s about trying to understand in depth how the tool works and the failure mode that it produces hallucinations that looks plausible to inexperienced programmers; you’re responding with a moral dictum that the user is at fault for not looking at it harder. I’m strongly reminds me of @hwayne’s rebuttal of “discipline” advice (discussion).
What does “running” the code prove?
So LLMs leave the QA to me, while automating the parts that have a degree of freedom and creativity to them.
Can you at least understand why some people are not that excited about LLM code assistants?
In a typed system, it proves that your code conforms to the properties of its input and output types, which is nice. In a tested system it proves whatever properties you believe your tests uphold.
QA was always on you. If you don’t enjoy using one, don’t? If you feel that it takes your freedom and creativity away, don’t use it. I don’t use LLMs for a ton of my work, especially the creative stuff.
Which is at odds with the claim in the same sentence, that ‘comprehensive automated tests’ will not prove that code does the right thing. And yes, you can argue that the comprehensive tests might be correct, but do not evaluate the properties you expect the results to have, if you want to split hairs.
Evaluating code for correctness is the hard problem in programming. I don’t think anyone expected LLMs to make that better, but there’s a case to be made that LLMs will make it harder. Code-sharing platforms like Stack Overflow or Github at least provide some context about the fitness of the code, and facilitate feedback.
The article is supposed to disprove that, but all it does is make some vague claims about “running” the code (while simultaneously questioning the motives of people who distrust LLM-generated code). I don’t think it’s a great argument.
Ah, I see what you mean. Yes, I don’t think that “running” code is sufficient testing for hallucinations.
What did you think my article was trying to disprove?
It’s an article that’s mainly about all the ways LLMs can mislead you that aren’t as obvious as hallucinating a method that doesn’t exist. Even the title contains an implicit criticism of LLMs: “Hallucinations in code are the least dangerous form of LLM mistakes”.
If anything, this is a piece about why people should “distrust LLM-generated code” more!
Ah, if you restrict ‘hallucinations’ to specifically mean non-extant functions or variables, then I can see where you’re coming from.
Because they don’t enjoy QA.
I don’t enjoy manual QA myself, but I’ve had to teach each myself to get good at it - not because of LLMs, but because that’s what it takes to productively ship good software.
I actually disagree a little bit here. QA’ing every bit of functionality you use is never going to scale. At some level you have to trust the ability of your fellow human beings to fish out bugs and verify correctness. And yes, it’s easy for that trust to be abused, by supply chain attacks and even more complicated “Jia Tan”-like operations.
But just like LLMs can be said to do copyright laundering, they also launder trust, because it’s impossible for them to distinguish example code from working code, let alone vulnerable code from safe code.
That’s fair - if you’re working on a team with shared responsibility for a codebase you should be able to trust other team members to test their code.
You can’t trust an LLM to test its code.
What I meant was something slightly different. Almost every piece of software that’s not a bootloader runs on a distributed stack of trust. I might trust a particular open source library, I might trust the stdlib, or the operating system itself. Most likely written by strangers on the internet. It’s
curl | sudo bashall the way down.The action of importing code from github, or even copy-pasting it from stack overflow, is qualitatively different from that of trusting the output of an LLM, because an LLM gives you no indication as to whether the code has been verified.
I’d go so far as to say the fact that an LLM emitted the code gives you the sure indication it has not been verified and must be tested—the same as if I wrote quicksort on a whiteboard from memory.
I think this post is more than just another “LLMs bad” post, though I did enjoy your response post as a standalone piece. The author ‘s co-worker figured out it didn’t work pretty quickly. It’s more interesting to me that the author found the source of the hallucination, and that it was a hypothetical that the author themselves had posed.
That’s why I didn’t link to the “Making o1, o3, and Sonnet 3.7 Hallucinate for Everyone” post from mine - I wasn’t attempting a rebuttal of that, I was arguing against a common theme I see in discussions any time the theme of hallucinations in code is raised.
I turned it into a full post when I found myself about to make the exact same point once again.
And that’s fair enough - in context I read your comment as a direct reply. I appreciate all the work you’ve been doing on sharing your experience, Simon!
This doesn’t really explain what ASDF is or does. Nor does the project web page.
I vaguely recall reading about it some years ago in the context of Lisp and Common Lisp, but this seems either to be something different or a sibling.
Can anyone explain what it is to a non-specialist?
asdf is a package manager dedicated to installing multiple versions of the same software and choosing which version is active. The packages it supports installing are mainly language runtimes like
python,ruby,node,go, and so on.In any particular terminal with a particular working directory, running a tool such as
rubywill run only one of your installed versions. asdf doesn’t just have a global setting for which version this is: it can dynamically choose the correct version based on files in the source code of a project. It might find the version in an ecosystem-specific file that contains the language version, such as.ruby-version, or in asdf’s own file.tool-versions.asdf was created to replace similar tools that manage multiple versions of only a single programming language. Examples of these tools: nodeenv, nvm, n, rvm, chruby, rbenv.
This asdf is a totally different project from the Lisp asdf, as discussed in this sibling thread.
Thanks! That was much clearer. I appreciate the explanation.
It’s a package/version manager for various development environments. For instance, you can use it to install different versions of nodejs, and switch between them. There’s a pretty wide array of plugins for it; most things you can think of are installable via asdf.
Thanks. TBH as a non-programmer these days I only understood a little of that, though…
Ah sorry, I didn’t read non-specialist as non-programmer. Sounds like you got it from the sibling though :)
We recently started using SQLite for a work project, and found some surprising behavior too. Here is what I feel was our most important insights:
STRICT tablesEXPLAIN QUERY PLAN.ANALYZEis your friendman 1 sync)Not defaulting to
STRICTand not enabling foreign key checks is purely for backwards compatibility. Maybe something like Rust editions should be there in SQLite, just for different sets of default values in SQLite. There could be “everything as it used to be” edition, and the “recommended things ’25” edition for example.Don’t forget SQLite doesn’t support a load of ANSI standard commands with ALTER statements, so if you’re using a migrations framework, you need to do things like SQLAlchemy’s batch mode processing and COPY+MOVE migrations.
I have a tool to help with that:
sqlite-utils, a CLI tool and Python library for implementing the “create a new table with the new structure, copy the data across, drop the old table, rename the new one in a single transaction” pattern:I’ve had good luck with synchronous mode set to normal with WAL mode on. But again, may depend on your workloads. I use a pretty similar set of defaults as this person: https://kerkour.com/sqlite-for-servers
Edit: Didn’t realize someone posted that link further down. D’oh.
Notably, STRICT tables limit the data types you can use to just a handful. This may be fine for most cases, but you do lose some semantic power of using say, DATETIME columns.
Disclaimer: I work at 1Password
People keep making this case, but this is only true if you cannot export/sync passkeys. There are password managers—1Password and even I think Apple’s Passwords—that will sync passkeys cross-platform. This shouldn’t be an issue in practice. And, yes, you can’t remember a passkey or easily write it down on paper but given the amount of work regular password management already is, “requiring” software to provide good UX isn’t the worst thing IMO.
1P definitely makes this experience better, but it’s certainly not the default experience for most people. There are people in my life who struggle with 2FA, especially around backing up tokens. I have a hard time imagining that I would be able to get them on board with passkeys, much less installing more software to make passkeys’ use easier.
On the contrary, passkeys require zero extra software and vastly simplify the experience for ordinary non-technical people. Now they don’t need to muck around with passwords anymore, they can just tap their finger or scan their face to log in. This is the first genuine usability improvement for online security in at least two decades.
You’re right that you don’t need any additional software, but the point of GP was that additional software solves problems with the OOTB experience.
GP’ assertion:
Is incorrect. And you can read my post to see why.
Your post outlines what is essentially a way to coordinate (“sync”) passkeys using magic links. With that, yes, you can use multiple devices to your heart’s content.
Using magic links works in theory and likely in practice, but it isn’t foolproof either. I’ve seen setups where someone hasn’t yet signed into their email on a device or their email client opens up the wrong browser/etc. There’s rough edges with every approach.
My point is simply that the ideal UX is syncing one passkey across devices using, ideally, 1st party software with a great ootb experience. This is already possible. You’re absolutely right that in lieu of that, you could also use magic links as described to work around it.
A ‘foolproof in practice’ auth method doesn’t exist. So we must haggle about what is the best tradeoff between security and UX for the vast majority of end users who are non-technical, non-power users, and will never go for the hassle of maintaining password managers.
EDIT: here’s what Passage (by 1Password) documentation says: https://docs.passage.id/complete/magic-links
No. We can let the user decide. Instead, the arrogance with which some people and services (especially big cloud providers) push their agendas is precisely one of the reasons why people (including me) are very hesitant with passkeys. History has made us aware.
As I’ve said many times, for ordinary non-technical people, this is not the kind of decision that they care about nor want to make. Normal people just want secure accounts that are not extremely difficult to use. They are not going to set up password managers. Many don’t even bother to remember passwords; they just log in every time with ‘forgot password’.
For power users like yourself, you can just use a good password manager to store all your passkeys and never have to use magic links at all.
I personally don’t find it productive to engage in discussions about ‘arrogance’ and ‘agendas’. All the options are in front of you, you have complete freedom as a user. No one is locking you into anything. Not sure what ‘history’ you are ‘aware’ of, but if it’s something relevant to this discussion please feel free to make it instead of spreading FUD.
Do I? Last time I checked GitHub forced me into 2FA, for zero increase in security since I already use a password manager, and I stored the second factor in my password manager for convenience.
Yes, but it’s zero increased security for you. For all the GitHub users who use the same password across N different sites, TOTP codes are a massive improvement to their security posture. Which, in turn, is good for everyone when you start to think about the supply-chain security risks.
It’s a 100% indisputable fact of life today that, if you have a user pick a password, some users are going to re-use passwords from other sites and/or use a very weak password. Passkeys bring the advantages of password managers to everyone else: it’s both way more secure because it’s a unique token for a single site (which is also significantly harder to phish for!), and it’s more convenient because it gets filled in for you. And, unlike, say, Chrome’s built-in password manager, it’s not something you can just ignore and do insecurely anyway.
Personally, rolling out passkeys has barely affected me at all (I’ll take a few seconds to set one up in 1Password if given the option on a site). But– hopefully– it’ll raise the bar for security for everyone else, preventing a lot of the actual practical attacks we’ve seen affect ordinary people.
It’s not black and white. Counterexample: person A uses github for their library X, person B relies on X. Now A loses access to their account and gives up. No further security updates for X unless B actively switches. Now you can claim that this is a rare scenario and I would agree.
Still, my feeling is that those pushing for passkeys are actively trying to talk down or hide the negative parts. The same for 2FA/MFA.
Furthermore, I suspect that the increased control and datamining is something those companies really like. That’s why so many companies only require a phone number. Or other data. Google employees dark patterns. When logging in, it ask you for your birthday and does not even allow you to reject just close the question. It seems like you are forced to give it to log in. However, you can actually just close the browser tab and you are already logged in.
Sorry, but these things take a away trust. At least for me, the burden is now on those services to proof that they are not having bad intentions. And right now, it looks to me like they have. Hence, I’m not willing to give them more power.
Oh, I do agree with you here. They have a point, and that’s precisely the problem.
Well there you go. GitHub requires users to set up security factors, as is their right. And you the user can store the security factors in your favourite password manager, as is your right. Each party in the transaction has all the freedoms it needs to operate.
There’s a tension between their rights, and that of their users. I was lucky they even allowed TOTP, because from their UI I could clearly tell they preferred webauthn. And if one day they decide I need to use a passkey with remote attestation, where all the approved providers only accept an app that runs on an unrooted Android or Apple phone?
Call me paranoid, but since that’s currently the best way I know of to actually secure an account for most users, they have a justification for going this route. And then you could say I am totally free to use any other service instead of GitHub… if it wasn’t for the obvious next step: policies of not pulling in code from sources other than properly secured providers, where “properly” means MFA of the kind I’ve just outlined.
Feels like the old freedom/security tradeoff all over again.
You realize that even if passkeys didn’t exist, the policymakers would still exist and find other ways to make and enforce these policies, right? What you are arguing about has nothing to do with passkeys except in the most tangential sense.
There is in the standard itself (Webauthn I believe?) support for cryptographic verification of the passkey provider (the entity/software/dongle that generated the key pair). Which means the standard supports remote attestation. While remote attestation has some legitimate uses, putting it right there in the standard facilitates abusive generalisation.
So there’s your tangent: the standard is an enabler, and I don’t like enablers.
So if I understand correctly you don’t like companies that manufacture kitchen knives? Because they are enablers of people who can do bad things with kitchen knives?
Ah, at last we’re talking trade-offs! My opinion here is that putting remote attestation in the standard does more harm than good.
Conversely, I believe allowing end-to-end encryption (the kind governments can’t wiretap ever), does more good than harm.
Quite a few things stayed accessible exactly until it became very cheap to make them inaccessible, though.
And good web security posture was inaccessible to most ordinary people until it became accessible with passkeys.
Good passkey security posture, for which availability is included, is not available to ordinary people.
Passkeys are a couple of years old at this point. Passwords are decades old. Give it a minute.
This is a lie. «Whether you can back up the passkey» will only become a simple question if the answer is «no, you are beholden to the vendor»
Irrelevant for ordinary users, and missing the point. Read my post, with my strategy backing up passkeys is an obsolete way of thinking when you just log in on any new device with a magic link.
Does this require not providing any alternative for those who do use a password manager? Like, if there’s an alternative, then some non-technical users are gonna use it and get pwned, so we’d better not?
Password managers can already save passkeys. Power users are already well covered here.
Sounds cool. One remaining snag though: can I opt out of email recovery? Chose my own availability/breach risk tradeoff?
In my design, no. It’s passkeys + magic links.
But this is just my design and recommendation. Others can obviously implement whatever they please. I just happen to think that the added complexity would not be worth it.
Oh I agree it’s far the the default experience, and I’d say far from the ideal experience. My early work on 1Password was its onboarding process and I’ve sat in on enough user interviews/user research that I’ll be the first to say there’s plenty users don’t understand.
And yet, when keepassxc tried to export passkeys:
(From https://github.com/keepassxreboot/keepassxc/issues/10407#issuecomment-1994182200)
Frankly, I think that assertion was an overreach. He explained later that RPs (Relying Parties, ie service providers) could block KPXC because it doesn’t properly verify the user when required to:
That is a choice that RPs can legitimately make for user security reasons. But I don’t see how they can block specific passkey managers by name.
Attestation existing in the protocol at all seems dangerous to me: inevitably, someone will start whitelisting specific providers “for user security” and then users start having to spread passkeys among providers and non-big-tech providers get frozen out.
That is already happening. The Austrian governmental ID maintains a limited set of passkeys (all hardware) that can be used. If you try to enroll a different one it will be refused. https://www.oesterreich.gv.at/id-austria/haeufige-fragen/allgemeines-zu-id-austria.html#fido-compatible
You mean it will be rejected?
I suspect GP meant refused.
Sorry I meant “refused”. Fixed it.
This is not an allowlist, it’s an example of conforming hardware. The FAQ answer says:
If you follow that link it shows how most browsers already support it. So the hardware list is not really relevant.
It is an allowlist. I have a FIDO2 level 2 token that is certified and not accepted because a-trust blocks it. There is also no browser or software implementation, only specific keys are allowed.
Support “it”? The it in question is allowing me to use my own hardware, without a third party veto.
The protocol allows for third party veto by design.
It allows for third party veto in case of missing required security attestation. Security standards sometimes need to be strict. This is no different from sites disabling TLS <1.3 for security reasons.
Can you explain to me how I can configure my TLS library such that it only allows connections from Google implementations of TLS 1.3 running on Android, and blocks any implementations written by someone other than Google?
This would be equivalent to attestation – instead of requiring a correct implementation of an open protocol, attestation requires a specific device or manufacturer.
That’s incorrect. Attention just says what level of verification was done and what the authenticator was. Attention in and of itself doesn’t require anything; it’s inert data. It’s up to each Relying Party (ie service account provider) to decide what attention requirements they want to enforce.
Typical passkey implementation guides just recommend that attestation be set to
preferredorrequiredon initial registration. They don’t recommend that specific devices be allowlisted. See eg https://simplewebauthn.dev/docs/packages/server#guiding-use-of-authenticators-via-authenticatorselectionAnd if you think about it for a second, it’s obvious why. WebAuthn is a web protocol. The web is built on top of open access protocols where anyone is supposed to be able to participate. If passkey SDK providers start recommending that it be locked down to specific hardware, that will quickly break the web. And nobody wants that.
Great, if it’s not meant to be used that way, it should be no problem to remove it from the protocol.
I have no opinion either way. Maybe you should take it up with W3C!
You’re the one who cares about passkey adoption. This is the biggest blocker.
Maybe you should?
It’s just deleting sections 6.5 and 8 from https://w3c.github.io/webauthn/#sctn-defined-attestation-formats
You seem to be projecting your incentives on to me. Like I said earlier, I don’t care either way because I think this ‘problem’ is way overblown and only a theoretical concern. Relying Parties ie account providers don’t have an incentive to go out of their way to block large swathes of potential users over which devices they’re using. That’s a great way to kill business. And in practice most people are using devices which will have certified authenticators anyway.
Any way you look at it, this is a moot point.
«Security attestation» is slang for «proof of not being under end-user control» (unlike TLS version)
Close, but it’s actually ‘we reliably verified that the claimed user is the one making the request’. So actually the opposite of ‘not under end-user control’.
This is advertisement.
This is probably close to the technical definition.
Is how the accepted device list for attestations will be implemented 99% of time, and I would like to see the remaining cases.
You seem to misunderstand what attestation is. It’s got nothing to do with the user.
The only information that attestation demonstrates is who manufactured the device making the request.
Like I said previously, I don’t see how a specific passkey manager can get blocked. The attestation just says whether user verification was done or not. It doesn’t say what the password manager is (as far as I know).
“Attestation” sounds like the kind of remote attestation sometimes demanded of some specific services.
For instance, you get hired in this security company, and they mandate a second factor with a USB dongle. The dongle has 2 private keys: one for you, that could be changed or reset at any time, and one for itself, that comes with a certificate that the device had been manufactured by this or that company.
Remote attestation would be that when you plug your key, the IT system not only asks for your key, it also asks your dongle to certificate the public half, and since the dongle is configured to provide certificates only for keys that it generated itself (that’s a promise of the dongle manufacturer), your company knows for sure your private key can’t leave the dongle, and thus you’re really logging in with the dongle.
Now it makes sense for companies, because leaking employee credentials doesn’t just harm the employee, it may harm the company itself. In this case you may not want to rely on the goodwill or conscientiousness of the employee, and just mandate they use the company issued dongle. That is much less of an issue with public-facing services, where when an account is compromise, the damage tend to be confined to that account.
Now replace “dongle” by “ID provider”, point out that GitHub repository or NPM package compromise can easily have far reaching consequences, and you have your foot in the “oligopolies in the name of consumer protection” door.
This is completely wrong and not at all how passkeys work. Completely irrelevant.
The attestation says which device was used on enrollment. ID Austria as mentioned in another comment here blocks all but a handful of dongles: https://www.oesterreich.gv.at/id-austria/haeufige-fragen/allgemeines-zu-id-austria.html#fido-compatible
(You can try it yourself, there is no way to enroll 1password or a similar thing, it needs to be one of those hardware tokens. They even denylist old yubikeys by firmware version)
That’s not possible at scale. The ‘someone’ would have to go to every Relying Party and get them to accept the whitelist. The decision is up to each Relying Party ie account service provider what attestation/authenticator they will accept. So your bank might decide to accept only certain known and certified ones, while your ecommerce site might accept others.
But again, I think we are getting too bogged down in the weeds here. For the majority of ordinary, non-technical people, who will use their platforms’ built-in passkey management, all this will work completely fine.
Syncing passkeys with 1P is a good experience. A little better than syncing passwords. And I think that’s the most we’re going to get out of passkeys.
Awesome work, this really fills a niche that I think is a bit underserved. Reminds me of my own nnote, which is even more minimalistic. I’ve bounced off vimwiki, Roam, Notion, Obsidian, Logseq (though I still use it for D&D notes), and I keep a paper bullet journal and have for almost ten years, but there’s just something awesome about being able to open a note, splat your context onto the page, and then be able to search and send it trivially forever after, without any ceremony.
An enabling factor is that I use Syncthing extensively, so adding another folder to sync is no trouble.
Thank you for your kind words!
When I first wrote this, I definitely said to myself “man, I bet someone will see this and say ‘that could just be a bash script’”, and wouldn’t ya know, someone’s already gone and done it :)
Looking at your repo, I’m a bit curious: how do you decide whether a note is worthy of being “monthly”, rather than “daily”, for example?
my rules are basically:
i use telescope,
fd, andrgvery extensively so the hierarchy is mostly there to keep record of when i made stuff and prevent collisions.A curated selection of my current notes:
As you can see, I’m idiosyncratic to the extreme, but the tool supports me in that.
Suggestion: remove the new / open flag. If the note exists, open it; otherwise, create it.
It’s an interesting suggestion, and one I thought about. The reason I didn’t do this is that a hindrance to writing something down is having picked a name that collides with another note. This is why
quicknotes opendisplays the date when two notes have duplicate titles: to help differentiate between them.With that said, I can see why for some people that might be desirable, and I’d be open to considering it further if you really want it; feel free to open an issue. There are a couple of asterisks that come along with it.
I filed the issue.
When it comes to taking notes, I have found no better substitute than a notebook at my desk. (Please bear in mind I am not prescribing this for everyone. I am describing what works for me.)
There are several reasons I have found this to be better than taking notes in the shell,
org-mode, random text files, and many other mind-mapping/note-taking software packages that exist out there. (I’ve tried many of them.)I can’t speak for anyone else, but a notebook at my side has been one of the most useful tools when I’m working.
I too am stuck with this analog method. While I sometimes run into the irritating fact that I can’t copy/paste from a notebook, it’s the only way that has stuck around for the past years with me. All the digital variants get too spread out, are too much work to get organized or get lost during some migration or the other. There is also just too much choice for digital solutions (org-mode, neuron, obsidian, mac notes, google notes, onenote, …).
Writing things does come with the proven benefit that writing things down is better for remembering them than typing things.
Personally I have:
I do also have the habit to use post-it notes to integrate some zettelkasten behavior into these notebooks.
Honestly, I wish I could do this My problem is that a) my handwriting is horrid, to the point the notes can be useless to me b) I need to copy/paste enough snippets that having a digital notes system is useful for me.
You sound like a younger me. If you wish you could do it, take it from me, you can.
I, too, tried building my own computerized notes system and failed — in the era of “GTD”. I remember the older folks at the startup at the time laughing at me a little. They’d all done it themselves. It’s a rite of passage.
Nowadays, I have my A5 notebook on me at almost all times and just do my thinking on paper. I had to learn some more things to get comfortable with it— not thinking too hard about it; caring less about mess (it’s just paper); etc — and one of those things was indeed my penmanship. It still sucks, but it sucks less now (and I don’t recommend this path necessarily, especially for your wallet, but it worked for me) by switching to fountain pens for a while.
(I could write a whole diatribe on why cursive sucks but cursive made sense in its time, and continuing its teaching absent a fountain pen is a cargo cult. See also two spaces after a full stop.)
You’ve done well with the code and the vibe; and if I’m fully honest, a thing by which I can best manage my code snippets (your second point) is indeed something I lack a bit. I’ve long wanted a nouveau searchable/personal pastebin but just haven’t gotten around to writing one — imho, with all these sorts of tools, the direct command tooling is super important: capture has to be free and (auto-)organization on the ingest side a complex problem. That’s why you’ve got a vibe with the command line, by the by.
Take this all with a full grain of salt— what works for you works for you and don’t change it. I think the thing my coworkers of old were laughing about is how personal it turns out to be (and that’s okay! No package, software or otherwise, is for everybody)
For what it’s worth, I do both. I write many notes on paper, but created a handwriting-friendly “link” mechanism that allows creating links between digital and paper notes. It works well, and I get the benefits of both worlds.
Can you explain more what you mean with the link mechanism? Sounds like something i would find useful
I assign a number to my spiral notebooks, and number all my pages. So if I want to create a link to notebook 005 page 47, it looks like this:
[[005-0047 Optional Note Title Here]].All my digital notes have a unique ID that looks like
2025-01-14 Some Title Here, so if I want to create a link to a digital note on paper I write that ID inside[[ ]].And lastly, I have a digital note describing all my physical notebooks, so I have an entry there like,
This makes things very easy to find, both physically and digitally.
Thats such a good idea! Thanks for sharing, if i start doing more handwritten notes i will steal this :)
Your handwriting will improve if you use it, just have patience.
I’m aware this won’t solve part b, but it will solve part a.
I appreciate the thought :) It’s been a point of improvement for a long time, but I have a diagnosed fine motor skills disorder that makes it difficult.
you get some (maybe most) of the benefits of note-taking by writing the note, not by reading it
Thank you so very much for sharing. Xe have been toiling hard to rebuild xir task and project management systems for months and crunched hard on consolidating around index cards last week. Comforting to have that choice affirmed here.
The only way to ensure a lack of digital distractions is to get away from digital devices, after all.
Huh. I wasn’t sure I followed, but yup.
Does anyone know why, assuming
xis a mutable object, Python doesn’t handlex = x + <whatever>by modifyingxin place? Wouldn’t that be more efficient—at least in the sense of creating fewer objects for the garbage collector to deal with?It’d be very surprising for this case:
I expect
yto be[1, 2]here. And indeed, that’s precisely what I was expecting fromx += [3], but it does modify in place:Contrast with Ruby:
Part of my discovery in this post was that it is possible to make Python work this way. Here’s a demonstration:
On the other hand, you couldn’t ask Ruby to behave like Python:
x += ystrictly meansx = x + y, so you can only overload thex + ybit, meaning the closest you could get would be to change all additions to modify self, but that’s quite different to only changing add-and-assign.It’s hardly a discovery, it’s the default behaviour of the language.
listhas an override to__iadd__specifically to do something else.Also sadly the std team decided to do the same thing when they added
|to dicts. Which makes at least some sense from the pov that it already did that on sets, but still…As in, I discovered it for myself, not the whole world.
From the article’s explanation, an implementation of += has the chance to return lhs or a new object to the lvalue. So + also has both options for its result. But naively I think = is unaware of the fact that its rhs was created from an expression involving its lhs.
I’m surprised this behavior on lists exists at all. Isn’t it unsafe to mutate that list in place if it’s not uniquely owned? Is there a check?
If by “unsafe” you mean “not thread-safe”, the GIL ensures you won’t produce a data race by mutating a list in one thread while reading it in another (though of course you’re not immune to race conditions). += is not defining a unique operation either, .extend() is also a method on list which does the same thing.
I meant more generally, in the sense of just changing a list someone else might be expecting to stay the same.
With an extend method I might guess that’s what happening and I could avoid it, but since some of us didn’t know that += isn’t the same as =…+ in this one type’s case, it struck me as some level of footgun.
That’s just par for the course in Python - shared mutability is everywhere, and usually hidden quite insidiously.
I think this is where a lot of the managed, imperative languages threw the baby out with the bathwater. Manual memory management and pointers are unsafe, so replace them with a GC? Good. Let’s also pretend to the user that indirection doesn’t exist at all while still having shared mutability? Very bad.
Indeed, that’s what I felt was footgun-y too. I was aware of
extend()s behaviour, and I choose otherwise for a reason. Spelunking CPython a bit, we can see that thecollectionsabstract base classMutableSequencedefines__iadd__asself.extend(values); self, so it’s very clearly considered The Python Way to be like this!Out of curiosity: how do mobile apps normally secure credentials for web APIs (both their own back-end and 3rd-party)?
Well for starters they do not hardcode root credentials for the database into the client :)
Mobile app APIs would typically identify the user from otherwise untrusted requests (via, e.g. a password, but more sophisticated methods are used in practice), validate the request on the server, and then use the server’s private keys to access a third party.
You cannot check that your client is really your app over the internet without really good remote attestation (that will eventually be broken), but you can check that our user is your user.
Edit: In this case however, the mobile R1 client was /not/ the issue and did not have hardcoded keys. Their backend applications, of which the source code was apparently leaked as per the story, however did. The proper approach would have been to isolate production keys to the production environment, and forbid dev access to them.
This is a poorly solved problem. OAuth was designed for server-to-server communications and then extended to support browser-based flows, but I don’t think we’ve ever had a good approach to doing this based just on software installed on end-user devices.
Back in the day I pulled apart the Flickr Upoadr and discovered that I could use it to get access to peoples’ accounts if they’ed previously trusted the Uploadr just by reusing their hard-coded keys. It’s been almost 20 years and while in theory we could use secure enclaves or something we generally just don’t.
Correct me if I’m wrong, but is this not the problem that PKCE aims to solve?
https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce
I’ve seen patterns using short-lived direct access keys where the remote service allows issuing them. The client authenticates to the first-party service API, which then contacts the third-party service API for a temporary credential with limited authorization scope and passes that credential to the client. The client can then talk to the third-party API directly for a brief period of time. The client should never possess a shared key, except perhaps for unmetered, read-only services.
As you can read from the replies, doing this properly requires a bunch of extra work which is why teams like this don’t bother with it.
Hard disagree. But I also disagree that if err != nil is actually good(tm), so what do I know.
Heh, I’m in your camp that
err != nilis good(tm), but I still prefer the use of Testify. I think this mostly comes down to the fact that I think the benefits oferr != nil(i.e. obvious control flow, forced error handling), are not as necessary in small contained tests.t.fatalFalready breaks control flow by doing a panic under the covers, so I don’t see an assert function as being very different.No, I wish go had a try operator and stretchr/testify in std
Ah, yes, sorry :)
I’ve seen this kind of pattern described as “hand-rolling dynamic scope”, which… both seems accurate, and kinda makes you think.
Because I’m on a BEAM kick lately, I wonder what this pattern would look like in Erlang or Elixir?
I think it depends on what aspect of
Contextyou’re looking for.Context.WithValuecould likely be replaced with an ETS table (or a GenServer w/ a Map behind it). I’ve seen that done before, but I don’t know if I’d do it for request context.Plug handles this by storing values in the
Connstruct.But…why not? At least this is moderately explicit.
We’ve been trying to do this hand-rolled dynamic scoping for suspension/context in Scala with gears… it’s a small experiment right now, but with implicit parameters they seem to be fairly handy. (in short, implicit parameters are parameters that, when not explicitly passed, will be searched in the current scope based on the types of the values declared as “givens”)
A friend of mine once cautioned me against using a sequence as a synthetic key. “One day when the server crashes, it will be impossible to tell what rows belong to what tables.” He recommended I use GUIDs instead. This advice saved his bacon at least once but I can’t imagine the scenario he feared recurring today.
Sometimes a natural key arises that you want to leverage and you should. With cascade, updating a primary key isn’t the concern it once was, assuming the primary key didn’t leak outside your database—some do and some don’t. But I wouldn’t follow the academic advice of fishing around to generate a large compound natural primary key if there weren’t any good candidates.
At the same time, I do want the schema enforcing as much validity as possible. I don’t trust the applications to get it right, I would rather they explode when someone does something insane than the database accept it.
Different domains are different; most of my work is with a fairly small number of fairly sophisticated and forgiving users. I would probably do it differently if I were facing a large customer base of inexperienced users. All advice is contingent.
I’m not sure I understand the scenario he feared, nor how GUIDs solve it. Would you mind clarifying?
I’ve seen something done where every id field is a short string, the first say 3 characters of which tell you the type.
Stripe’s API does that, and a few other besides. It’s neat for distinguishing live keys from test keys, too.
Oh nice, thanks for the example.
Whatever the fear (not quite sure either!), a GUID solves it since it will only appear as a key in one place, or not at all. I guess if you could link arbitrary objects ..? Contrast with your usual serial integer keys where you can have user 1, product 1, site 1, message 1, image 1, … I think a much younger me might’ve once or twice applied the wrong key to the wrong table, with some fun results.
I wish I could but it never made a lot of sense to me. He was a FoxPro guy in the 80s and early 90s; I assume the problem scenario had something to do with handling corrupt files where you found the IDs but couldn’t tell what columns they belonged to.
An aside, I’ve actually seen legitimate ISP pages hosted on DO IPs. My last job had a dev box on site, and used ATT as an ISP. Querying for a non-existent domain on it returned such an address.
I enjoy a good call-out of contemporary web design as much as anyone, but if a fussy registration form and slow navigation are the biggest complaints then this is probably not even the worst website launched this week.
The author is invited to try using TurboTax to fill out a complex US tax return[0], or navigate a Japanese government site that blocks non-Safari browsers and uses stateful POST for navigation[1], or use a smartphone to view a page with grey 8pt fonts that disables zoom[2].
[0] TurboTax is infamous for adding 5-10 second intermissions at arbitrary points to make it seem like their servers are thinking very hard about your tax calculations, with the occasional upsell sprinkled in. A moderately complex return can take an entire day of wall-clock time, most of it spent hunting some field validation error across the entire UI surface.
[1] Chrome’s auto-translation mode can switch back to the original page without a reload, but Safari’s can’t. Reloading a page that uses state-machine POST requests for navigation will result in an unrecoverable error state.
[2] The ability to disable core functionality, including zoom and right-click, is easily one of the most user-hostile “features” ever added to browsers.
Oh damn. I thought the hunting down some field validation error was just me being unlucky.
I don’t know why I keep using this piece of shit service. The only thing it has going for it that some of my data is already there, but entering them again somewhere else probably take less than just clicking “skip” on all the upsell BS.
Please recommend alternatives. It’s not even about the price. I just don’t want to be treated like trash by the tax filling company, while I’m already treated like trash by IRS which already has all these stupid forms and knows fully well exactly how much should I pay, but will fine me if I I screw up anything.
I’ve only heard good things about FreeTaxUSA. I had my taxes done for me this year, or I would have given them a whirl.
tax time :)
If you live outside the US, alternatives won’t let you use them. It’s a lot cheaper than paying a human, but boy does it suck to use. The UX cherry on top tho is when you go to pay you have 2 options: 1) pay out of your return or 2) pay with a credit card. Option 1 is straight not available if your address is outside the US (why?). Option 2 requires that your credit card is registered with a US address (why?). This was my second year calling my mother like I was a teenager 2 decades ago asking for lunch money to help pay the TurboTax filing fee. Naturally you don’t get shown the payment screen until after you have poured hours into filling out all their forms too.
It’s not the worst experience in the world if you have a simple to moderately complex return to just use Free File Fillable Forms. The worst part is data entry; the forms itself are better documented than any program.
no need to look as far as Japan, many HR websites of extremely western multinationals do all sorts of a11y crap
This is awesome! I look forward to its development. To me, the killer feature of Insomnia was “request chaining”; it was super useful for hacking on APIs with timed tokens. Are you planning on that making a return (or is it there, and hiding)?
Yes, that’s definitely on the roadmap! https://yaak.canny.io/feedback/p/reference-response-values-in-other-requests-chaining
My only concern about
*/v2is that those not “in the know” will continue to use the old version. I imagine it’s going to be a bit of a “which one do I use?” moment for new developers. I do hope that there’s some sort of static analysis that warns you to use/v2packages when available (perhaps only for new code, but I don’t know how one would detect that)I think the plan is to eventually mark the old package as deprecated at which point various tools will point it out. But they didn’t want to mark the old one as deprecated in the same release as introducing the new one, because that’s annoying for Go code that supports multiple Go releases.
Makes total sense.
It’s an interesting approach, for sure. I definitely like the idea of not necessarily introducing more tools than needed.
With things like this, I’m always a bit wary of “magic”. You may know how it works as the person who installed the package, but down the road when someone else inherits it, it may not be so obvious that
csvbase-clientis what’s providing this scheme to Python. Just my 2cI suppose both the question of how much magic is being introduced by this - and how much is an acceptable level - is a matter of taste.
Any abstraction layer that is transparent is vulnerable to the same criticism really - whether it’s HTTP proxies, or DNS. If it can be enabled/disabled without a code change it’s never going to be clear from the code that it’s enabled/disabled :)
I learned from someone on mastodon that I’m not the only person to have thought of using fsspec this way. HuggingFace also provide a driver for fsspec. So there is that evidence, at least, to suggest that I’m not completely bonkers :)
We’re all a little bonkers :) Don’t get me wrong, it’s definitely neat!
I also try to avoid “magic”, especially in languages where there’s so much potential for magic like Python. I’d argue that the automatic registration of fsspec providers is too much magic. After all “explicit is better than implicit” is the second line of the Zen of Python.
I was a bit hazy on posting this, but I shared it because I really liked the idea of forcing personal projects along by timeboxing it to a month
This looks neat. I just picked up a small LiveView project and definitely felt myself running into the “is there a more idiomatic way to do this” barrier quite quickly, particularly around UX subtleties like the author mentions. I eventually came to the conclusion that LiveView isn’t mature enough to have anything that’s super idiomatic, but this does seem like an interesting compromise.
For now, I’ve just added a top-of-screen loader while state is changing, which for my little hobby project is likely more than sufficient