The next problem with batteries is going to be charging them. Having to wait overnight before your car has more zoom-zoom doesn't really cut it. A gallon of gasoline is about 33 kWh, so if you have a car with a 10 gallon tank and you fill it up in 2 minutes, that means that you are moving 330 kWh in.03 hours, so your instantaneous power would need to be 11 mega watts. That's a lot of juice and even if you have an ultracapacitor at the station to average out the flow from the grid, the cables you'd need to put it into the car would have to be pretty special.
I'm sure that some clever engineering will come up with a way to make this work but it's not a done deal yet. I wouldn't count fuel cells out. I would see it being a lot easier to fill a tank or swap a tank than to charge a battery/ultracapacitor at those levels or to swap out a battery (the tank should be simpler than a battery and less likely to have been damaged/worn out)
Well, as I said, I was looking at it as a possible back-end for a hosted backup service. So, it's not my pockets that would need to be deep, it's how many customers I could scrounge up. Taking my laptop (a little unusual) as a baseline with 1.5M files, 10,000 customers would blow right past what S3 is storing right now.
So, that was my point. For small uses (like a small-medium size business' data) it's probably just fine but if you are trying to build a business on top of it you might find it inadequate.
I looked at S3 with an eye towards using it as a backend for a hosted backup system (one of their recommended uses, in fact). The problem that I had with using it is that there is no transparency about their operations, no service level guarantees and really no information about just where things will work and where things will start to break down.
For example, the talk about S3's scalability as being "unlimited". In reality, nothing is unlimited. They might have an architecture that theoretically scales up indefinitely but the implementation could be quite lacking. I could see two ways to use S3 as backup storage - you could make a tar file or equivalent and put it into S3 or you could assign each individual file an S3 ID and put it in. The difference between the two approaches is huge in terms of the number of unique objects stored (I have over 1.5M files on my laptop. Now multiply that out by 10's of 1000's of users). Designing a system that can stores 100's of billions of unique objects is different from designing a system that can store millions of unique objects. Not knowing what S3's intended workload is, it's hard to design for using it.
Furthermore there are no guarantees about bandwidth, availability. There aren't even guidelines for how much they think is reasonable. If I were to design a service using them as a backend and then have big success, what happens? Even if they're willing to add capacity at a rapid rate, how rapidly can they add? If a customer calls and says "I can't access my data" - how does that get resolved? How global is S3? If I start picking up customers in Europe or Japan or China, what will happen?
So, I think S3 is a great service for small uses. It's not possible to build a larger business around it until they start being more transparent about how it works, what are reasonable uses for it and how it is being used currently.
As a developer, customers have asked me why I don't add S3 as a backend to my backup app. That would be reasonable, but what's in it for me? S3 doesn't have any kind of referral fee so I'm just handing them money and adding headaches for myself. If they want people to add it their apps they should set up a way that the developers can get a little piece of the action.
Realize that most scientific code probably still has lots of code in it written for the original CRAY system it ran on in the 80's, and you see why vector systems will live on for a while: code that was written for one will have to be used on a vector system. One has to have to luck to find a PhD student willing and able to rewrite the code for a new machine. Worse than that even. I was doing this back in the late 80's/early 90's and we spent a large amount of energy getting the FORTRAN compiler to automatically vectorize "dusty deck" (that would be code that was originally written on PUNCHCARDS) scientific code.
Parallel programming is hard. Vectorized code is kind of like parallel light in that it parallelizes very narrow operations without all that messy locking and message passing.
Oh, there was one thing that the vector excelled at that OS's do a lot of - memory copying. When we instrumented our kernel (4.3 BSD derived) we found that it spent an awful lot of time in bcopy. One of the guys spent a fair amount of time implementing a "vcopy" which would use the vector to copy large blocks of memory. On our smoking fast 237 MB/s bus with 8-way interleaved memory the scalar CPU would top out at around 25/30 MB/s due to the interaction of the cache and the memory subsystem. The vector, though, could move at bus speed. Unfortunately, I don't think it ever worked as well in practice as in theory because there was a lot of overhead in getting the vector started, checking to make sure that it wasn't busy doing other work, etc. A dedicated DMA unit would give you the same effect.
I haven't looked closely but I would guess (based on having worked at a manufacturer of vector supercomputers many years ago) that all of the machines represented on the Top 500 list are hybrid machines. All of the vector architectures I'm familiar with had a scalar processor to handle most of the housekeeping, run the OS, compilers and things like that. Vector processors aren't very good at doing things like that.
Vector excel at running through essentially loop operations. There's two components to their speed - one is the number of functional units that they have. Conceptually vector operations are applied across an entire array at once (in math speak, arrays are known as "vectors"). Hence they are automatically parallelizable and the more functional units you have the more of the operations can actually be applied in parallel. The other component, though, is their ability to run through data quickly. Since the vector knows that it will be running through a contiguous block of memory they can really get the memory system moving. Scalar processors and their caches are not designed for running in straight lines through data. It's pretty rare to see a cache that will go into a full streaming mode so they are continually starting and stopping the memory subsystem. A vector can issue prefetches for all of its data so you can build an interleaved memory system that will really move the data (we used to have 8-way interleave on our memory subsystem. The scalar didn't do all that well with that but the vector could max out the memory bus in a sustained manner).
Well, the reason that you can't remove the file is because you created it in/tmp which typically is set so that directory entries can only be removed by their owners. If you have made the link in a regular directory you would have been able to remove it.
Any competent law enforcement officer should be able to determine that a breadboard with some LEDs and a 9 volt battery is not a bomb or even a fake bomb, tell the young lady that wearning that shirt at the airport is a bad idea and let the whole thing drop.
Those guys weren't competent and I don't see why I should trust them with any form of weapon.
They did their jobs. A potential threat was quickly neutralized with no loss of life and a prankster was arrested. SInce when is it the job of the police to arrest pranksters or even silly MIT students? That's what everyone is up in arms about. Asking her what the thing on her shirt is, explaining to her that it's not a good idea to wear the shirt cause it makes people at the airport nervous those are fine. Arresting her and saying that she's lucky they didn't shoot her in the head? Not so good.
I don't like the security restrictions we are faced with these days, but given that the current threat to our airports (in the UK we had a carbomb attack on Glasgow airport at the start of the Summer) we must be prepared to make some sacrifices. Yah, and those carbombs had circuit boards, wires and flashing LEDs glued all over the outside of the car because, duh, you needs das blinken lights for der bomb to work.
Having looked at the photos, I have to say the police were right to react the way they did... and Star was very lucky to come away with her life. If she'd had a bottle of water with her it would have been bullet through the head time, no ifs, ands or buts.
The point was that the newspapers were *incorrect* (in the Jean Charles de Menezes case) and the police lied to the newspapers as was later shown by CCTV footage.
If your idea of presence of mind and restraint is not shooting a teenaged girl with a few blinking lights on her shirt in broad daylight I'd hate to see the kind of world you want to live in. This isn't like a kid jumping out in a dark alley with a realistic toy gun in his hand.
The police arrested her simply to show that they could. What she was wearing doesn't look like a bomb to anyone with an ounce of brains. It was worthwhile to check her out because someone unfamiliar with bombs and electronics thought what she was wearing was unusual but there was no crime committed. Boston police overreacted and wasted a lot of money and a lot of peoples time on the Aqua Teen Hunger Force devices and they overreacted here.
I'd say that the letter (the GPL) evolved after the fact to include the hardware. Come on, the right to modify the code is pretty useless if you can't *run* the code.
Well since I OWN the hardware. I should be able to make copies of it and sell bootleg Tivo's on the blackmarket. Who said that? In any case, anyone capable of copying Tivo's hardware designs and making bootleg's could easily remove the circuits that restrict what software runs on the box.
I would guess that Tivo's decision to lock out unauthorized software was made to prevent people from making versions of the Tivo code that don't need to talk to their (pay-to-use) service.
It doesn't matter if Tivo violates "the spirit of GPL" if that spirit isn't written clearly in the license. You're absolutely correct. That's why GPLv3 was introduced to close the loophole. It's up to the authors of the code to decide whether they will license their code under GPLv2 or move to GPLv3 (many, of course, already made the decision by promising to license their code under any future versions of the GPL).
Whining about the GPL being changed to close a loophole is in the same category as whining about people taking advantage of the loophole.
Rightly or wrongly the Free Software Foundation is not about making software that businesses can use to make money. Where an earth did you get this? Making money of GPL code is perfectly fine. Yes, it's fine to make money off of it. That, however, is not the reason why the FSF exists.
If you're a business and you want to use code that comes under the GPL you should be prepared to go along with what the community expects. If not, go find code that is licensed differently, like under BSD, or hey, consider *investing* some money in the software so that you can do whatever you like with it and license it however you like. And your last sentence is somewhat curious. If a Big (Evil) Company take GPL code, modify it, use it in their product and give back the changed source, what's wrong with that? GPL allows this. In fact this is the basic point in GPL license: you can change (and hopefully improve) the code but you have to give your changes to the rest of the world. On the other hand if the Big (Evil) Company makes their own in-house implementation, no-one but the company benefits from that. That's great. And if the community that created the code wants to change the license they distribute the code under to promote certain behavior, those who benefit from the community's work should be prepared to accept that or not benefit from that work. I don't know what's so hard about that concept.
I haven't looked at Tivo's modifications to the Linux kernel but I would wager that the majority of them are not useful unless you're running on top of Tivo hardware. Opening the source but not allowing you to modify and run it on the hardware you purchased runs contrary to the spirit of the GPL. I don't see why that's so hard to understand. Yes, it's legal. It's also legal to change the license to close the loophole and it shouldn't be a surprise to anyone, especially those exploiting the loophole, that that was done.
It's not *their* machine. It's *your* machine. You purchased it from them. It isn't rented or leased to you. Having the freedom to modify the software (that they based on GPL'd code) is pretty moot if you can't run it. It's a loophole in GPLv2 that they can do this to you. Closing that loophole is entirely in line with the stated goals of the FSF.
Well, there's a lot of different reasoning behind the GPL. One reason for the GPL is that to have you return to the community modifications and improvements that you make to code you receive from the community. Another reason behind the GPL, though, is to allow people who receive code from you (that you based on code received from the community) to *modify* the code. When the GPLv2 was written, the thinking was that requiring you to share the code would automatically allow people to make modifications to it.
Tivo found a way around it that stuck to the letter of the GPL but violated the spirit of the agreement. Certainly if you read what RMS has written about his philosophy about software the ability to change and modify software that you get is a keep part of his philosophy.
Rightly or wrongly the Free Software Foundation is not about making software that businesses can use to make money. It's about making software that people can share and modify freely. If you're a business and you want to use code that comes under the GPL you should be prepared to go along with what the community expects. If not, go find code that is licensed differently, like under BSD, or hey, consider *investing* some money in the software so that you can do whatever you like with it and license it however you like.
The problem with that philosophy is who gets to classify someone as reasonable?
Strangely enough, in the American system, the courts do. Many laws are based around what a "reasonable" person would do with the interpretation of reasonable being left up to the courts. It's impossible to write laws that take into account all possible situations. That's why we have a judicial system which as the job of interpreting the laws and applying them to real life situations.
It's called scaling. One server can't handle all of the time requests. The various servers use NTP to sync up to a good time source such as an atomic clock and correct their clocks and can then hand out the correct time to clients.
Oh, I just love being schooled by AC's who don't know what they're talking about.
So, there are numbers that floating point formats do not represent well. However, the world is not floating point numbers. And computer math is not just floating point numbers.
The number is stored in the XML as an ASCII represented decimal real number. They're not stored as binary floating point numbers and they shouldn't have the kind of brain damageness that floating point has.
Let's look at what's going on here.
User enters a number in a decimal format. User sees the number in a decimal format displayed on the screen. Excel apparently does not use floating point or it's got a lot of compensation because if you do things like multiple 12345.12345 * 100000000 you get 1234512345000 and not some weird approximation. I would guess that the XML output routine is using floating point (and why would be a good question).
Why is this a problem? Well, we don't know how many digits of precision to work with here or how to round things. If I write an app to work with the spreadsheet I'd probably use something like a Java BigDecimal to handle the numbers. But, I don't know how to round things out so that I get the right numbers. If I use a BigDecimal, 12345.123449999999 is going to be 12345.123449999999. If I multiple by 100000000 I will get 123451234499.99999 instead of 1234512345000 as I would expect from looking at the values that were put into the spreadsheet.
Excel should be putting the proper values out in the XML or the standard should define the form of rounding/conversion to be applied.
No, this is a pretty reasonable thing to point out. It wasn't a value that was undisplayed. When you look at the cell it shows it (in decimal) as 1234.1234 (without the cell rounding). So it shows you that on the screen but doesn't store it properly in the XML file. I would say it's a problem. If it were stored as a binary floating point number in the XML I'd say you might have a point, but if it's displayed on the screen in decimal and then the decimal value in the file is different, that's pretty broken. And it's not just broken, it's now damned hard to work with. What happens if you pull the value from Excel using VBA and then try to change a value in the XML? They're not going to be the same.
I don't know about that. Yes, taking control of the network and making things do what you want would require a lot of knowledge. Lots of hackers just like to "mess around" though and doing something that they think is l33t, like running a Quake server on a nuclear power plant network, could cause a lot of problems. These kinds of systems are not usually designed with a lot of redundancy at the software level. The people who build those kind of things just don't understand how to manage those kinds of things in software.
Case in point. Long ago I worked for a supercomputer manufacturer. Our system had a nifty temperature sensing and power control system that was all controlled from a small front end system, a 286 running Microport Unix. We could also do things like boot the system from that console and dial in to do remote diagnostics. I was working with a customer and he needed a patch so I started uploading it to main system via the modem link and a pass-through from the console into the main system (must have been Kermit). Things are moving along and then the main system crashes. For some reason it's overheating. OK, that's weird, we reboot and I start the upload again. System crashes again. About the third time we start putting two and two together and I go off and do some sleuthing around to figure out why that might cause a problem.
Well, it turns out that the hardware guys have the whole temperature and power control system running over an RS-232 line. Using a protocol that they designed that has no checksums, no framing, no resynchronization. And, a 286 running Microport is just not fast enough to handle two 9600 baud streams of data simultaneously and it starts dropping characters. Drop a few characters out of this unframed, unchecksummed data stream and it starts getting fan speed values (or whatever) mixed up with its temperature values and the control software thinks that the machines is melting down and turns it off - fast.
Our hardware guys were not stupid. They just weren't familiar with communications protocols, didn't bother to consult with the folks on the software side who were, and it had always worked in the lab and the field. I'm quite certain there are any number of pieces of software and hardware running around out there that would be very vulnerable to an unexpected change in the environment and the cascading effects would be incalculable.
Even if you do have safety protocols and interlocks in place, just shutting things down has costs. If you shut down a nuclear power plant, how much does it cost to bring it back on line? If you shut down a factory floor, how much does it cost you to not be producing, how much product will be spoiled and how much clean up will you have to do?
The risks are non-trivial and people believe that there networks are secure when in reality, someone probably installed a wireless access point somewhere or has a router bridging things (so that managers can look at "view only" data as one poster mentioned above) that just opens everything up.
It's not the same thing at all. You're saying that script kiddies will get caught because they had to sign their code. That's an assertation of fact, not an opinion. Factually, you're wrong because there are paths open for kernel level exploits that don't require you to get a certificate. See the point? It's not an opinion that you don't need the certificate, it's a statement of fact. Whether or not that makes signing the code useless is a matter of opinion, but the fact that signed drivers are not being vetted well enough to actually be "trusted" is a fact as shown by the exploit.
You've now written the same stupid thing in three places. Try reading and comprehending.
If you can exploit someone else's signed driver to get trusted access you don't need to apply for a certificate to sign your exploit. Therefore since you never applied for a certificate there's no way to track you down.
The problem isn't that the certificate issuing process is flawed. The problem is that a properly signed driver had a security hole that could be exploited. The GP was not asking what the process for issuing a vendor certificate was, but what the process for certifying the driver (i.e. making sure that it didn't have security holes) was.
Slashdot Mirror
The next problem with batteries is going to be charging them. Having to wait overnight before your car has more zoom-zoom doesn't really cut it. A gallon of gasoline is about 33 kWh, so if you have a car with a 10 gallon tank and you fill it up in 2 minutes, that means that you are moving 330 kWh in .03 hours, so your instantaneous power would need to be 11 mega watts. That's a lot of juice and even if you have an ultracapacitor at the station to average out the flow from the grid, the cables you'd need to put it into the car would have to be pretty special.
I'm sure that some clever engineering will come up with a way to make this work but it's not a done deal yet. I wouldn't count fuel cells out. I would see it being a lot easier to fill a tank or swap a tank than to charge a battery/ultracapacitor at those levels or to swap out a battery (the tank should be simpler than a battery and less likely to have been damaged/worn out)
Well, as I said, I was looking at it as a possible back-end for a hosted backup service. So, it's not my pockets that would need to be deep, it's how many customers I could scrounge up. Taking my laptop (a little unusual) as a baseline with 1.5M files, 10,000 customers would blow right past what S3 is storing right now.
So, that was my point. For small uses (like a small-medium size business' data) it's probably just fine but if you are trying to build a business on top of it you might find it inadequate.
I looked at S3 with an eye towards using it as a backend for a hosted backup system (one of their recommended uses, in fact). The problem that I had with using it is that there is no transparency about their operations, no service level guarantees and really no information about just where things will work and where things will start to break down.
For example, the talk about S3's scalability as being "unlimited". In reality, nothing is unlimited. They might have an architecture that theoretically scales up indefinitely but the implementation could be quite lacking. I could see two ways to use S3 as backup storage - you could make a tar file or equivalent and put it into S3 or you could assign each individual file an S3 ID and put it in. The difference between the two approaches is huge in terms of the number of unique objects stored (I have over 1.5M files on my laptop. Now multiply that out by 10's of 1000's of users). Designing a system that can stores 100's of billions of unique objects is different from designing a system that can store millions of unique objects. Not knowing what S3's intended workload is, it's hard to design for using it.
Furthermore there are no guarantees about bandwidth, availability. There aren't even guidelines for how much they think is reasonable. If I were to design a service using them as a backend and then have big success, what happens? Even if they're willing to add capacity at a rapid rate, how rapidly can they add? If a customer calls and says "I can't access my data" - how does that get resolved? How global is S3? If I start picking up customers in Europe or Japan or China, what will happen?
So, I think S3 is a great service for small uses. It's not possible to build a larger business around it until they start being more transparent about how it works, what are reasonable uses for it and how it is being used currently.
As a developer, customers have asked me why I don't add S3 as a backend to my backup app. That would be reasonable, but what's in it for me? S3 doesn't have any kind of referral fee so I'm just handing them money and adding headaches for myself. If they want people to add it their apps they should set up a way that the developers can get a little piece of the action.
Parallel programming is hard. Vectorized code is kind of like parallel light in that it parallelizes very narrow operations without all that messy locking and message passing.
Oh, there was one thing that the vector excelled at that OS's do a lot of - memory copying. When we instrumented our kernel (4.3 BSD derived) we found that it spent an awful lot of time in bcopy. One of the guys spent a fair amount of time implementing a "vcopy" which would use the vector to copy large blocks of memory. On our smoking fast 237 MB/s bus with 8-way interleaved memory the scalar CPU would top out at around 25/30 MB/s due to the interaction of the cache and the memory subsystem. The vector, though, could move at bus speed. Unfortunately, I don't think it ever worked as well in practice as in theory because there was a lot of overhead in getting the vector started, checking to make sure that it wasn't busy doing other work, etc. A dedicated DMA unit would give you the same effect.
I haven't looked closely but I would guess (based on having worked at a manufacturer of vector supercomputers many years ago) that all of the machines represented on the Top 500 list are hybrid machines. All of the vector architectures I'm familiar with had a scalar processor to handle most of the housekeeping, run the OS, compilers and things like that. Vector processors aren't very good at doing things like that.
Vector excel at running through essentially loop operations. There's two components to their speed - one is the number of functional units that they have. Conceptually vector operations are applied across an entire array at once (in math speak, arrays are known as "vectors"). Hence they are automatically parallelizable and the more functional units you have the more of the operations can actually be applied in parallel. The other component, though, is their ability to run through data quickly. Since the vector knows that it will be running through a contiguous block of memory they can really get the memory system moving. Scalar processors and their caches are not designed for running in straight lines through data. It's pretty rare to see a cache that will go into a full streaming mode so they are continually starting and stopping the memory subsystem. A vector can issue prefetches for all of its data so you can build an interleaved memory system that will really move the data (we used to have 8-way interleave on our memory subsystem. The scalar didn't do all that well with that but the vector could max out the memory bus in a sustained manner).
Well, the reason that you can't remove the file is because you created it in /tmp which typically is set so that directory entries can only be removed by their owners. If you have made the link in a regular directory you would have been able to remove it.
Any competent law enforcement officer should be able to determine that a breadboard with some LEDs and a 9 volt battery is not a bomb or even a fake bomb, tell the young lady that wearning that shirt at the airport is a bad idea and let the whole thing drop.
Those guys weren't competent and I don't see why I should trust them with any form of weapon.
The point was that the newspapers were *incorrect* (in the Jean Charles de Menezes case) and the police lied to the newspapers as was later shown by CCTV footage.
If your idea of presence of mind and restraint is not shooting a teenaged girl with a few blinking lights on her shirt in broad daylight I'd hate to see the kind of world you want to live in. This isn't like a kid jumping out in a dark alley with a realistic toy gun in his hand.
The police arrested her simply to show that they could. What she was wearing doesn't look like a bomb to anyone with an ounce of brains. It was worthwhile to check her out because someone unfamiliar with bombs and electronics thought what she was wearing was unusual but there was no crime committed. Boston police overreacted and wasted a lot of money and a lot of peoples time on the Aqua Teen Hunger Force devices and they overreacted here.
I'd say that the letter (the GPL) evolved after the fact to include the hardware. Come on, the right to modify the code is pretty useless if you can't *run* the code.
I would guess that Tivo's decision to lock out unauthorized software was made to prevent people from making versions of the Tivo code that don't need to talk to their (pay-to-use) service.
Whining about the GPL being changed to close a loophole is in the same category as whining about people taking advantage of the loophole. Rightly or wrongly the Free Software Foundation is not about making software that businesses can use to make money. Where an earth did you get this? Making money of GPL code is perfectly fine. Yes, it's fine to make money off of it. That, however, is not the reason why the FSF exists. If you're a business and you want to use code that comes under the GPL you should be prepared to go along with what the community expects. If not, go find code that is licensed differently, like under BSD, or hey, consider *investing* some money in the software so that you can do whatever you like with it and license it however you like. And your last sentence is somewhat curious. If a Big (Evil) Company take GPL code, modify it, use it in their product and give back the changed source, what's wrong with that? GPL allows this. In fact this is the basic point in GPL license: you can change (and hopefully improve) the code but you have to give your changes to the rest of the world. On the other hand if the Big (Evil) Company makes their own in-house implementation, no-one but the company benefits from that. That's great. And if the community that created the code wants to change the license they distribute the code under to promote certain behavior, those who benefit from the community's work should be prepared to accept that or not benefit from that work. I don't know what's so hard about that concept.
I haven't looked at Tivo's modifications to the Linux kernel but I would wager that the majority of them are not useful unless you're running on top of Tivo hardware. Opening the source but not allowing you to modify and run it on the hardware you purchased runs contrary to the spirit of the GPL. I don't see why that's so hard to understand. Yes, it's legal. It's also legal to change the license to close the loophole and it shouldn't be a surprise to anyone, especially those exploiting the loophole, that that was done.
It's not *their* machine. It's *your* machine. You purchased it from them. It isn't rented or leased to you. Having the freedom to modify the software (that they based on GPL'd code) is pretty moot if you can't run it. It's a loophole in GPLv2 that they can do this to you. Closing that loophole is entirely in line with the stated goals of the FSF.
Well, there's a lot of different reasoning behind the GPL. One reason for the GPL is that to have you return to the community modifications and improvements that you make to code you receive from the community. Another reason behind the GPL, though, is to allow people who receive code from you (that you based on code received from the community) to *modify* the code. When the GPLv2 was written, the thinking was that requiring you to share the code would automatically allow people to make modifications to it.
Tivo found a way around it that stuck to the letter of the GPL but violated the spirit of the agreement. Certainly if you read what RMS has written about his philosophy about software the ability to change and modify software that you get is a keep part of his philosophy.
Rightly or wrongly the Free Software Foundation is not about making software that businesses can use to make money. It's about making software that people can share and modify freely. If you're a business and you want to use code that comes under the GPL you should be prepared to go along with what the community expects. If not, go find code that is licensed differently, like under BSD, or hey, consider *investing* some money in the software so that you can do whatever you like with it and license it however you like.
The problem with that philosophy is who gets to classify someone as reasonable?
Strangely enough, in the American system, the courts do. Many laws are based around what a "reasonable" person would do with the interpretation of reasonable being left up to the courts. It's impossible to write laws that take into account all possible situations. That's why we have a judicial system which as the job of interpreting the laws and applying them to real life situations.
It's called scaling. One server can't handle all of the time requests. The various servers use NTP to sync up to a good time source such as an atomic clock and correct their clocks and can then hand out the correct time to clients.
867-5309
Ummm, that's what I said.
Oh, I just love being schooled by AC's who don't know what they're talking about.
So, there are numbers that floating point formats do not represent well. However, the world is not floating point numbers. And computer math is not just floating point numbers.
The number is stored in the XML as an ASCII represented decimal real number. They're not stored as binary floating point numbers and they shouldn't have the kind of brain damageness that floating point has.
Let's look at what's going on here.
User enters a number in a decimal format. User sees the number in a decimal format displayed on the screen. Excel apparently does not use floating point or it's got a lot of compensation because if you do things like multiple 12345.12345 * 100000000 you get 1234512345000 and not some weird approximation. I would guess that the XML output routine is using floating point (and why would be a good question).
Why is this a problem? Well, we don't know how many digits of precision to work with here or how to round things. If I write an app to work with the spreadsheet I'd probably use something like a Java BigDecimal to handle the numbers. But, I don't know how to round things out so that I get the right numbers. If I use a BigDecimal, 12345.123449999999 is going to be 12345.123449999999. If I multiple by 100000000 I will get 123451234499.99999 instead of 1234512345000 as I would expect from looking at the values that were put into the spreadsheet.
Excel should be putting the proper values out in the XML or the standard should define the form of rounding/conversion to be applied.
No, this is a pretty reasonable thing to point out. It wasn't a value that was undisplayed. When you look at the cell it shows it (in decimal) as 1234.1234 (without the cell rounding). So it shows you that on the screen but doesn't store it properly in the XML file. I would say it's a problem. If it were stored as a binary floating point number in the XML I'd say you might have a point, but if it's displayed on the screen in decimal and then the decimal value in the file is different, that's pretty broken. And it's not just broken, it's now damned hard to work with. What happens if you pull the value from Excel using VBA and then try to change a value in the XML? They're not going to be the same.
I don't know about that. Yes, taking control of the network and making things do what you want would require a lot of knowledge. Lots of hackers just like to "mess around" though and doing something that they think is l33t, like running a Quake server on a nuclear power plant network, could cause a lot of problems. These kinds of systems are not usually designed with a lot of redundancy at the software level. The people who build those kind of things just don't understand how to manage those kinds of things in software.
Case in point. Long ago I worked for a supercomputer manufacturer. Our system had a nifty temperature sensing and power control system that was all controlled from a small front end system, a 286 running Microport Unix. We could also do things like boot the system from that console and dial in to do remote diagnostics. I was working with a customer and he needed a patch so I started uploading it to main system via the modem link and a pass-through from the console into the main system (must have been Kermit). Things are moving along and then the main system crashes. For some reason it's overheating. OK, that's weird, we reboot and I start the upload again. System crashes again. About the third time we start putting two and two together and I go off and do some sleuthing around to figure out why that might cause a problem.
Well, it turns out that the hardware guys have the whole temperature and power control system running over an RS-232 line. Using a protocol that they designed that has no checksums, no framing, no resynchronization. And, a 286 running Microport is just not fast enough to handle two 9600 baud streams of data simultaneously and it starts dropping characters. Drop a few characters out of this unframed, unchecksummed data stream and it starts getting fan speed values (or whatever) mixed up with its temperature values and the control software thinks that the machines is melting down and turns it off - fast.
Our hardware guys were not stupid. They just weren't familiar with communications protocols, didn't bother to consult with the folks on the software side who were, and it had always worked in the lab and the field. I'm quite certain there are any number of pieces of software and hardware running around out there that would be very vulnerable to an unexpected change in the environment and the cascading effects would be incalculable.
Even if you do have safety protocols and interlocks in place, just shutting things down has costs. If you shut down a nuclear power plant, how much does it cost to bring it back on line? If you shut down a factory floor, how much does it cost you to not be producing, how much product will be spoiled and how much clean up will you have to do?
The risks are non-trivial and people believe that there networks are secure when in reality, someone probably installed a wireless access point somewhere or has a router bridging things (so that managers can look at "view only" data as one poster mentioned above) that just opens everything up.
It's not the same thing at all. You're saying that script kiddies will get caught because they had to sign their code. That's an assertation of fact, not an opinion. Factually, you're wrong because there are paths open for kernel level exploits that don't require you to get a certificate. See the point? It's not an opinion that you don't need the certificate, it's a statement of fact. Whether or not that makes signing the code useless is a matter of opinion, but the fact that signed drivers are not being vetted well enough to actually be "trusted" is a fact as shown by the exploit.
You've now written the same stupid thing in three places. Try reading and comprehending.
If you can exploit someone else's signed driver to get trusted access you don't need to apply for a certificate to sign your exploit. Therefore since you never applied for a certificate there's no way to track you down.
You missed the whole point.
The problem isn't that the certificate issuing process is flawed. The problem is that a properly signed driver had a security hole that could be exploited. The GP was not asking what the process for issuing a vendor certificate was, but what the process for certifying the driver (i.e. making sure that it didn't have security holes) was.