so the memory your preloaded applications are using gets written to a different part of the disk (which takes time).
I don't think that Microsoft programmers are so dumb that they would write memory info which they loaded programs (from disk) to a different part of the disk, taking time. Maybe YOU should take some time. To study how a virtual memory system works, and what is done with clean and dirty pages when they have to make room for other data.
The access time is also VERY low compared to a HDD
It depends. I have one of those "IDE Flash disk" modules in a system I want to keep as silent and lowpower as possible. It looks like a normal IDE connector (a bit larger) and plugs directly in the motherboard, looking just like a normal IDE disk to the BIOS, the OS, etc. (so you can just install your system on it and boot, read/write, etc. no special drivers or trouble with booting from USB)
However, this device is easily outperformed by any modern harddisk. It is fine for the application I use it for, but certainly not something I would want to have in my main system.
Parallel running of boot scripts has been standard in SuSE Linux for quite some time. It is usually the first thing I turn off. But then, I do not boot my systems very often.
In my experience, swapping to USB is usually much slower than swapping to harddisk.
You might think that flash memory is much faster than harddisk, but this is not really true (certainly for write). Try to benchmark a USB key and a modern harddisk. The disk will easily do 50-60 MB/s bulk transfers. Try to make the USB key do that.
You may gain a little because a flash key does not need to seek, and thus has less latency when a single disk is used as swap and filesystem and needs to seek between the swapspace and some files that are being processed. But that's it.
Rapid7's suggested action to mitigate this vulnerability: "Disable the binary blob driver and use the open-source 'nv' driver that is included by default with X."
This is as useless as suggesting "Install Linux" when a Windows vulnerability has been found!
Until a few decades ago, there was a worldwide system of shortwave radio stations sending telegrams and international phone conversations. With the advent of satellite (and later optical fibre seacable) links, those were one by one decommissioned and now there are only a few museum stations and some empty buildings remaining.
A sad thing when you visit one, but technology advances. Keeping old systems for redundancy is costly and will not really work when the service is called upon.
This is not going to happen, because the people making such decisions do not have such keyhole viewpoints. In real life, there is always a finite chance that something fails. There is no point in blindly changing the system because a flaw has been pointed out, especially not when changing to a system that has flaws as well. "it has worked well" is clearly contradicted by real incidents that happened even in countries that consider themselves well-developed. and there no known incidents with these voting machines (that are already being used for over 15 years).
The machines use EPROM for the software and EEPROM for the storage of parameters and the recording of votes. I don't know about the exact time FLASH was available but devices with EEPROM functionality are listed in my 1982 databook.
The EPROM devices are now being replaced by PROM (useless, because they could not be programmed on-board anyway) and the box is being sealed.
There is always a tradoff between cost, security and practicality. You cannot order the whole infrastructure to be rebuilt for every flaw that someone finds or imagines. The currently pointed-out flaws are real, but that does not mean you have to make drastic modifications or discard everything you have (or risk that this will be required at the next change in voting law).
The relevant item here is not the epoxy, but the code signing device underneath. They did not exist back then, at least not as off-the-shelf components available for civilian designs.
And don't forget the endless reports of some party going from 10% to 15% of the votes, with the presenter making the claim that this is an increase by 5%. Again and again and again. As if the programmer of the election graphics system would not be able to display some change percentage with each bar so that the presenter (who can subtract, but not divide, by head) can report it...
The excuse for that is of course: money. Those machines were quite expensive and have to be amortized over a large number of elections, and thus: years. It is not something that is being evaluated and upgraded all the time, like a PC.
Had they used a PC instead of this machine, and upgraded it to the latest state-of-the-art, it would maybe be replaced by a "trusted computing platform" system this or next year. However, in practice that would most likely have been a less accountable and less secure system than we have now.
It is true that some obvious defects should not have been there (like the possibility to open the hardware box and swap EPROMS without any trace like a broken seal), but it is not fair to claim that there should have been security features as we know them today (like signed software) implemented in a machine designed over 20 years ago.
This would be much like holding the government responsible for the absence of antilock braking, a feature that is required in today's new cars, in all of the current car fleet. If they had demanded that in 1980 all cars would have it now.
Technology progresses, insight in computer security progresses, hackers do things that we did not consider practical 20 years ago. (like exploiting stack overruns to run malicious code, while at that time it was only considered that they could be used to crash programs)
The reason this is generally considered a bad thing (and thus not done) is that it would be very easy to prove what vote you entered, and this could promote vote buying. (you deliver your "voted party X" proof to some agent and get cash or other advantages in return)
Having a paper trail of each vote would be very dangerous to voting security, as the team behind the table knows exactly in what sequence the voters have passed along the machine. So a sequential printout of all votes on the paper roll printer would be a very bad thing to have.
Remember that these electronic voting machines were designed and build in the eighties of the last century, and have been used ever since. What Microsoft does in an xbox360 is not relevant to what a small engineering company would have done over 20 years ago.
You could call it the disadvantage of an early rollout of modern technology. On the other hand, you can also claim that the current hardware can be understood by a causal onlooker with electronics and software background. It contains only off-the-shelf parts and the protest group was able to disassemble and analyze it (as well as port a chess program to the hardware) in a months time. Try that with an Xbox.
"My company, a fairly large telco, still uses social security numbers for non-financial purposes; mostly for our IT ticketing system. I find it amazing that in these times, with how easy it is to use an SSN to obtain credit, that any company still does this."
I would say that the problem is not that your company uses the numbers for non-financial purposes, but that it is easy to use it to obtain credit. *that* is the thing that should be fixed. Don't attempt to keep something like an SSN a secret, because that will certainly fail.
Here in the Netherlands we have our equivalent of the SSN printed on just about every document and letter, and nobody considers that a problem.
Even with a DTD, the CSS support still sucks. I use a DTD for IE6 as well, to fix the boxmodel, and with this same DTD IE7 still shows positioning and stacking bugs. (absolute and relative positioning do not work according to spec, and positioned elements still start a new stacking context making z-index inoperative)
Although I hold the same position, to my disappointment I read that there are not going to be any essential bugfixes before the release. They will just be looking at the things important to MS (i.e. the eye-candy, the smoothness of the installer), not the CSS bugs.
not too quick... the CSS support in IE7 still sucks badly when compared with competing browsers. sure it is better than IE6, but don't assume your valid CSS will work OK in IE7, it probably will not.
This does not really work. You can install multiple versions but they will all send the same browser version to the website and the "conditional comment" evaluation is also done using one version. That will break the methods you can use to have different versions of the browser looking at the same content in a way compatible to each of them.
Slashdot Mirror
so the memory your preloaded applications are using gets written to a different part of the disk (which takes time).
I don't think that Microsoft programmers are so dumb that they would write memory info which they loaded programs (from disk) to a different part of the disk, taking time.
Maybe YOU should take some time. To study how a virtual memory system works, and what is done with clean and dirty pages when they have to make room for other data.
The access time is also VERY low compared to a HDD
It depends. I have one of those "IDE Flash disk" modules in a system I want to keep as silent and lowpower as possible.
It looks like a normal IDE connector (a bit larger) and plugs directly in the motherboard, looking just like a normal IDE disk to the BIOS, the OS, etc.
(so you can just install your system on it and boot, read/write, etc. no special drivers or trouble with booting from USB)
However, this device is easily outperformed by any modern harddisk. It is fine for the application I use it for, but certainly not something I would want to have in my main system.
Parallel running of boot scripts has been standard in SuSE Linux for quite some time.
It is usually the first thing I turn off. But then, I do not boot my systems very often.
In my experience, swapping to USB is usually much slower than swapping to harddisk.
You might think that flash memory is much faster than harddisk, but this is not really true (certainly for write).
Try to benchmark a USB key and a modern harddisk. The disk will easily do 50-60 MB/s bulk transfers. Try to make the USB key do that.
You may gain a little because a flash key does not need to seek, and thus has less latency when a single disk is used as swap and filesystem and needs to seek between the swapspace and some files that are being processed. But that's it.
Rapid7's suggested action to mitigate this vulnerability: "Disable the binary blob driver and use the open-source 'nv' driver that is included by default with X."
This is as useless as suggesting "Install Linux" when a Windows vulnerability has been found!
Until a few decades ago, there was a worldwide system of shortwave radio stations sending telegrams and international phone conversations.
With the advent of satellite (and later optical fibre seacable) links, those were one by one decommissioned and now there are only a few museum stations and some empty buildings remaining.
A sad thing when you visit one, but technology advances. Keeping old systems for redundancy is costly and will not really work when the service is called upon.
This is not going to happen, because the people making such decisions do not have such keyhole viewpoints.
In real life, there is always a finite chance that something fails. There is no point in blindly changing the system because a flaw has been pointed out, especially not when changing to a system that has flaws as well. "it has worked well" is clearly contradicted by real incidents that happened even in countries that consider themselves well-developed. and there no known incidents with these voting machines (that are already being used for over 15 years).
The machines use EPROM for the software and EEPROM for the storage of parameters and the recording of votes.
I don't know about the exact time FLASH was available but devices with EEPROM functionality are listed in my 1982 databook.
The EPROM devices are now being replaced by PROM (useless, because they could not be programmed on-board anyway) and the box is being sealed.
There is always a tradoff between cost, security and practicality. You cannot order the whole infrastructure to be rebuilt for every flaw that someone finds or imagines.
The currently pointed-out flaws are real, but that does not mean you have to make drastic modifications or discard everything you have (or risk that this will be required at the next change in voting law).
The relevant item here is not the epoxy, but the code signing device underneath. They did not exist back then, at least not as off-the-shelf components available for civilian designs.
The elections are to be held next month. No way this modification can be ready in time.
That will require a hardware addition. The available printer is not accessible to the voter and does not print separate tags.
And don't forget the endless reports of some party going from 10% to 15% of the votes, with the presenter making the claim that this is an increase by 5%.
Again and again and again. As if the programmer of the election graphics system would not be able to display some change percentage with each bar so that the presenter (who can subtract, but not divide, by head) can report it...
The excuse for that is of course: money.
Those machines were quite expensive and have to be amortized over a large number of elections, and thus: years.
It is not something that is being evaluated and upgraded all the time, like a PC.
Had they used a PC instead of this machine, and upgraded it to the latest state-of-the-art, it would maybe be replaced by a "trusted computing platform" system this or next year.
However, in practice that would most likely have been a less accountable and less secure system than we have now.
It is true that some obvious defects should not have been there (like the possibility to open the hardware box and swap EPROMS without any trace like a broken seal), but it is not fair to claim that there should have been security features as we know them today (like signed software) implemented in a machine designed over 20 years ago.
This would be much like holding the government responsible for the absence of antilock braking, a feature that is required in today's new cars, in all of the current car fleet. If they had demanded that in 1980 all cars would have it now.
Technology progresses, insight in computer security progresses, hackers do things that we did not consider practical 20 years ago.
(like exploiting stack overruns to run malicious code, while at that time it was only considered that they could be used to crash programs)
The reason this is generally considered a bad thing (and thus not done) is that it would be very easy to prove what vote you entered, and this could promote vote buying.
(you deliver your "voted party X" proof to some agent and get cash or other advantages in return)
This is not an issue. The electronic voting machines here (the Netherlands) have a separate button for this purpose.
Having a paper trail of each vote would be very dangerous to voting security, as the team behind the table knows exactly in what sequence the voters have passed along the machine. So a sequential printout of all votes on the paper roll printer would be a very bad thing to have.
Remember that these electronic voting machines were designed and build in the eighties of the last century, and have been used ever since.
What Microsoft does in an xbox360 is not relevant to what a small engineering company would have done over 20 years ago.
You could call it the disadvantage of an early rollout of modern technology.
On the other hand, you can also claim that the current hardware can be understood by a causal onlooker with electronics and software background.
It contains only off-the-shelf parts and the protest group was able to disassemble and analyze it (as well as port a chess program to the hardware) in a months time.
Try that with an Xbox.
"My company, a fairly large telco, still uses social security numbers for non-financial purposes; mostly for our IT ticketing system. I find it amazing that in these times, with how easy it is to use an SSN to obtain credit, that any company still does this."
I would say that the problem is not that your company uses the numbers for non-financial purposes, but that it is easy to use it to obtain credit.
*that* is the thing that should be fixed. Don't attempt to keep something like an SSN a secret, because that will certainly fail.
Here in the Netherlands we have our equivalent of the SSN printed on just about every document and letter, and nobody considers that a problem.
Even with a DTD, the CSS support still sucks.
I use a DTD for IE6 as well, to fix the boxmodel, and with this same DTD IE7 still shows positioning and stacking bugs.
(absolute and relative positioning do not work according to spec, and positioned elements still start a new stacking context making z-index inoperative)
This has always been the only reasonable way to do it...
Don't use hacks that rely on CSS parsing bugs. Use conditional comments.
Although I hold the same position, to my disappointment I read that there are not going to be any essential bugfixes before the release.
They will just be looking at the things important to MS (i.e. the eye-candy, the smoothness of the installer), not the CSS bugs.
not too quick... the CSS support in IE7 still sucks badly when compared with competing browsers.
sure it is better than IE6, but don't assume your valid CSS will work OK in IE7, it probably will not.
This does not really work. You can install multiple versions but they will all send the same browser version to the website and the "conditional comment" evaluation is also done using one version.
That will break the methods you can use to have different versions of the browser looking at the same content in a way compatible to each of them.
The video capture functions of NVIDIA cards don't work under Linux either.
The TV out sort of works.