I can't imagine a worse privacy nightmare. Always on backdoored baseband in 5G with a unique permanent IPv6 address assigned to the machine. Okay, maybe it could be worse if each user account is assigned its own unique IPv6 perma-cookie.
You're thinking of MAC addresses. Machines don't have permanently-assigned v6 addresses, rather the IP is assigned by whatever network they're currently attached to and will change based on that network's whims, just like it does in v4.
“Privacy addresses” are named because in the beginning, your auto-generated IPv6 would incorporate your hardware MAC address verbatim, and many people consider the MAC address to be PII.
On the last 64 bits, yes. On mobile phones, the first 64 bits may be fixed. This was something I argued against when I was at Vodafone Group, but didn't get any traction. That was a while back, but I'd assume that this is still the case, and that mobile phone addresses can be used for tracking.
No, not just like IPv4. My IP address is 192.168.0.23 right now, as are millions of others. Add in CG-NAT from my ISP and I do not have a globally unique identifier.
Let's be honest. Being a real man is approaching 100 women, getting rejected 100 times, and still approaching number 101. That's the basic reality for men. All that rejection makes men callous. The author, from an all boys school, hasn't been beaten down by it. He runs into men in college for the first time who have been rejected and demoralized by women their entire lives, and he has no empathy with those men. He can't, because he's from the all boys school where all his knowledge of women comes from unrealistic books, movies, anime, etc. Portrayals where the dorky boy has half a dozen love interests, they all banter with him, they're like stray cats who are all cute in their own way, and his biggest problem is choosing which one he really wants... the hard to get one of course. It's not like that in real life at all. Those are just fantasies for children, because telling boys the truth would be like telling them there is no Santa.
If you've been to Japan any time recently you'd probably know that just about everything is cheaper in Japan, especially food and drink. I've been twice, most recently back in October, and I'm blown away by how relatively affordable things are. USD goes a long long way in Japan.
Oddly I could not find any cheaply priced Japanese Whiskey, and I looked around quite a bit. It was all about as much or more than what I could get it for in the states.
Japan's salaries are much lower than those in the US. Even adjusted to PPP, the median salary in Japan is still significantly lower that in the US. Few would be able to afford food at US price levels.
> Oddly I could not find any cheaply priced Japanese Whiskey
Any bog-standard supermarket will carry a variety of very low end Japanese Whiskeys. You can easily find 750ml for about 1000 yen. It won't poison you(!), but it is pretty rough. At this price point, it is rarely drunk neat. Also, Japan has nationwide uniform alcohol taxes. Alcohol taxes vary widely in the US by jurisdiction.
I mean more like, I'd look for the stuff that's like $300-$400 in the US at various places that would sell it in Japan and generally speaking it was more expensive in the stores in Japan after conversion. I was expecting it'd be like similar price or less. So I opted to just buy the imports in the US.
I don't know about McD's exactly, but food in general is very cheap in Japan compared to the U.S.
Source: I watch a lot of behind the scenes restaurant videos on YouTube and I'm always shocked at the prices. Most dishes are cheaper than if I were to go to the grocery store and cook it myself...
Their meat also tastes like actual food compared to the US. McDonalds Japan is more like a gourmet meal experience, everything is delicious and the service is much faster and way more polite and pleasant in my experience.
Did you know it was impossible to grow rice in Hokkaido Japan. No one successfully grew rice there until the 1850s. Now Hokkaido produces 7.5% of the rice in Japan.
Interesting comparison. Have you done one for sqlite vs H2? Since you're using clojure, it seems a natural fit. According to what I've read, H2 is faster than sqlite, but it would be interesting to see some up to date numbers on it.
That's a good point. I'll give that a go and do a write up at some point.
The choice to use SQLite for me isn't actually about speed (LMDB is way faster).
I just get tired of people saying switch to Postgres for speed/scale. Postgres is great for many things but speed/scale is not its strength.
The main reason I use SQLite is the affordances and conveniences of an embedded database. Being able to easily have many databases. When databases are "cheap" it opens up loads of options. Of the embedded/file OLTP databases SQLite also has the largest toolbox: litestream, R*Tree indexes, JSONB, FTS, etc.
I haven't tried sqlite because the lack of data types is off putting to me. I want to like derby because they have gone to the trouble of making their database JPMS modular. But derby doesn't have UUID types and I want UUID types. Especially with Java 26 adding UUIDv7. I end up on H2 as a result.
For what it's worth blob types and application functions make it pretty straight forward to implement your own datatypes. I often have one for EDN and one for bigdecimal.
I think the synergy part is what is great here. Imagine thundermail is a FOSS server app. Imagine they implement things like proof-of-work for senders, and no PoW means the mail goes into a quarantine instead of directly in the user's inbox. That could fight spam, without the centralization and loss of privacy we've had in email. That hasn't happened now, because of the chicken-egg problem. There's no client that supports it because there's no server that supports it because there's no client that supports it.
Thunderbird is a very big client. It could push email forward like nothing before. I may give Thundermail a try. I'd much rather self-host a Thundermail server... one that works around the port 25 block on every residential IP. Maybe my self hosted instance could receive messages relayed from the "real" thundermail server on something other than port 25.
I spend a lot of time outside the country. Everyone seems to block VoIP for "security" now too. So please stop using SMS for 2FA. Seriously, even NIST says this is a bad idea, but everyone keeps doing it.
I have yubikeys. Lots of people can do authenticator codes on their phones. Stop using SMS already. As you're discovering, it's garbage for that purpose, even for you as the developer. Even emailing the code would be better.
I sent 100,000 SMS appointment reminders every day for over a decade. I resisted lead times under 1 day for a very long time, until I was forced to roll out lead times as short as one hour. I made extra sure, I got it in writing, that customers would be informed hourly lead time may fail and be unrecoverable. Don't depend on it.
Hourly, the shortest lead time was one hour. And you're talking about 45 seconds.
What you’re describing is kind of what I keep running into too — people don’t really try to understand delivery, they just design around the fact that it’s unreliable.
Longer lead times, retries, fallback channels, etc.
Which works, but it also means the actual behavior stays a black box.
Did you ever notice differences between providers or routes, or was it basically opaque the whole time?
>they just design around the fact that it’s unreliable
Everything is unreliable. Always design for unreliable. That's my major gripe with most docs and tutorials from any of these services. They only describe what happens during success. They never go into detail on what happens when things go wrong. Your only option is to wait for it to blow up and learn from experience. In the meantime, assume it is going to blow up, try to catch it and log as much of the blowup as possible. Never assume it will work. Assume it won't work and be happy when it does.
This is why you should lean toward something like an authenticator. You can control the whole experience. Rely on unreliable services as little as you can.
>I stopped development in 2014.
>I stopped supporting it in 2016.
Ouch. I guess his customers learned their lesson about trusting random 1 guy OSS projects.
reply