Bacteria isn't going to be an issue with this, not at 1000 degrees C. Doesn't take a specialist to understand that.
That's a terrible solution. It simply guarantees that there will be even more significant problems when you do trigger that Leap Minute. Having this occur every year or two means you have an incentive to handle it correctly. Having it occur once every 60-100 years means that no one will bother handling I correctly, or will implement handling it incorrectly.
Think of a critical system that hangs for a minute rather than a second. The results would be much more damaging.
That's like fixing a memory leak by adding more memory to your system. You're just pushing problems down the line and making them more significant.
Exactly. The system clock should be uniform and continuous down to the resolution of the system/hardware. All conversions to/from wall time (including time zones, DST, and leap seconds) should be done separately. The tz database/library is already capable of supporting that mode.
I think it was one of the biggest mistakes in time processing to have NTP adjust the system clock on a leap second. Have NTP include the current offset, even have something that automatically updates the leap second history file when NTP indicates a pending leap second (or is showing a different offset from the current database, which would indicate that a database update is needed, say for a system that's been turned off or disconnected for a long time - not perfect, but close).
This could be phased in in several ways, perhaps just changing it and overriding the few programs that would break (perhaps with a per-process flag to modify the kernel calls to get the time, which the tz library could take into account).
PLATO Plasma panel terminals (1973 or so) had the same thing. It was only 16x16, and wasn't "multi-touch", but worked well.
So, basically 40 year old tech.
Champaign and Urbana are the same system, working also with the University of Illinois.
They have the core network in place, City, schools, some businesses, and some under-served neighborhoods (using a federal grant), but progress in connecting other neighborhoods has been very slow. They're now working with another area company to install neighborhoods, but no good indication of how fast it will go. They've made some commitments, but only if enough houses in each neighborhood sign up.
The biggest problem I've seen is getting a competent company to do the work, and keeping people informed. I'm still hopeful, I want to get away from AT&T. The City/University group has been turned into a non-profit, and they've pledged that the network will be open to ISPs on an equal basis (though I assume that the company building out the home connections will get a chunk of any revenue for some time until they've recouped their investment).
Yeah, I really like the idea of setting up a bug tracking system for your competitor that all their customers can contibute to.
One of the biggest turn-offs to me is a company that doesn't have any good way to report bugs or to request changes. The ideal company for me would be one where every bug or suggestion either generates a new tracking entry or is assigned to an existing one, and that tracking ID is sent to me as a response.
Now I can see what's happening with an issue that affects me, I can provide further details when I see that no one else has pointed something out (or not create redundant reports when they have) - such a system should have a "me too" capability for tracking how many people have that issue without them all needing to take up support time by reporting it. It doesn't need to show all the developer notes on progress or specifics about internals, but it really isn't that hard to give a status update that's useful to the customer, or an explanation of why something isn't going to be done, work-arounds, etc.
Make it easy for your customer to find out the issues and you won't have as much of a problem with wild rumors and complaints and mobs with pitchforks.
Yes, security-related issues should be redacted. No big deal.
Shouldn't be any problem to restrict it to customers who request it, at least for non-consumer-based products, as long as there's a simple process for a prospect to be given access as well, but I really don't think it's worth the hassle of keeping access restricted. It would be interesting to see the sales/marketing response after seeing how mnay of their sales are contingent upon getting access to the bug tracking system.
I'm really looking forward to seeing how the Rift and the Glyph compare. They both seem to be converging from different sides to be very similar, but with the delivery tech being quite different. I'm excited about the form factor of the Glyph and the emphasis on audio. The video doesn't have the resolution of the Rift yet, but it sounds like it is still very good.
It would be really interesting to see innovations from both put together. I really like the idea of using micro-mirror arrays to create the virtual image, and I really like that the Glyph can be used without corrective lenses.
If the two companies could have merged and joined the best of both, that would have been really excellent.
It's not like it's a surprise that there's a lot of Netflix traffic. I could forgive an ISP for not having the connections in place to handle that amount of traffic if all of a sudden it sprang up, but they should be able to handle it by now.
Customers are paying for that level of service. If most of their traffic is coming from Netflix, that's because THAT'S what's driving their customers to pay more for higher speed service. That means that they're getting more money, but most of the capacity increase for their network can be concentrated on serving the Netflix traffic. That's probably less expensive than building out the capacity to handle all those high-bandwidth customers spreading it around more.
It would actually be fairly easy to show that it isn't traffic-analysis throttling going on - set up a server somewhere that you can get a 5Mbps stream going, and that also can get 3Mbps to Netflix, then use an un-encrypted port forward. Given that Verizon and Level3 have both shown that it's a bottleneck at their interconnect point, I'd expect that method to get you a full speed Netflix stream with no problem.
Now, that wouldn't necessarily be a real solution - the route you're getting would probably also be overwhelmed by the traffic if a large number of people were all routing traffic through it. What it does show is that Verizon needs to fix the bottleneck. That's what they're being paid for by their customers. The providers Netflix is using can handle the load, and they clearly have no incentive to not build out their networks in whatever way is needed to handle it properly.
If 90% of Verizon's traffic ends up coming from Netflix, so what? That means they only need 10% of their network for everything else. Their customers are already paying to receive that data, why should Netflix pay again?
The people talking about "unbalanced data flows" are missing the point. It wouldn't make things better if Netflix changed the protocol to require that customers send them as much data as they receive. Bits aren't a resource, nor are they toxic waste, the country won't start to tilt if Netflix sends too many bits in one direction without accepting the same number in return.
If that's the way it worked, then Netflix could simply set up a Cloud backup service.
My parents have an apple tree growing in the front that has apples that don't brown at all. They taste pretty good as well, and don't seem to have much of a problem with insects. I have no idea if the tree was grown from ra andom seed from an apple or what its lineage is, I don't think it's been grafted. Does that mean it's potentially worth something?
BTW, regarding the article - that's Urbana, Ohio. There's more than one Urbana (e.g. Urbana, Illinois, with the University of Illinois, not Urbana University). That confused me briefly!
Google contributes quite a bit, just because its software doesn't mean it's not creative.
I'd be willing to bet that he uses free software all the time. Why doesn't he think that's a worthwhile contribution?
You forgot Jony Ives and iOS7. He did fairly well with some earlier stuff, but ugh.
You're comparing Microsoft Windows to iOS? Why aren't you comparing Windows to OSX?
How locked down was Zune, how locked down is RT, how is it that the PC platform is becoming more locked down than Apple hardware?
We'd be in much better shape in a world where PPC and Alpha desktop computers were competing with ARM for marketshare, with OF still a relevant standard (rather than just having remnants left behind in the Linux kernel), rather than the total hash that's x86, BIOS, MBR, EFI.
The Apple partition map presaged GPT, OF (which Apple embraced) presaged EFI, all of it quite open. A large part of OSX is open source, and the documentation of everything is superb (I remember when the big criticism of MacOS was that you needed THREE VOLUMES of documentation to cover everything! I still have the phonebook version).
Yeah, iOS and iTunes is not very open, I'll give you that.
I don't like Microsoft, and I haven't liked them since I saw the price they wanted for their sort program for CP/M.
I will also never forgive Bill Gates for using a backslash as a path separator. Every time I hear someone speak a URL, saying "forward slash" I wince.
Microsoft did so many things that have set back the state of computing. Sure, maybe someone else would have screwed things up just as much, maybe even more, but in this world it's Microsoft's fault.
When the Morris worm was the big news, and the cost estimates were flying, I made the observation that MS had caused MUCH more economic damage, and they did it ON PURPOSE!
Man, I take issue with about 90% of what you say. Yes, there are people who are all rules, but I haven't found them more likely to be in an accident, mostly because they spend so much time worrying about the rules they hardly ever fly. What I did find was that people who didn't take flying seriously were the ones more likely to have problems, regardless of their attitude towards being a stickler for the rules. Now, I knew quite a few of the "old fart" pilots, they were great pilots. They also knew their limits, they knew the rules, and they didn't do stupid things. They weren't good because they ignored the rules, they were able to get away with ignoring SOME of the rules because they understood exactly what the rules were for and when you could bend them. You fly a haphazard traffic pattern with them, though, you'd get your ear chewed off.
My experience with FAA regulations is that most of them are more about common sense than blind obedience to stupid rules. If you read between the lines, most of them say "you can kill yourself, just don't kill anyone else, please." Many of the rest are about protocols, how you and other pilots can co-exist in the same airspace. That's as of 9/11, I pretty much stopped around then when stupid security regulations started coming out, so maybe things have changed.
The most dangerous people are yahoos who think the rules are dumb, they're better than the average pilot, they can get away with it, so why should they bother. People who say "flying is easy, any monkey can do it" tend to be like that. Yeah, the mechanics of flying are pretty straightforward, and most people can learn to do it, however I found that people who took longer to learn tended to be the ones that had the highest flying skills eventually.
If your instructor wasn't constantly testing your situational awareness, asking you what you'd do if something unexpected happened, either you had a poor instructor or you weren't paying attention. That's at least half of what your training is about.
If your plan of action if your elevator gets stuck is to ask your front seat passenger to climb into the back seat - well, I don't think you've really thought it through very well. You're either going to be in an uncontrollable spin well before he gets his seat belt unbuckled or the airplane is controllable and the last thing you want to do is push your CG backwards with limited elevator control. Fail.