HN user
Opinions are my own and do not represent the views of my employer.
My personal website is https://dangerlibrary.com
An email sent to any username at the above domain will reach my personal email.
If you have questions about working with me on Veho's Data Platform team, first dot last at shipveho is the perfect place.
Last year I became the volunteer coordinator for my kid's school PTA. They had been using Sign Up Genius for years. I spent a full year fighting a paid tool, gave up, and re-wrote it.
Now https://voluntold.fyi exists, and I never need to remember to manually move my single $100/year "ad free signup" off an event that has already happened to one that is coming next week.
noTunes is one of the first things I install on a new mac.
There's a book that changed a lot of the way I think about attention and media [0]. The book isn't very good, but it flags something relevant here. There is a huge asymmetry between the reach of a big, flashy announcement (here: bun was re-written in memory-safe rust in a couple weeks), and the relatively small reach of a correction (often just a footnote on an old article, here a GH issue).
This asymmetry is well understood by marketing and PR professionals, and actively exploited.
Veho | ONSITE / HYBRID 3 days per week | NYC or Boston | No Visa | https://shipveho.com/careers
Hi there! At Veho, we don't sell software. We ship packages. Lots of them. We have all of the interesting problems that crop up when running twinned distributed systems in AWS and the real world. It's pretty great.
We're hiring staff-level folks (L4+) in NYC and Boston: Data Scientists, Data Engineers, Mobile Engineers, and Backend Engineers (typescript).
Personally, I'm hiring a Staff Data Engineer with the depth of experience to be a technical lead and mentor for the Data Platform team, while also shipping code. You will need to understand distributed data systems both intellectually and at an instinctive, emotional level. You should have Opinions about the wild boar book. You should probably also be comfortable writing and debugging English, SQL, and Python.
If that sounds like you, I really want you to apply for the Staff Data Engineer role on our career page. Our inbound applications are reviewed by humans.
With apologies that our first interaction requires this silliness: including one of the 7-digit numbers from the "ROS Calculator" on Veho's website in the appropriate box will heavily bias me towards believing you are a human being. That's more of an advantage than it may seem! It's worth the thirty seconds. It would also speed things along if you populate the "Location" field to confirm you are aware this is an in-office role.
Personal website. https://dangerlibrary.com/
Like Unison [0], but buggier.
It is 2025 and CSVs still dominate data interchange between organizations.
It's called upcoding. It's been happening with or without AI or SV's help for well over 40 years. [0]
Interestingly, whistleblowers can recoup a big chunk of the recovered funds in a False Claims Act suit when medical providers do this to defraud Medicaid / Medicare [1]. Could be a lucrative long-term play if you get employed at a company whose sole purpose is helping hospital chains bill for care that an AI thinks may have been provided.
[0] https://pmc.ncbi.nlm.nih.gov/articles/PMC10759668/ [1] https://en.wikipedia.org/wiki/False_Claims_Act_of_1863
The US Government did a study in the 1950s and discovered that the damage done to a roadway by a car is proportional to the fourth power of its axle weight.
Super heated water is a pretty effective disinfectant within the pipes. For interior spaces ventilation is a legitimate problem in non-forced-air systems.
Historically, you open a window.
The shadow druids are gaining a foothold in Silicon Valley circles, it seems.
It seems intentional, though?
* There's an animation hiding it.
* If you disable javascript, the content doesn't load.
* Copying is disabled.
* There's some kind of javascript function constantly toggling state so that if you right-click inspect, the content div collapses before you can further unroll it.
Someone really wanted users to see the article, then watch it disappear, and make them feel a sense of loss.
This paywall product must have required a staggering amount of work. And yet, the entire text of the article is right there in the network tab.
Why send it over the wire, then try to hide it?
I use the readthedocs theme: https://www.mkdocs.org/user-guide/choosing-your-theme/#readt...
Not sure if that fits the bill for you, but I like it.
I just use mkdocs for everything.
I'm someone not really aware of the consequences of each quantum of progress in quantum computing. But, I know that I'm exposed to QC risks in that at some point I'll need to change every security key I've ever generated and every crypto algorithm every piece of software uses.
How much closer does this work bring us to the Quantum Crypto Apocalypse? How much time do I have left before I need to start budgeting it into my quarterly engineering plan?
My slack profile, for years, has had a volcano emoji and the words "DMs are lava. Don't touch the lava."
It doesn't actually stop people from DMing me, but it does soften the blow a bit when I immediately move technical/product conversations out of DMs. (Obviously anything personal or sensitive stays private)
SheerID already exists and can differentiate between alumni and current students. Apple just needs to decide it's worth it (thus far, they haven't).
Did you perhaps respond to the wrong comment? This is in no way responsive to what I wrote.
Or that their sales contacts treat women and non-binary folks worse than men.
https://www.newsweek.com/male-and-female-coworkers-switched-...
The point of the GP post is that the "w-4" token had very different results from ["w", "-4"] or similar algorithms where the "w" and "4" wound up in separate tokens.
Without IPv6 network sees an unsupported IPv4 packet and throws it away. You need something to convert IPv4 to IPv6.
Acknowledging my own ignorance here, assuming this sentence seemingly disregards my point, because this was a choice. The IPv6 standard chose to fix the header length at 40 bytes and operate differently from IPv4, but the standard could easily have said "We're re-using the IPv4 header format, except now addresses are variable-length up to 128 bits."
You are correct, given the assumption that an IPv6-capable server or host has no IPv4 address. I attempted to acknowledge that such a server would be unreachable from an IPv4 client.
I assure you I am under no illusions about my cleverness relative to others in this industry.
Just to address the implication (prevalent in many of the sibling comments as well) that I and everyone else who talks about this are idiots incapable of grasping that 128 is larger than 32:
If 32 bit IPv4 addresses are valid IPv6 addresses without fiddly NAT64/DNS64 shenanigans, then (it seems to me) IPv4-only clients could blithely continue to interact with the IPv4-accessible internet via IPv6-only servers, routers, etc. indefinitely. They can putter along accessing only a subset of available resources forever and everyone can passive-aggressively roll their eyes at them and close support tickets saying "upgrade to IPv6 if you want to see the rest of the internet, it just works."
That's what I mean by backwards compatible. Everyone who says "it can't be done, it has to be this way" is asserting that there's no better alternative to NAT64/DNS64 and running two entirely separate networking stacks in parallel. I don't buy that there was no simpler way to accomplish packing 32 bits into a space that can contain 128 bits. And if "supporting IPv6" simply meant "upgrading your networking software to the latest version, which transparently handles both IPv4 and IPv6 traffic for you" then networking and server teams have no excuse to avoid deploying IPv6 support for 26 years.
I recognize that 128 bit addresses will be truncated and packets misdirected or rejected if handled by a 32 bit networking stack. I recognize that clients upgrading too early will fail and need to fall back. But making it unnecessarily difficult for servers and routers to handle IPv4 traffic in an IPv6-only context led us to where we are today.
To illustrate my point: ascii text works just fine, with no translation layer required, when parsed and transmitted as UTF-8.
Interesting! Thank you for the thoughtful reply - I did not anticipate those complications.
"The length is the problem, IPv6 format is more compact."
"IPv4 still can't access IPv6. IPv6 can't access IPv4."
I guess my point is that these statements represent choices made by humans. Leaving the decimal representation aside, I don't get why they made these choices. If every IPv4 address were a valid IPv6 address, then these statements wouldn't be true.
It never made sense to me why the authors of the IPv6 standard chose to use an entirely different address format, instead of extending address space in a backwards-compatible way. Why not just append/prepend the 12 additional bytes onto existing IPv4 addresses, and write the standard such that all valid IPv4 addresses are also valid IPv6 addresses?
I'm not an RFC author, but something like "All existing IPv4 addresses will be reachable under the 0.0.0.0.0.0.0.0.0.0.0.0 prefix in the IPv6 Standard" seems like it would've made migration relatively trivial.
The draft standard is 26 years old. The official standard is 7 years old, and we are still reading articles about how "not all enterprises or applications are ready for IPv6 yet."
This question is coming from a place of genuine confusion and curiosity - I really don't get it. Did the authors of the standard just assume that migration and adoption would be easier than they've turned out to be? Was it a fairness issue where somehow this would have granted dominion over huge swaths of the new address space to existing players?
This is more an opinion piece with some hand waving than actual proof
Pot, meet kettle. Kettle, this is pot.
I would absolutely say that medicine is not science - or at least that it is very bad science with a low probability of being reproducible - and anyone with even tangential exposure to most medical research would do the same. Small sample sizes, confounding variables in treatment, and non-random assignment are the norm, simply because practicing medicine is not the same as performing scientific research.
Medicine is the practice of healing sick people, and (even if they wanted to, which most do not) it is very, very hard for doctors to convince an IRB that it's a good idea to give sick people a placebo. Also, despite some attempts to perform placebo knee surgeries [0], there are many medical interventions where it is simply impossible to do things like a basic RCT.