Viable electric cars, light bulbs connected to wifi, Raspberry Pi, robots that run like cheetahs, quad copters, quantum computers...
But saying "I'm sure there might be a few but..." indicates your disposition will be critical of an objective response. You're probably going to argue that IoT light bulbs are just lightbulbs + wifi. But Edison didn't invent copper wire or glass, and nobody questions whether the lightbulb was an invention.
It's the same argument that no thoughts are unique, they are just derivative of prior thoughts. But the conclusion is hasty and incomplete. It's easy to deconstruct ideas (and inventions), a posteriori, into a collection of parts that existed prior. But the combination of those parts is what constitutes uniqueness.
"Just because I know how to write PHP doesn't mean I understand these vulnerabilities at all."
Ouch.
You need to know a lot more than PHP to make your toaster talk to your dishwasher. And I'm pretty certain it's not the Maytag Man who's going to make it happen.
The concern over securing mesh networks is real, but the argument in the article is terrible.
I don't know... a lot of terrible wifi router software is written in PHP, and it's not clear that you can expect something different from your microwave.
If you want to propose a solution to the problem, why not have everyone adopt UTC? Every programmer who has ever dealt with time deltas will give you a big hug.
That's called optimizing for the 5% use case at the expense of the 95%. I don't really want to get rid of time zones for the rare instances when I need to schedule transatlantic meetings at the expense of having no fucking idea what time shops are supposed to be open or that people are supposed to be at work without either reconstructing the time zone in my head anyway or keeping a massive table of local custom by region. If I fly to London and look at my phone (which compensates for time zones) and it says it's 1300, I figure it will be similar to 1300 at home in many ways: late but not too late for lunch, during normal working hours, and most everything is probably open. If I'm used to 2100 being that time of day, I am going to fly to London and see that it's 1300 and have no fucking idea what that means, except that back home I would probably be sleeping and thank you very much for that subtle psychological reinforcement of my jet lag, you've ruined my day just because you're a lazy programmer who doesn't want to worry about time zone conversions.
If you fly to Madrid and look at your phone you're still going to need that massive table of local custom by region, or you're going to be utterly baffled when most shops start closing at 13:30 and then reopen in early evening, and the restaurants are all closed at 18:00.
There's no shortage of international differences in opening hours, days and times and time-zones don't really get you very far towards understanding them.
But I would have to know that about Madrid either way. It would at least help to know when those times are relative to the local day cycle.
Time zones give me a few bits of information and knowing about local customs gives me the other bits, but the bits that are encoded in the time zone are bits I can ignore as soon as I change my clock, just as setting your zero helps you work out a physics problem. Instead you want me to worry about all the bits all the time. Why, to make it easier for computers? I thought computers were better than me at handling bits.
"If I fly to London and look at my phone (which compensates for time zones) and it says it's 1300, I figure it will be similar to 1300 at home in many ways: late but not too late for lunch, during normal working hours, and most everything is probably open."
Realize that you're on HN, where I've heard long arguments about why your laptop and/or phone should not adjust the timezone of the device based on location. People who argue with a straight face that "the vast majority of people want their laptop to display their home time when abroad".
It's rare that you have transatlantic meetings, but you fly abroad so often that you can't keep track of when the shops open? (your phone could compensate for that). Do you also flip the fuck out when you fly to Australia and it's goddamn Summer in January?
It would be confusing having the day change in the middle of the afternoon. I'd get to work on Monday but leave on Tuesday. If I told someone I'd do something on Wednesday, what would that mean? All the solutions I can think of are complex, thus negating the benefit of switching to UTC.
I like the "Zulu time" system used by pilots and the military. A time like 12:30 is understood to be local time, while 0730Z is unambiguously UTC.
It's only confusing because it's different from what you've been doing your entire life. The solution (hypothetically, as this will never happen in our lifetime) is a different paradigm. You could say, "I'll get that to you by COB Wednesday", and it's understood by custom that "Wednesday" means "the workday that began on Wednesday". But more likely is that you'd say, "it'll be on your desk by 06:00 on the fourth." Speech patterns would adjust.
It isn't even hypothetical. The speech patterns of all English speakers who spend a significant amount of midnights awake have adjusted precisely like that.
There was a lovely looped animation of the world's online activity over the course of 24 hours. Can't find it right now, but I'm pretty sure it was on HN. It really exemplified how daytime no longer relates so much to the presence of the sun in the sky as it does to the level of physical alertness and electronic communication. High noon is more like the median longitude of human and network I/O than it is solar noon.
Well you need to know what timezone you are in and change all your clocks anyway ... And nothing prevents you from changing your clock to the old local-time-zone.
I spent a year and a half working on a calendar application and timezones were by far the most complicated part of the application.
I agree that a lot of things would be easier it everyone used UTC without timezones. In England you might go to work at 09:00, while someone in California might go to work at 01:00.
When you setup a meeting, you would just need to say, "The meeting is at 04:00", which might be mid-day for California and really freaking early for London, but everyone would know that right away without doing any offset calculations.
Actually, this is a fabulous idea! Today people must communicate time+zone to understand when an event will occur, unless people are assuming the local timezone.
The thing is, little business is just local now.
Think about the process for scheduling meetings between coastal groups, time+zone information must always be communicated.
I suspect all the time zones are really costing us more work than than they benefit us.
Actually, I'd say that most business is still local. And making everyone wildly redefine what their even most simple definition of what a calendar day is doesn't seem to be useful.
I suspect the number of people who share the perspective of programmers working across international teams is a lot smaller than the programmers think.
Ever hear of someone missing a meeting because it was scheduled for 2:00EST and they thought it was 2:00PST? Ever see an email from an employer, or hear the news reminding you to change your clock this weekend? It's not a programming problem, programmers are just more keenly aware of it.
And it's not really a "problem" at all. Just an idiosyncrasy. Like imperial units.
I think a much better idea would be to give UTC time in addition to local time as a standard practice. That way everyone only needs to memorise their own offset, instead of looking up what a particular acronym means every time they need to. (And probably forgetting, if they don't do it that often).
totally agree with that. I'd say one of the main reasons it hasn't happened is there are way too many software/operating system patches to roll out and would cause way too much chaos.
It's similar in that it's peer-to-peer, but doesn't require an auth/directory server to establish connections. If any known peer is accessible, the two can authenticate directly.
Yep, that's what I meant by "accessible" too. But with Hamachi, there's a central service for client authentication. With freelan, peers authenticate directly via signed crts.
I looked into this heavily over the past few days. The punchline is this needs support for NAT traversal and some type of out-of-band way for clients to find each other.
NAT traversal is an implementation thing, and I favor Jabber as the out-of-band these days since everyone can get at least a GTalk account.
Though we now have libjingle, which basically merges both of these things and would probably elegantly solve the problem. But p2p vpn's aren't much use if you have to control the NAT router you're attached to.
Doesn't seem to be a problem with connecting with Pidgin, and I had it working with Wippien (sadly Wippien doesn't really work great with Win 7 or Linux).
Google has stopped federating with other Jabber services. They have replaced the GTalk Android app with the Google Hangouts app. They have started pushing people (forcibly) towards Google Hangouts instead of Google Talk. How long before XMPP support is dropped? I don't think we can claim that Google will keep it around for certain.
For VPN purposes, a throwaway Jabber account you use solely for that is perfectly acceptable though. The thing needed here is mostly a channel for two hosts to find their public IP addresses and communicate that information.
p2pvpn <http://www.p2pvpn.org/> uses BitTorrent trackers for it - which is actually a pretty good solution, but sadly also - no NAT holepunching or even UPnP yet.
Though I have been trying to find a VPN which uses a Tor hidden service to define network rendeavous point - since Tor is distributed and available, you could issue invites with the hidden service ID, and then send real IPs to members to establish P2P (so, not using the anonymity, just using it to bootstrap the network). SocialVPN does something similar, but I couldn't get it work reliably in tests (it would go up...then my hosts went down and I couldn't get them to appear to each other again).
With freelan, once the client has established a connection with any other known and accessible freelan client, a direct client-client connection can be made to anyone on the network, even if they are behind a NAT/firewall. I believe it's through a combination of tun/tap, UDP-punching, and proxying, but don't know for certain.
OpenVPN establishes a site-to-site or point-to-site VPN, but routing to the client still goes through the gateway server.
Freelan still requires a known "supernode" to broker the initial connection, but after that, they can either communicate directly or through peers.
