The US does identity verification by asking for a driver's license (which has no chip or biometric data) and possibly a series of questions about your past drawn from public data. All of these credentials are laughably easy to spoof. Compare this to Europe, where every resident has an eID containing a keypair and X.509 certificate signed by the government containing their personal details. It is trivial to check the validity of these cards and nearly impossible to forge without subverting either the national PKI or printing apparatus
> Compare this to Europe, where every resident has an eID containing a keypair and X.509 certificate signed by the government containing their personal details.
Woah. First, on HN I keep seeing this term "Europe". Europe is 50 countries. Please try to be more specific. Did you mean EU? If yes, then my question: Really? All 27 EU nations support and actually use this identity programme with financial institutions? I never heard about it. And, just saying that it exists isn't enough. Do normies use it (like your parents & grandparents)?
It's currently being deployed across the european union[1], I think the 2026 target they gave it's a tad too unrealistic, wouldn't be surprised if we get major coverage not until 2030.
That target is for the new and improved version where you can use NFC to self-identify on the web. The old version (with a smart card inside, so only offline auth) was rolled out in Germany in 2010.
Can't remember if they ever released the 1st version either in Italy or France, a few days ago my septuagenarian mum got the NFC enabled one in Italy.
The iOS app is surprisingly decent. She could still request the old, paper-only id but this one could be also used to pay for local ordinances straight from her phone, and it's less cumbersome than the SPID-based[1] authentication.
It's an EU thing. Yes, normies do use it, as it is a chip embedded in your personal ID card and your passport. You hand your ID to an officer, they read the chip data and verify the signature. You don't have to know anything about how it works. It also contains biometrical data (your fingerprints, etc).
Implementation of eIDAS is still in progress. It's not even mandatory for every citizen to haven an eID until end of 2026. And it's also not used yet everywhere for everything. But it's gradually growing.
The first time I had a chance to use was just some months ago, when I could activate a SIM-card online through and my smartphone reading out my ID-card via NFC. I pay daily via NFC, but it's the first time ever I had to use the chip in my ID-Card, despite it having one for 15 years now. Laws and regulations are good in theory, but reality can be often quite a bit different.
Fingerprints are collected only from criminals or people who visit US. Why did Europeans agree to being treated like criminals or tourists I don't understand.
>Fingerprints are collected only from criminals or people who visit US. Why did Europeans agree to being treated like criminals or tourists I don't understand.
Only if you assume that anyone who works for a SEC regulated company[0], applies for a California driver's license[1], current and former US Military personnel[2] healthcare workers, teachers, real estate agents, child care providers and others[3] are either "criminals" or "tourists."
If so, into which bucket would you place CA driver's license applicants? Criminals? How about US Military personnel? Tourists?
Yes the government wants to treat everyone as a possible criminal and collects fingerprints for this reason. There is absolutely no logical reason for collection of fingerprints for a driver's license. Collecting fingerprints doesn't make driving safer in any way. Making driving exam more difficult and having to take it more often would make driving safer, limiting the speed would make driving safer, but fingerprints wouldn't.
Nobody, surprisingly, our regime doesn't require us to provide fingerprints yet (although that might change; our government loves to say "we just do the same thing all Western democratic governments do, so don't complain"). The punishment for not having valid "papers" is usually a fine (the fines for not having valid documentation related to military service were significantly increased recently for obvious reasons). Unless they close the border, I think we don't need to worry.
Also I always thought that it is weird, having to take driving exams to get an ID and calling an ID a "driver's license".
Don't know about the whole Europe (or EU) but I strongly suspect it is indeed (almost) everywhere. I'm Turkish and Turkey has it too. And yes, my mother uses it, and my grandparents used it when they were alive. You can't do anything government-related, open a bank account, or even visit a hospital without your government-issued ID card (which contains a chip). And a few decades ago, before the chips, there were other security measures tied to ID cards.
The USB HID protocol is designed to support basically any device that regularly reports a set of values; those values can represent which keys are pressed, how a mouse has moved, how a joystick is positioned, etc. Now, different devices have different things that they support: joysticks have varying numbers of axes, mice have different sets of buttons, some keyboards have dials on them, etc. So, there's no single format for a report that simultaneously efficiently uses bandwidth and supports all the things a human interface device might do. To solve this, the HID protocol specifies that the host can request a "report descriptor" that specifies the format and meaning of the status reports. This is great for complex devices running a full OS; there's plenty of memory and processing power to handle those varying formats. However, these HID devices needed to also work in very limited environments: a real mode BIOS, microcontroller, etc. So, for certain classes of device such as keyboards and mice, there is a standard but limited report format called the "boot protocol". IIRC, the keyboard version has space to list 6 keys that are pressed simultaneously (plus modifiers), all of which must be from the same table of keys in the spec, and the mouse has an dX and dY field plus a bitfield for up to 8 buttons (four of which are the various ways you can scroll). To implement a more complex device, you'd want to be able to specify your own report format, which the ESP driver doesn't seem to allow you to do.
So your original comment / request was regarding USB specifically then?
I ask because I'd have guessed (possibly incorrectly!) that implement HID via GATT (BLE) you'd be able to support anything the BLE hardware revision could implement?
Perhaps the disconnect for me is that it's unclear when there is some special hardware that exists within the ESP32 itself (I think I2C, I2S, etc would be examples of this) vs something you are just implementing by manipulating the IO pins. Perhaps HID is one of those things?
Maybe. If you have Linux the command `lsusb -v` gives you a verbose breakdown of the attached USB devices, if you find your keyboard it will show which interfaces it provides (a USB device can offer several if it wants) and to work at boot you want:
interface class 3 (a Human Interface Device) sub class 1 (Boot protocol or Boot interface)
In contrast the sub class 0 of HID is just the ordinary case, which is arbitrarily complicated (six thousand keys and four axis input? Why not) and so understandably a BIOS or similar environment might not implement that but a full blown OS usually does.
Doubtless tools exist for other platforms which can show the same information as lsusb
Calendar apps expose all of the weird edge cases in dates and times. For a specific instance of a specific event that never needs to move, TAI will work. However, suppose that you schedule a meeting for 28 March at 13:00. You then move that meeting forward a week, crossing a DST switch. If you simply add 604800 seconds to the TAI, that meeting will be at 14:00, which is surprising. OK, easy enough to solve; convert the TAI back to the local timezone, add 7 to the day field (carrying into month and year, as needed), and you're good to go. Now suppose that the meeting was set up in the US, and you realized that you needed to reschedule the meeting while you were travelling in Germany. You get back to the US, and suddenly the meeting is an hour early, because DST rules aren't universal.
Worse, imagine a recurring meeting, every week at noon. You've got the TAI for the original instance, but as you cross a DST boundary, some places will shift according to DST and others won't, and thus you have half the attendees showing up at the wrong time.
Finally, TAI introduces the leap second bug for calendars. When you schedule a meeting for noon next year, you want that to happen at noon, not now plus however many seconds. If a leap second is introduced, you don't want that meeting to happen at one second before or after noon.
TBH, if you find yourself in a situation where you need to deal with calendar events, I recommend updating your CV.
I'll preface this by stating that I fully realize that localized datetime is absolutely byzantine and fraught with difficulties. That's the rationale for leaving it to an external library as close to 100% of the time as possible.
I also realize that there might well be complexities involved in calendar software that I'm unaware of. Hence my comment - I'm genuinely interested to learn. That said, I think your examples are all fairly clear examples of errors in reasoning by the programmer. Specifically they stem from conceptual mistakes regarding the relation of different logic domains (by which I'm referring to storage, display, scheduling, etc).
You never move events around in TAI (the unambiguous storage format) just as you don't go manually flipping bits in an SQLite database. You always work in a localized time because that's what the user is reasoning in. And you use the datetime library to implement as much of those manipulations as possible.
> US vs Germany, conflicting DST rules.
Go back to the era before smartphones and PDAs and the internet. You're in Germany on a business trip. You call your secretary to reschedule next weeks meeting back home. You don't use German time when doing that, you use US time.
Events have a location which has a timezone. Scheduling happens in that timezone. Blindly using the current local timezone of the device is a reasoning error. Storage, scheduling, and presentation are distinct logic domains.
> you have half the attendees showing up at the wrong time.
There is a single unique TAI time for a given event (after all that's the entire point of using UTC or TAI or what have you). All attendees will see an equivalent local time barring a bug in the datetime library.
See my earlier point regarding which timezone to use for the computation.
> TAI introduces the leap second bug for calendars.
Only if you make the mistake of attempting to manually manipulate your data storage format. The point of TAI as opposed to UTC in this specific case is to offload the complexity of handling leap seconds onto the datetime library so that you don't need to worry about it.
> You never move events around in TAI (the unambiguous storage format) just as you don't go manually flipping bits in an SQLite database.
You actually do. From the point of view of future scheduled events, a event scheduled for 13h00 in a specific timezone is still "13h00 in a specific timezone" even when crazy people on that timezone suddenly declare a new Daylight savings time to start before the event happens. All future "timestamps" are prone to move due to such shenanigans. And you need to keep your timezone DB as updated as possible to update thing as soon as possible, if you don't want users with wrong times on their future events.
If you're not doing something like full rfc9557 https://datatracker.ietf.org/doc/html/rfc9557 "Internet Extended Date/Time Format (IXDTF)" [iso 8601 local time + as-of-now known timezone offset + IANA timezone] as "timestamps" you're probably truncating important information that will bite you back later if you're doing a calendar/scheduler.
It's a good point. I responded to the adjacent comment.
After glancing at that RFC I'm unclear about the purpose of the UTC offset. Is it simply an error check to catch the case of a datetime library with outdated timezone information? Otherwise it seems like the library will have all the historical information on hand so it shouldn't have any use for it.
The problem is TAI is not the source of truth in real life. In real life, Arizona can change its laws and suddenly that event is going to happen at a different TAI timestamp. That’s why the unambiguous storage format has to be a date time with time zone, and not just a timestamp.
Good point. Seems I also made a reasoning error by failing to consider that timezones, being arbitrary legal constructs, can be changed at the drop of a hat.
However it doesn't seem particularly difficult to fix. My error was suggesting using TAI for storage. I guess that works only for events in the past. So the timezone that the event belongs to is what should have been used for storage, you should forget leap seconds exist because this is a human centric calendar so who cares, and you should trust the datetime library to just do the right thing when converting timestamps.
Is there some other issue I'm missing? Because so long as all the timezone complexity is stuffed into the datetime library (and thus NotMyProblem™) it seems like the really difficult part is already solved for you.
IMHO, based on zero evidence, for scheduling, very few people are scheduling events beyond a minute of precision. TAI is a better timescale than UTC, but UTC is better supported and leap seconds might be going away, so pretending they don't exist is probably a better choice.
But timezones are super byzantine. Especially when the rules update. More especially when the rules update on short notice.
If you scheduled an event at 5 pm local time at some place on some day and the rules change, the event's UTC (and TAI) would change. But you may want to confirm with the user, because maybe they're calling into an event somewhere else and they entered their local time but the event is really scheduled in the other time.
You might also have fun when multiple clients are using the same event and the clients and the server don't all agree on timezone definitions. iCalendar suggests that the timezone definition be included in the files, but my experience is definitions are often missing and most things ignore the definitions if present; you've got to include a timezone name the software is going to process as you want or you won't have a good time (or use UTC and hope)
If the event was scheduled in the DST window, the time may no longer exist, or may be ambiguous. iCalendar has rules for that, but they might not actually meet your user's needs (otoh, who is scheduleding things at 2-3am on a Sunday ... probably not a lot of people)
> the clients and the server don't all agree on timezone definitions
Isn't that scenario unsalvageable regardless? It presumably means one or more of the devices are displaying the wrong time to the user. Or at least will be upon arrival in the timezone of the event.
For example (intentionally extreme) suppose the library used by my calendar thinks EST is -4, the OS on my device thinks EST is -6, and everyone else thinks EST is -5. What possible program logic could prevent disaster in this scenario?
It's a really interesting edge case to point out, I'm just not clear what a sensible algorithm for handling it would look like. I strongly suspect that assuming that can never happen is the right answer. Everyone agrees the event is scheduled for 9 am EST. If outdated client software translates that to PST incorrectly or displays the incorrect time on the clock then the affected user is going to have issues and I don't see what the programmer can realistically do about it.
> ... DST window, the time may no longer exist, or may be ambiguous.
Assuming the timestamp disambiguates the daylight timezone from the standard timezone this should be handled gracefully by the datetime library since the stale timestamp is merely "out of bounds" for that timezone now that the laws changed. I'm failing to think of a scenario where it becomes ambiguous (although reasoning through this is once again reinforcing my view that we should have ditched DST long ago).
However this did cause me to realize that there's an additional edge case for far future events where the timezone is modified multiple times. If the event timestamp was never updated in the interim you land in an ambiguous situation and have no way to detect it.
I'm not sure that particular edge case is worth worrying about, but it seems like tracking a second timestamp indicating the last time that the event was processed by the datetime library would resolve it. The library should hopefully have all the necessary historical information on hand to update a long since stale timestamp (I haven't tested this though). Anyway if it doesn't I don't see that there's anything you can do about it.
Indeed, BFS, DFS, and A* are the same algorithm just with a different data structure to track unexplored nodes. BFS uses a FIFO queue, DFS uses a LIFO stack, and A* uses a priority queue (generally a heap)
A* is also importantly different for what the ordering of the priority queue is. Dijkstra's algorithm is just BFS with a priority queue, but the lack of heuristic in the comparison key keeps it clearly breadth-first.
One of the things that Data Matrix got right was being able to shift between encoding regimes mid-stream. Many character sets can be represented in radix-40 (so three characters per two bytes), and the occasional capital character can be handled by a shift byte. If you have a long string of digits, they can be encoded in 4 bits/char. You can even put raw binary in there if need be
A QR Code consists of a sequence of segments. Each segment has a mode - numeric, alphanumeric, kanji, or byte. It is possible to shift between encoding regimes by ending a segment and beginning a new segment with a different mode. https://www.nayuki.io/page/optimal-text-segmentation-for-qr-...
I seems to me best approach would be to compress the contents with a Huffman code or some other entropy encoding. All this business of restricted character sets is just an ad-hoc way of reducing the size of each symbol and we've got much more mature solutions for that.
For entropy codes to be effective for such short strings you need a shared initial probability table. And if you have that you are effectively back at special encoding modes for each character set.
Compiling an emulator is quite easy: have a look at simh. It's very portable and should just work out of the box.
Once you've got that working, try installing a 2.11BSD distribution. It's well-documented and came after a lot of the churn in early Unix. After that, I've had great fun playing with RT-11, to the point that I've actually written some small apps on it.
The daves garage youtube has an episode where he documents the pitfalls of compiling 2bsd for a PDP-11/83. https://www.youtube.com/watch?v=IBFeM-sa2YY basically it is an art on a memory constrained system.
What I found entertaining was when he was explaining how to compile the kernel, I went Oh! that's where openbsd gets it from. it is still a very similar process.
The PDP-11/03 emulator itself is good enough that it can run the RT-11 installer to create the disk image you see in the browser version. The VT240 emulator is good enough that the standalone Linux version can be used as terminal emulator for daily work. Once I have time, I plan to make a proper blog post describing how it all works / what the challenges were and post it as Show HN eventually.
> It's somewhat picky about the environment. So far, aap's PDP-11/20 emulator (https://github.com/aap/pdp11) is the only one capable of booting the kernel. SIMH and Ersatz-11 both hang before reaching the login prompt. This makes installation from the s1/s2 tapes difficult, as aap's emulator does not support the TC11. The intended installation process involves booting from s1 and restoring files from s2.
good luck though. my emulator is not particularly user friendly, as in, it has no user interface. i recommend simh (although perhaps not for this thing in particular).
I've been messing around with RSX-11M myself! I find these early OSes quite fascinating. So far I've set up DECNet with another emulator running VMS, installed a TCP stack, and a bunch of compilers.
This arrangement makes ordering easier anyway which is probably why they chose it.
If we have some positive 32-bit integers A and B then if A < B, f32::from_bits(A) < f32::from_bits(B)
Edited to add anecdote:
I actually had a bug in realistic (my Rust crate to implement Hans Boehm's "Towards an API for the Real Numbers") which I only fixed recently, for converting my Real number into a floating point type where I might end up with too many mantissa bits, but then sometimes coincidentally the bottom bit of the exponent is zero, and so instead of increasing the exponent by one I actually overwrite it with a one and that's the same result.
I finally caught that when it occurred to me to do "thorough testing". That is, take all possible 32-bit floats, turn them into a Real, then, turn that Real back into a 32-bit float, this should be a roundtrip, if it's not we've found a bug. There are "only" a few billion of these values to test, a machine can do that.
I fixed the 64-bit routines for the same bugs, but I don't have enough years to run all the 64-bit tests the same way and discover any that aren't paralleled.
[Of course there are presumably still bugs in the conversion algorithms which may either be symmetric, and thus the bug doesn't impact a round trip, or they don't affect the binary fractions used exclusively by floats, Real has proper rationals and various other things like the square root of integers, Pi, etc. which we can convert to a float and lose precision but we never get these from converting a float because floats are always binary fractions.]
> I fixed the 64-bit routines for the same bugs, but I don't have enough years to run all the 64-bit tests the same way and discover any that aren't paralleled.
Minor thought for today: there are more than 2^64 bits of RAM in the world.
If you're familiar with that work, realistic implements most of it (some trig functions I didn't get to yet) but it's deliberately not 1.0 because I'm still tinkering with core API things like, I changed how the errors work this week.
If you're not familiar, a fact about the reals which cannot be emphasised enough is that almost all real numbers are non-computable. This serves to properly temper expectations, regardless of whether you know what the mathematical term "Almost all" means. We're going to be able to compute some useful reals, and then do arithmetic with them, and not get miserably bad rounding errors like for floating point for example. We just need to keep in mind that "towards" here is just gesturing in a direction, it's not a destination which can be reached.
Haha I'm familiar, I actually also tried to implement the paper at some point. It's such a cool idea and a great example of the difficulty that goes in to making a really good UX, even for something as simple-sounding as a calculator app.
Indeed there isn't; 10 is not relatively prime to 2^32. However, 5 is (and therefore has a multiplicative inverse), so you can right shift and then multiply by the inverse.
All of this is missing the point that doing basic arithmetic like this in Python drowns in the overhead of manipulating objects (at least with the reference C implementation).
For that matter, the naive "convert to string and convert each digit to int" approach becomes faster in pure Python than using explicit div/mod arithmetic for very large numbers. This is in part thanks to algorithmic improvements implemented at least partially in Python (https://github.com/python/cpython/blob/main/Lib/_pylong.py#L...). But I can also see improved performance even for only a couple hundred digits (i.e. less than DIGLIM for the recursion) which I think comes from being able to do the div/mod loop in C (although my initial idea about the details doesn't make much sense if I keep thinking about it).
With debian, is you develop on stable, you only need to do the upgrade song and dance every year and a half or so and upgrades rarely break anything. If you develop on unstable, you can use the snapshot archive to either upgrade 6 months at a time or move back to the next stable and then walk through stable releases.
