Has anyone done any research on how much 'energy' is stored in wind currents? How many wind turbines can we erect before we affect the climate by disrupting air currents?
Clearly you haven't done the back of the envelope calculation. Many people have looked at the problem and it's not a trivial one. First, to see how much wind could be harnessed see for ex. [0] or [1]. Assuming 100TW of power, it's ~10^7 turbines. If each one has 50*10^3 kg of steel, it's somewhere between 10^10 - 10^11 kg of steel. 100,000,000 tons if I'm not mistaking. It turns out that Japan produced as much steel on its own, just in 2014. If my estimate is off by a factor of 10, china produced 800 million tons of steel! Glassfibre could be challenging to scale, but it's hardly a scarce resource.
I can also see you have never worked or lived next to a wind turbine. I worked a few yards away from one for a year and the noise was imperceptible inside the building. (Mostly because, when it's moving fast, it's very windy, i.e. very noisy already due to the wind).
Finally, the migrant bird issue is an issue, but it's not hard to solve. Radar and Sonar systems exist to detect migrating flocks of birds and slow down the turbines [3]. But more importantly, buildings, skyscrapers and cars are the number one killer of birds (not turbines). Numbers would change, of course, if we truly tried to extract all accessible, high yield winds. But careful planning and technological solutions would mean that migrant birds would not be more affected than they are today by the human infrastructure.
I haven't seen this approach before, and I like the idea of it. Dunno if it fits for all goals though. Would it be effective if you just measured total hours?
Yes, but 1 hour is quite a big quantum (if you work out for 55 minutes, then stop, then what — all effort is lost?) Measuring minutes is better.
Another thing: the goal should be quite bold, bigger than you'd think first (something you can think of reaching in 2-3 years; don't worry, it will be faster). Some examples: do 10,000 push-ups. Save $100,000 (or give $100,000 to charity, whatever suits you best). Run 2,000 kilometers. You start slow, but your progress accumulates, and then accelerates.
Has anyone figured out how to deal with the issue of latency for space-based internet? Things like online games and video calls will just not work if the traffic hits space.
I could see an ISP offering a service where traffic that needs low latency gets routed on land, while web pages and the like get routed through space. At a cost, of course.
All of the past versions of "space internet" have been geostationary orbit, which is around 25,000-26,000 miles above sea level. The new iterations, such as SpaceX's idea, is to use many many more microsats and put them in LEO. Low Earth Orbit is closer to 750 or so miles above sea level. Since the ping latency of geostationary sat internet is around 500-700ms, it would be massively less for low earth orbit.
The two technical issues I'm aware of are the sheer number of satellites required for LEO internet, and the fact that you can't point your dish at a single place. There would need to be some sort of actuator or omnidirectional receiver for tracking to satellites at every client site. This makes the installation a bit trickier, but the ping times should be entirely reasonable provided someone gets the funding to put hundreds of satellites into an internet constellation.
As someone who has worked in this industry and seen a lot of these ideas fail first hand - another big challenge is going to be ground entry points. For GEO satellites, each satellite serves many customers and may only need maybe 2-3 (for redundancy) groundstations.
For LEO constellations, each satellite can only see a small portion of customers at any time and will quickly move out of coverage of a single point on the earth, requiring many groundstations.
Alternatively, the satellites can crosslink and eventually hit a groundstation, but these handoffs and trip lengths quickly get back to the ping latencies of making a single trip to GEO.
The article reads almost like a press release for ViaSat which uses a handful of big geostationary satellites. It even disparages the OneWeb LEO initiative saying it will be too expensive and take too long to build. I think the article was prompted by the dispute between American and Gogo. I'm not sure what it's doing here on HN, doesn't seem that interesting.
This actually exists in some countries. E.g. in Europe there are (were?) several companies selling modem/ISDN+satellite bundles. All the upstream and parts of the downstream would travel through land-line while larger downloads would be routed via the satellite. This also saves you from needing to have relatively expensive satellite upstream equipment.
Otherwise, with GEO/GSO satellites there is no way to get below ~280ms round-trip times.
The new services are set to use satellites in low Earth orbit. That only adds a few hundred miles to the distance your data has to travel. The added latency is measurable, but not very high.
The problem with existing high-speed satellite internet is that the satellites are all in geosynchronous orbit, which is about 22,000 miles up. For a roundtrip, your data has to go up to the satellite, down to the ground station, then back up to the satellite and back down to you, for a total of almost 100,000 miles, or more than half a second at the speed of light.
I wonder if there's any data on accidents/ traffic violations between the two companies. Tips are supposed to be for better service, and with driving the only way to provide better service is to be faster. My hypothesis would be that in attempts to be faster, drivers may be driving more dangerously, thus increasing accidents and/or traffic violations.
> with driving the only way to provide better service is to be faster
This isn't even close to the case - being friendly, having a clean and quiet vehicle, and providing a ride that is safe and not white-knuckle terrifying will all garner a lot more in tips from me than someone careening through traffic to save 30 seconds. I think your hypothesis is baseless.
Agreed. I nearly always tip with Lyft. One of the rare times I didn't was when a driver, in the interests of speed, decided to hit the gas and merge two lanes to the right without a turn signal, because he wanted to get ahead of the truck that was coming down the street. The other passenger (this was a Lyft Line) joked with him about how sometimes you just gotta drive like that. But that kind of driving not only ensured I didn't tip him, it also meant I gave him a bad rating and wrote some nasty feedback. I really don't appreciate having my safety compromised in the interests of saving 20 seconds.
Semi relevant: New York City advises you to "tip your driver for safety and good service" [1]. Kinda scary that safety is some optional thing that you do for the prospect of a passenger noticing it and paying you more...
there's a balance there: people are less likely to tip if they are driving dangerously as well. Of course, this is all assuming people's tips are really based on better service. I'm sure tips are like that in some cases, but in general I think the customer's general mood and generosity are far bigger factors.
Tips can be nice in certain situations, but I think people would prefer to just be paid more, so their income is stable and dependable.
Your comment made me stop and think about all the times I've seen someone complain about 'coding' on a whiteboard during interviews. Did those people learn 'computer science' entirely in front of a computer, and so sort of 'trial and errored' they're way to the correct answer? Not trying to claim one way is better than the other, but rather trying to understand why the argument over coding in interviews is so polarized.
I think the main problem with "coding on a whiteboard" during interviews is not that you have to reason about an algorithm without the help of a computer, but rather that you have very limited time to do so. You stand there, looking at an empty board, trying to come up with something sensible (or at least, a decent start) in a few seconds. In the meantime people are looking at you, waiting for your answer, which adds just a tiny bit of psychological pressure. :) This is a very different situation from sitting down at your desk and thinking an algorithm over, at your leisure.
I can only speak for myself, but I just want a keyboard and a screen. I don't need a compiler--it's just got to do with the transcription method, not because I need the write/execute/debug loop.
I'd be fine doing a coding interview with just Notepad.exe or vi or whatever. It takes me ~2 seconds to type a line of code, but more like 10 or 15 seconds to handwrite it [0], and my brain's just not used to that kind of latency. It trips me up.
Plus, on a whiteboard, the mechanics of "oops I need to insert a line... I guess I'll just write it down here and draw a big arrow... ok now I need to rename this variable, but now the name is really long and I can't fit it... wait, what was I doing?".
It just mucks up my process. I don't precisely conceive an entire subroutine before I put fingers to keyboard--my code evolves as I'm writing it. I edit, revise, rethink, and refactor constantly, long before anything's even compiled. Keys and screen facilitate that process a thousand times better than pencil and paper. Handwriting just isn't the best medium for code [1].
[0] And thank god I have a CS education, because if nothing else I at least learned how to write legible braces, brackets, ampersands, and at-signs by hand...
[1] OP is obviously a wonderful idea but that's because it's teaching aspects of CS that aren't code.
Yeah, I opened a can of worms with my comment, didn't I? For the record, I'm one of the people who has complained here on HN about whiteboard interviews. Just because they taught me that I rely a bit too much on the compile/run cycle doesn't mean that I think coding exercises at the whiteboard are the right way to do interviews!
I think your use of the term "latency" is a very good way to describe some of the problems around whiteboard coding.
I do not "trial and error" my way to correct answers, but I complain bitterly about whiteboard interviews. It's the wrong medium. I wouldn't mind at all being asked to use a pack of cards as a prop to talk through a sort algorithm, but asking me to write one out on a whiteboard is just hamstringing me.
For me, part of it is literally the whiteboard. I do almost nothing in real life on a whiteboard. I don't like writing on them. I'd much prefer a pencil and paper on a desk.
I would say, yes. Some programmers have trouble reasoning abstractly or think it somehow beneath themselves because it does not produce something real at the end.
There are also "programmers" who's entire method of work seems to be to copy+paste blocks of code from Stackoverflow, only changing the minimum amount to make something load and then move onto the next item in their hit list.
I've spent a good chunk of my waking life studying programming the past several years, in an effort to get good at this stuff and really understand what I'm doing. I am incredibly jealous that people get to be professional "programmers" without really caring.
Bitcoin private keys are 256bit ECDSA keys. The largest key (publically broken) of this type is ~114bit PS3 hardware key which took 17 months on ~2600 systems.
