For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | more rwallace's commentsregister

Be careful what you hope for. For all we know, the answer might be, "Sorry, human, I'd love to chat, but I need to get your dish cleaned and racked up to dry before they close the lab for the eon. Now, how do you get the childproof cap off this bottle of antineutronium..."


I'm curious, what exactly would you redesign? Seems to me that it's intrinsically necessary to have DNS to translate between human-readable names and machine-efficient addresses. What am I missing?


The main thing is I would collapse most of the layers.

Something like DNS is necessary, but I'd use individually digitally signed records except for mdns, and if you couldn't reach upstream, you wouldn't ever just drop stuff out of the cache.

I'd get rid of certificates entirely though. Without any insecure DNS, you

I'd also change IP addresses to be longer, maybe even 256 bits. 48 would be reserved for identifying an ISP (And large ISPs would have different codes for different regions), 16 would be reserved for whatever the ISP wanted to do with them, 32 bits would mark a customer, 16 would be for a customer subnet, and the rest would be chosen by the device, based on the hash of a public key.

All communication would be secured at the IP level, if you have the right IP, it's all good, if you want to refresh your "certificate" you just get a new IP and tell DNS about it.

Since the last section of the address is enough to uniquely identify the device, you can move between providers while still keeping your cryptographic identity.

Which also means that any kind of decentralized DHT routing can work transparently, the first half of the address is just routing info you can ignore if you have a better route, like being in the same LAN.

DNS servers could also also let you look up the routing info just given the crypto ID of a node, so you don't need a true static IP.

You could also do the same lookup with a local broadcast, and then cache the result for later use, so your phone can find your IoT devices, and then access them on the go with the cached routing info, if DNS is down.

A special TLD could exist that's just the crypto ID in base64, that doesn't require any registration. You can't spam too many of them, because you can reliably IP identify customer numbers unlike with ipv6 which makes that rather hard.


This is the first time I've ever posted an XKCD link here, but I think the occasion calls for it.

https://xkcd.com/810/


I'm curious; I know the Sun workstations were generally well-regarded, but what was it about the Sun-3 specifically, that made it such an important quantum jump?1


In general of course you're right, and this is a very good point.

> Even doing work agilely with review every two weeks and the client only paying once they've reviewed and approved the work in that two week period, and approved your work plan for the next two week period, even with all that -- after a year or two they can still threaten or carry out legal action to try to claw back of some or all of the money they've paid you.

But I would've thought that way of doing things, sounded pretty ironclad. If in every fortnightly review of progress so far, they thought things were going well, how did they end up retroactively changing their mind after a year? Can you go into a little more detail about how things went wrong? Was it a case of 'they were a startup selling waterproof teabags, you built them an online store, turns out there is no market for waterproof teabags, and they were looking for someone to blame'?


Yes, and it's not just a binary. As a general rule – this has been verified in any number of cases – the more people are paying for something, the more respectful they are to the providers thereof, and the higher the perceived pay and status of the individual employee they are dealing with, the more respectful they are to that employee.


Sounds to me like a programming dream. The usual way of things these days is 'don't waste your employer's time trying to optimize; everything that can profitably be done has already been done by other people; you just have to accept that particular part of your skill set is useless'. Dojo would let you actually use a lot more of your skills.


Now I'm curious, 'Near 100% RH and temperatures in the 100s' should as the article says, be theoretically lethal; what are the precautions by which you avoid heatstroke, without air conditioning? (The one I thought of, if you have no air conditioning but you do have a fridge, was putting a bag of ice cubes on your head, but for some reason, people who live in hot countries, don't seem to do that.)


Wasn't VB5 backward-compatible? I thought VB.net was the first version that wasn't; what am I missing?


> The first benchmarks indicated the plain Archimedes had higher FP throughput than a 16MHz 386 with a 387.

I could imagine a plain Archimedes being competitive with a 386 in integer throughput, but an integer-only machine outdoing an FPU in floating-point performance would be very surprising. I don't suppose you remember which benchmarks they were?


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You