In the meantime, plenty of people were writing things in Pascal for the Mac. You had a resource compiler with resource files. You could write things in C, on a Unix system. You could build things with "make". Most of the software tools used to compile Linux and most of the current standard software was already in existence. There were source code control systems. There was X Windows. There was TeX. There was PostScript. There were a LOT of things that make up the majority of the software tools still in use today, and most are very little changed since then.
Sure, git is better than CVS. A large part of that is due to the constraints of the available hardware, you simply couldn't have done git in 1985 with available hardware.
The basis for Object Oriented Languages was well established, as was the basis for multi-threading (see Path Pascal, C++, Smalltalk).
What's been done since then is to take advantage of the massive increase in speed and storage available. Sure, there have been some incremental improvements to languages and utilities and development environments, but the impact that's had compared to the hardware improvements is fairly small.
The main advances in programming have been with encryption and compression. Everything else would have fast-forwarded within a few years if today's hardware had all of a sudden been made available back then.
Your average desktop computer, compared to a system from 30 years ago, is over 7,000 times faster, has 3-6,000 times as much RAM and 1.5 million times as much persistent storage available, and can communicate over 4,000 times faster, and that's not even getting into graphics capabilities.
There's more code in the boot ROM than there was in the boot ROM plus OS plus several applications.
It's not that programming tools are so much better, or that programming techniques have advanced, it's that you can write programs with many fewer restraints.
Hmph, I've been using e-mail, online chat, forums, multi-player games for over 40 years, but I don't have a cell phone. I was telling relatives how cool things like e-mail and on-line communities were, but I barely have a Facebook account (created just so my family could share photos).
I was reisisting LinkedIn, finally gave in when an uncle sent me an invitation, and then I added my brother. No one else. My brother is an HR/headhunter type, so I guess I can forgive him using it.
I have a Twitter account. I've never posted to it, I barely check the one group I follow.
When the GlobalNet-connected AR/wearable tech finally gets here I may jump in, but so far everything I've seen has been so boring and stupid that Slashdot and the occasional Ars Technica post is about as Social Media as I get.
I wouldn't say the results are invalid, but the relevance is restricted to people who don't understand algorithms or statements such as "disk is slower than memory".
I once had to fix a program that was reading all the file names in a directory into a linked list, sorting it (using operations to retrieve, remove, and insert elements using an index, which worked by starting at the beginning of each list and counting elements until it got to the correct one), then using the resulting sorted list to process the first 10 files.
Rather than fix the abominably slow sort, I used the fact that all the file names were decimal numbers, and all the numbers were sequential, to scan the directory for the smallest number, then just increment that to find the next one. Needless to say, it was both much faster and used very little memory.
Algorithms matter, and the shame of ever faster processors and "more productive" languages is that too many programmers don't understand them.
Certainly CO2 shouldn't be used without previously rendering the person unconscious. I read that some studies had some indications of distress from straight N2 suffocation, hence using N2O first might be more humane.
Since part of the "humane" aspect of it is how it appears to observers, that should be taken into account as well. I don't know if CO2 would cause a faster death than N2 when used in conjunction with N2O, or if there's a difference in visible signs while it's happening.
Nitrous Oxide isn't a bad idea, followed by CO2 or N2 displacing all the O2, or simply lowering the pressure. Valium drip followed by ex-sanguination might be an effective method as well.
I'm generally not happy with the death penalty for various reasons, but if you're going to do it, do it right.
The section I quoted defines "Broadband Internet access sevice". What you're talking about is irrelevant for the purposes of this rule.
What the 25 Mbps / 3 Mbps defines is not "broadband" but "advanced telecommunications capability". See the actual rule (actually "Broadband Progress Report and Notice of Inquiry"):
The actual regulation is 8.5 pages, about 22K characters. The rest is commentary. You'll find the commentary in the Federal Register. You won't find it in the actual regulations (Code of Federal Regulations, CFR).
There's the index, 576 paragraphs of commentary of various sorts, 12 paragraphs of procedural stuff, APPENDIX A which contains the actual rule, and APPENDIX B which contains a required analysis of the rules. APPENDIX B alone is 110 pages long.
The 8.5 pages is the actual program. The rest is the README and HOWTO combined with the man/info page, the makefile, the comments that would be in the code and a code review. The code itself is presented as a diff onto the existing codebase. Since it's a scripting language, there is no binary.
That's not the legal definition of "broadband" in the context of this rule. Read the rule. It's right there in the definitions section. Pretty much any Internet connection except dialup is "broadband".
It isn't 400 pages of regulation, it's about 8.5 pages of (new/modified) regulation, including all the definitions, procedures for filing complaints, etc.
The other 391 pages are commentary, explaining the rationale, the legal authority, discussing the public comments and rebuttals, talking about the implementation and implications, and so on.
Saying this is 400 pages of regulation is totally false. The 400 pages are in fact going to be published, and can be used by courts when deciding cases influenced by the new regulations, but they are not themselves regulations.
Most of the 400 pages are commentary on the rules - justification, clarification, intent, responding to comments, legal authority, possible legal challenges, implications, etc.
I don't know about the "305 words" bit. The actual rule (the part that says "amend this part to read... renumber section x to y... insert a new section x that reads..." is 8.5 pages long (page 283 through 290, which is about half a page long). If I copy directly from the PDF version and run it through fmt (default 65 wide) it yields 347 lines, 22542 characters.
However, the heart of it is contained in 3 short sections, about 1200 characters depending on encoding and whether you include the editing directives:
8.5 No blocking. A person engaged in the provision of broadband Internet access service, insofar as such person is so engaged, shall not block lawful content, applications, services, or non-harmful devices, subject to reasonable network management.
8.7 No throttling. A person engaged in the provision of broadband Internet access service, insofar as such person is so engaged, shall not impair or degrade lawful Internet traffic on the basis of Internet content, application, or service, or use of a non-harmful device, subject to reasonable network management.
8.9 No paid prioritization. (a) A person engaged in the provision of broadband Internet access service, insofar as such person is so engaged, shall not engage in paid prioritization. (b) “Paid prioritization” refers to the management of a broadband provider’s network to directly or indirectly favor some traffic over other traffic, including through use of techniques such as traffic shaping, prioritization, resource reservation, or other forms of preferential traffic management, either (a) in exchange for consideration (monetary or otherwise) from a third party, or (b) to benefit an affiliated entity.
The definition in the rule makes no such reference to speed:
8.2 Definitions.
a) Broadband Internet access service. A mass-market retail service by wire or radio that provides the capability to transmit data to and receive data from all or substantially all Internet endpoints, including any capabilities that are incidental to and enable the operation of the communications service, but excluding dial-up Internet access service. This term also encompasses any service that the Commission finds to be providing a functional equivalent of the service described in the previous sentence, or that is used to evade the protections set forth in this Part.
I'd be curious to know what problems would have been found AT THE TIME (not now, a few years later), with the e-mail server itself (not web front-ends other than as actual vectors to compromise the system, not just an individual connection; is there any indication Clinton ever used a web front-end?), and compare that with the state.gov e-mail server (also at the same time).
Comparing this to someone using a gmail account is irrelevant. The biggest threat to security is probably going to be the people at a commercial business.
The distinction between "personal" or "private" or "government" e-mail systems is sort of dumb when she's using a specific system AS a "government" e-mail system. Perhaps she even had it authorized through whatever route that might take, maybe having State IT people take a look at it.
What were the data retention policies for the state.gov e-mail server at the time? Did they retain every single piece of mail, so you could ask now to see how many Viagra spams she received while in office? If she deleted a message, was it archived or is it gone now? Would outgoing messages be retained? What if an e-mail client was configured to send outgoing e-mail directly to the recipients server (I realize that's becoming harder to do now as more and more servers are set up to require relaying through an official authenticated server via DNS records, but what was the situation then?)
The people to put on the stand here are the IT people responsible for the state.gov e-mail servers and the IT people that Clinton used to set up her server.
Many years back is 9 (when that particular patent was filed) or 16 (based on the priority date, though I'm unclear what that priority date is based on).
Buying things over the Internet wasn't some stroke of genius, and couching things in standard patent-speak doesn't make it any more innovative.
Makes me want to file a patent on "A Method and System of Using A Computing Device", put in all sorts of vague claims with "data means" and "storage means" and "communication means" and "user interface means", include something really specific like "a processor using graphene), then wait until someone creates something nifty after graphene has become common in chip fabrication, then sue everyone for violating my innovative patent, since I was the only person in 2015 who could have foreseen graphene being used in computers.
Of course, as every new potential technology is reported on, I file a continuation on my patent and add in the new technology. Perhaps a cool new public key system is devised, I can toss using that as part of the data communications means of using my Computing Device.
This will cost me some money, of course, so I'll deserve a big payout at the end for having taken so much risk in developing my innovative technology.
I read a few of them. They appear to be continuations of continuations of continuations based on a foreign application of a continuation of....
Trying to figure out what was ACTUALLY claimed to be innovative a the priority date of 1999, and what was added since the iPod and other systems supposedly infringing came out, is pretty difficult. Indeed, trying to understand the claims themselves doesn't really tell you much, and I fail to see how ANY jury, with anyone with a hint of software knowledge excluded, could form a reasonable decision as to validity.
As near as I can tell from the ones I read, it's basically "You know that music and stuff you can download off the Internet onto a portable device? What if you had to pay for it first?"
There really is nothing more non-obvious than "sell something - OVER THE INTERNET".
With hardware support in the CPU this can be done properly.
CPU-unique public/private key pair generated by the manufacturer. Public key signed by manufacturer's private key. To install program, CPU public key is validated, program is encrypted with unique key, unique key is encrypted with CPU public key, program and encrypted key is sent to customer.
CPU would then be givent the execution key, which it decrypts internally with private key and saves securely (no access via JTAG, no instructions to access it in any way). Instructions are then decrypted on-the-fly into internal secure instruction cache. You could do the same thing with data, with specific instructions to read/write unencrypted (after all, you do have to get the results out somehow), using a random key internally generated by the CPU. That key could be read/stored, but only encrypted with the instruction key (and changing the instruction key would wipe the data key).
Encryption key for each block would include the location of that block (e.g. take decrypted key and hash with location, then use that as the key for the block). A final step could be to have a block of (encrypted) hashes of each block that would be verified as each block is decrypted (with immediate wipe of decryption keys and cached code if it fails).
Breaking the private key of an individual CPU would, of course, allow you to emulate such a processor and break any program that's been keyed to it, but if such a CPU also required booting into encrypted firmware it could be very difficult to do (assuming the hardware is properly hardened), with the only practical attack being to break it using the public key. If you could do that, there are much better targets to go after than to get a free copy of some expensive program.
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).
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.
Slashdot Mirror
In the meantime, plenty of people were writing things in Pascal for the Mac. You had a resource compiler with resource files. You could write things in C, on a Unix system. You could build things with "make". Most of the software tools used to compile Linux and most of the current standard software was already in existence. There were source code control systems. There was X Windows. There was TeX. There was PostScript. There were a LOT of things that make up the majority of the software tools still in use today, and most are very little changed since then.
Sure, git is better than CVS. A large part of that is due to the constraints of the available hardware, you simply couldn't have done git in 1985 with available hardware.
The basis for Object Oriented Languages was well established, as was the basis for multi-threading (see Path Pascal, C++, Smalltalk).
What's been done since then is to take advantage of the massive increase in speed and storage available. Sure, there have been some incremental improvements to languages and utilities and development environments, but the impact that's had compared to the hardware improvements is fairly small.
The main advances in programming have been with encryption and compression. Everything else would have fast-forwarded within a few years if today's hardware had all of a sudden been made available back then.
Your average desktop computer, compared to a system from 30 years ago, is over 7,000 times faster, has 3-6,000 times as much RAM and 1.5 million times as much persistent storage available, and can communicate over 4,000 times faster, and that's not even getting into graphics capabilities.
There's more code in the boot ROM than there was in the boot ROM plus OS plus several applications.
It's not that programming tools are so much better, or that programming techniques have advanced, it's that you can write programs with many fewer restraints.
Hmph, I've been using e-mail, online chat, forums, multi-player games for over 40 years, but I don't have a cell phone. I was telling relatives how cool things like e-mail and on-line communities were, but I barely have a Facebook account (created just so my family could share photos).
I was reisisting LinkedIn, finally gave in when an uncle sent me an invitation, and then I added my brother. No one else. My brother is an HR/headhunter type, so I guess I can forgive him using it.
I have a Twitter account. I've never posted to it, I barely check the one group I follow.
When the GlobalNet-connected AR/wearable tech finally gets here I may jump in, but so far everything I've seen has been so boring and stupid that Slashdot and the occasional Ars Technica post is about as Social Media as I get.
I wouldn't say the results are invalid, but the relevance is restricted to people who don't understand algorithms or statements such as "disk is slower than memory".
I once had to fix a program that was reading all the file names in a directory into a linked list, sorting it (using operations to retrieve, remove, and insert elements using an index, which worked by starting at the beginning of each list and counting elements until it got to the correct one), then using the resulting sorted list to process the first 10 files.
Rather than fix the abominably slow sort, I used the fact that all the file names were decimal numbers, and all the numbers were sequential, to scan the directory for the smallest number, then just increment that to find the next one. Needless to say, it was both much faster and used very little memory.
Algorithms matter, and the shame of ever faster processors and "more productive" languages is that too many programmers don't understand them.
Certainly CO2 shouldn't be used without previously rendering the person unconscious. I read that some studies had some indications of distress from straight N2 suffocation, hence using N2O first might be more humane.
Since part of the "humane" aspect of it is how it appears to observers, that should be taken into account as well. I don't know if CO2 would cause a faster death than N2 when used in conjunction with N2O, or if there's a difference in visible signs while it's happening.
Nitrous Oxide isn't a bad idea, followed by CO2 or N2 displacing all the O2, or simply lowering the pressure. Valium drip followed by ex-sanguination might be an effective method as well.
I'm generally not happy with the death penalty for various reasons, but if you're going to do it, do it right.
The section I quoted defines "Broadband Internet access sevice". What you're talking about is irrelevant for the purposes of this rule.
What the 25 Mbps / 3 Mbps defines is not "broadband" but "advanced telecommunications capability". See the actual rule (actually "Broadband Progress Report and Notice of Inquiry"):
http://www.fcc.gov/document/fc...
The actual regulation is 8.5 pages, about 22K characters. The rest is commentary. You'll find the commentary in the Federal Register. You won't find it in the actual regulations (Code of Federal Regulations, CFR).
There's the index, 576 paragraphs of commentary of various sorts, 12 paragraphs of procedural stuff, APPENDIX A which contains the actual rule, and APPENDIX B which contains a required analysis of the rules. APPENDIX B alone is 110 pages long.
The 8.5 pages is the actual program. The rest is the README and HOWTO combined with the man/info page, the makefile, the comments that would be in the code and a code review. The code itself is presented as a diff onto the existing codebase. Since it's a scripting language, there is no binary.
That's not the legal definition of "broadband" in the context of this rule. Read the rule. It's right there in the definitions section. Pretty much any Internet connection except dialup is "broadband".
It isn't 400 pages of regulation, it's about 8.5 pages of (new/modified) regulation, including all the definitions, procedures for filing complaints, etc.
The other 391 pages are commentary, explaining the rationale, the legal authority, discussing the public comments and rebuttals, talking about the implementation and implications, and so on.
Saying this is 400 pages of regulation is totally false. The 400 pages are in fact going to be published, and can be used by courts when deciding cases influenced by the new regulations, but they are not themselves regulations.
Most of the 400 pages are commentary on the rules - justification, clarification, intent, responding to comments, legal authority, possible legal challenges, implications, etc.
I don't know about the "305 words" bit. The actual rule (the part that says "amend this part to read ... renumber section x to y ... insert a new section x that reads ..." is 8.5 pages long (page 283 through 290, which is about half a page long). If I copy directly from the PDF version and run it through fmt (default 65 wide) it yields 347 lines, 22542 characters.
However, the heart of it is contained in 3 short sections, about 1200 characters depending on encoding and whether you include the editing directives:
The definition in the rule makes no such reference to speed:
I'd be curious to know what problems would have been found AT THE TIME (not now, a few years later), with the e-mail server itself (not web front-ends other than as actual vectors to compromise the system, not just an individual connection; is there any indication Clinton ever used a web front-end?), and compare that with the state.gov e-mail server (also at the same time).
Comparing this to someone using a gmail account is irrelevant. The biggest threat to security is probably going to be the people at a commercial business.
The distinction between "personal" or "private" or "government" e-mail systems is sort of dumb when she's using a specific system AS a "government" e-mail system. Perhaps she even had it authorized through whatever route that might take, maybe having State IT people take a look at it.
What were the data retention policies for the state.gov e-mail server at the time? Did they retain every single piece of mail, so you could ask now to see how many Viagra spams she received while in office? If she deleted a message, was it archived or is it gone now? Would outgoing messages be retained? What if an e-mail client was configured to send outgoing e-mail directly to the recipients server (I realize that's becoming harder to do now as more and more servers are set up to require relaying through an official authenticated server via DNS records, but what was the situation then?)
The people to put on the stand here are the IT people responsible for the state.gov e-mail servers and the IT people that Clinton used to set up her server.
Many years back is 9 (when that particular patent was filed) or 16 (based on the priority date, though I'm unclear what that priority date is based on). Buying things over the Internet wasn't some stroke of genius, and couching things in standard patent-speak doesn't make it any more innovative. Makes me want to file a patent on "A Method and System of Using A Computing Device", put in all sorts of vague claims with "data means" and "storage means" and "communication means" and "user interface means", include something really specific like "a processor using graphene), then wait until someone creates something nifty after graphene has become common in chip fabrication, then sue everyone for violating my innovative patent, since I was the only person in 2015 who could have foreseen graphene being used in computers. Of course, as every new potential technology is reported on, I file a continuation on my patent and add in the new technology. Perhaps a cool new public key system is devised, I can toss using that as part of the data communications means of using my Computing Device. This will cost me some money, of course, so I'll deserve a big payout at the end for having taken so much risk in developing my innovative technology.
I read a few of them. They appear to be continuations of continuations of continuations based on a foreign application of a continuation of ....
Trying to figure out what was ACTUALLY claimed to be innovative a the priority date of 1999, and what was added since the iPod and other systems supposedly infringing came out, is pretty difficult. Indeed, trying to understand the claims themselves doesn't really tell you much, and I fail to see how ANY jury, with anyone with a hint of software knowledge excluded, could form a reasonable decision as to validity.
As near as I can tell from the ones I read, it's basically "You know that music and stuff you can download off the Internet onto a portable device? What if you had to pay for it first?"
There really is nothing more non-obvious than "sell something - OVER THE INTERNET".
With hardware support in the CPU this can be done properly.
CPU-unique public/private key pair generated by the manufacturer. Public key signed by manufacturer's private key. To install program, CPU public key is validated, program is encrypted with unique key, unique key is encrypted with CPU public key, program and encrypted key is sent to customer.
CPU would then be givent the execution key, which it decrypts internally with private key and saves securely (no access via JTAG, no instructions to access it in any way). Instructions are then decrypted on-the-fly into internal secure instruction cache. You could do the same thing with data, with specific instructions to read/write unencrypted (after all, you do have to get the results out somehow), using a random key internally generated by the CPU. That key could be read/stored, but only encrypted with the instruction key (and changing the instruction key would wipe the data key).
Encryption key for each block would include the location of that block (e.g. take decrypted key and hash with location, then use that as the key for the block). A final step could be to have a block of (encrypted) hashes of each block that would be verified as each block is decrypted (with immediate wipe of decryption keys and cached code if it fails).
Breaking the private key of an individual CPU would, of course, allow you to emulate such a processor and break any program that's been keyed to it, but if such a CPU also required booting into encrypted firmware it could be very difficult to do (assuming the hardware is properly hardened), with the only practical attack being to break it using the public key. If you could do that, there are much better targets to go after than to get a free copy of some expensive program.
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.