None of the linked articles say that the 128 bits is for the filesystem only, but I still believe you're right:
Making the entire os 128-bit would simply waste a _lot_ of memory, for zero real gain. (Rather the opposite: A larger working set always leads to slower code.)
Having 128 bits available for filesystem/storage makes it quite feasible to have globally unique addresses for everything, across huge populations of machines.
This has been done before, afair IBM has used a 128 (or 129!) bit address space for their AS400 platform, where everything is memory mapped.
I.e. there is no visible file system, you just access objects by address (which is really a handle).
I believe Amazon's cloud storage is similar, in that the only way to access a blob of data is via a 128-bit handle.
I did my MSEE thesis in 1981, working on mono-mode optical fibers. This was still pretty cutting edge at the time, but the first semi-automatic splicing units had started to arrive.
The most fascinating feature of very pure optical fibers is that they have two minima not too far apart:
At around 1200 nm the frequency dispersion is very close to zero, which means that a single pulse traveling along the fiber will suffer minimum smearing, which maximizes the possible bandwidth.
At around 1500 nm the optical damping (i.e. sum of scattering & absorption) has a minimum, which means that by using this frequency you can maximize the distance between repeaters.
Anyway, it took about 20 years (i.e. around 2001) before mono-mode fibers become standard in all new installations here in Norway, it seems like this is the normal time to go from lab prototypes to SOP.
Until about 10 years ago, there were many magnesium manufacturers around the world, including one in my home town of Porsgrunn (in Norway).
When China decided that light metals was a crucial market for them, they started a bunch of very low-tech/high-pollusion magnesium smelters, and many/most Western competitors folded.
In the latest (for the year 1998) SFT (Norwegian EPA) regulations for the Porsgrunn factory (in norwegian), the limit on some pollutants was set to maximum 1 gram/year, I suspect the Chinese smelters are many orders of magnitude above this level.
I think it was Amdahl who said that a "supercomputer is a machine which is fast enough to turn cpu-bound problems into io-bound problems", which means that disk speed could become a limiting factor.
I have trouble seeing how having SSD arrays can make a big difference though!
All current supercomputers have enough RAM to handle the entire problem set, simply because _all_ disks, including SSDs, are far slower than RAM.
A supercomputer, like those which are used by oil companies to do seismic processing, does need fast disk, but only in order to load the input data, and this is an almost totally sequential process.
Regular disk arrays are just as fast as SSD arrays for sequential IO, so unless they have found a supercomputer problem which requires significant amounts of random access disk IO, having SSDs available should only provide marginal speedups.
Disclaimer: My first job after graduation was with SINTEF, next I worked 24 years for Hydro/StatoilHydro (Norway's largest offshore oil operator), where I (among many other things) specified how the production and admin networks should be separated on each platform.
First of all: Most North Sea platforms use fiber links these days, microwave is only there as a backup in case something cuts the fiber, which means that if you want to use the radio link as your attack point, you must first locate and disable the fiber(s).
Second, the production networks, which is the only part which can directly affect platform infrastructure has significantly better security than the office/admin net.
I.e. you would first have to hack into the regular StatoilHydro network, then find a way to pass through the admin/process firewall before you could even start to try to take over one or more control computers. (And afaik none of these run any form of open source SCADA sw.)
Finally, the 'integrated operations' mentioned in the article consists of special on-shore operations rooms which have strict physical security checks: The computers inside these rooms are indeed part of the production network, they have no direct links at all to the office/admin net and/or the Internet.
I've solved this problem by having a Win XP virtual machine: I put this machine on a second monitor (or external projector) and then I don't have to worry at all about the host OS being messed up.
Alternatively I can make it fullscreen on the primary/only screen.
This might actually make sense economically for ASUS:
_Maybe_ less support calls.
_Very deep_ discounts/kickbacks from Microsoft.
Personally I am very glad that I got the Linux version of my Eee PC 901: More flash disk and more ram, for a little less money. Currently I run the latest Ubuntu Netbook remix, and I'm very happy with it. The last time I booted it into XP must have been during Easter, to debug a Windows problem.
To make that mirror panorama image I needed 3 landscape format photos. In each direction I used bracketing to take 5 photos with 0.7 f stops between them, i.e. the total range was about 3 full stops or a factor of 8.
I then optimized a pano consisting of all 15 source images, merging each group of 3 with the same exposure into a separate layer.
Finally I used gradient filters, blending all 5 fixed-exposure panos into a final HDR pano.
It is quite interesting that the only two places on the Earth with significant amounts of fjords are located in Norway and New Zealand, two countries which are located more or less on opposite sides of the globe.
The New Zealand fjords are more remote, i.e. nobody actually lives there, and there is no infrastructure for a visitor, while the west coast of Norway has been inhabited since the last ice age, and the fjord system is significantly larger.
The original article is basically describing analog computing, where the most significant bits/digits are always correct, but the noise floor can/will eat the least significant parts, right?
I optimized the world's fastest Ogg Vorbis decoder back in 2007, and verified the results of my SIMD code by comparing the 32-bit floating point value of each resulting sample with that from the reference decoder:
Even though many parts of this process works very well with just 16-20 bits, and on something like a GameBoy 12-bit is perfectly fine, there are some very crucial steps in the algorithm that needs to be bit perfect:
The most important one is where the frequency envelope is approximated by a set of Bresenham-style line segments, and every single bit in those calculations _must_ be identical to the reference bits, otherwise the final audio will diverge rapidly.
What I'm trying to say is that probabilistic computing only works for some specific algorithms, and that it can be very hard to determine which is which up front.
For the first 2-3 years of PC history, the original Microsoft Flight Simulator was _the_ PC compatibility test:
If a machine could run MSFC, then it would also run retty much every other PcDos application on the market.
The first stumble came in 1984 with the PCAT, since the 6 MHz 286 cpu in this box meant that all the carefully tuned sw timing loops ran too fast and the simulator ran about twice as fast as it should.
As long as (most) disk activity can be stopped while the screen is locked, there is a solution which is both easy and safe:
The disk key in any reasonable full disk encryption setup is stored in encrypted form, meaning that the disk password is required to decrypt/retrieve it, right?
So what's stopping us from "simply" freezing all disk activity, then erasing the disk key from memory? (Keep the encrypted key from the disk master block if you want to, otherwise just re-read it when needed.)
Only after entry of a valid disk user/password combo can the real disk key be decrypted, so until that happens any "Cold Boot" attack will be just as useless as against a machine which has been powered all the way down.
The only question seems to be if it is actually possible to stop _all_ disk activity, or if a small unencrypted partition must be set aside for absolutely required background activity?
In the day of multi-core everywhere, a possible solution seems to be:
Dedicate one core to handle both screen unlock and disk encryption, but only when locking the machine.
On this core I would use one (128 bit) or two (256 bit) SSE registers to hold the disk key, and another register to hold the unlock credentials, then setup a static communication area where the other core(s) can leave messages, in particular an attempt to unlock the machine.
The dedicated lock core would stay in a loop, comparing the content with the unlock creds (i.e. hashed/salted password) and write the disk key back to memory upon receipt of a valid entry.
Using this approach means that you don't need to mess around with MTRRs or other cache control instructions, you just need to schedule everything else onto the other core(s), including all interrupts (which would (lazily?) writeback SSE register content on a task switch).
OTOH, there are of course some obvious downsides to this approach as well, in particular the fact that the locked core cannot go into a regular sleep mode, if said mode requires an interrupt to get back out of.:-(
The interesting part, at least to me, is the fact that the developers felt they had to reinvent (very badly) the algorithm to convert between day number and year-month-day, when correct & fast functions to do so have been public domain knowledge for a _very_ long time.
It is of course easy to convert from Y-M-D to daynr (year * 365 + number of leap days + days in previous months + day), particularly if you rotate the year a bit, making March 1st the first day of the year, since that removes the need to specialcase days in March or later in leap years.
Going in the opposite direction is slightly more interesting:
The best method I've found is to take advantage of the fast reverse conversion, by first guessing the approximate year, then adjust it if the reverse calculation comes out wrong.
Using this approach makes it possible to handle any legal Gregorian date up to some millions of years in the future (when 32-bit ints will overflow) and still do the conversion in about the same time as one or two integer divisions.
I know from the actual Novell developers (I worked for Novell in 1991-92) that on multiple occasions, Microsoft modified a new Dos version between the last beta and the actual release, in such a way that Novell's Netware client drivers stopped working.
Here in Norway authorities are trying to limit the use of studded tires,since they do chew up the asphalt pretty badly, particularly when the roads are wet from salting.
This is a problem both from the extra road maintenance it requires, and from the fact that in major cities it can lead to significant amounts of asphalt dust in the air on cold dry days. The latter is a big problem for people with asthma.
On our car we do have studded winter tires, to make trips to our cabin in the mountains of Telemark safer and more comfortable, but that means that we have to pay an additional road tax of NOK 1200 (about $200) per winter.
Here in Norway (nearly?) all speed trap cameras use roadbed sensors which detect each vehicle axle as the car/truck passes over it.
There are two such sensors a few meters apart, and the speed trap logic will calculate both the speed the car must have had between the two sensors, and the distance between the vehicle axles.
The gear is supposedly sensitive/accurate enough that the axle distance can be measured within a cm or so.
This still leaves a lot of possible car models, but it is used as a first-order check of the license plate OCR sw.
When the ticket is mailed to the (assumed) owner of the car, it includes a copy of the photo, so the owner can verify that it is indeed the correct car and driver.
If you ever need to have more than 48 bits to address unique items on interest, on a single network segment, then you'll have a problem.
2^48 is a pretty big number though. It is big enough that every human being on the planet can have about 60.000 addresses, on every single possible IPX network segment.
IPX won't run out before you do need that many single-segment addresses, and IPv6 is doing much of the same as IPX, by (at least by default) having the 48-bit MAC as the least significant part of the 128-bit address.
Disclaimer: I spent a year (91-92) working for Novell in Utah.
That said, IPX was in many ways both more forward-looking and easier to administrate than IP networks:
Instead of statically allocated local addresses or DHCP servers, IPX use the 48-bit MAC address as the only local identifier.
IPX and IP both use 32-bit external addresses, but the IPX 32-bit address is simply the address of the network, with no addressing mask to split it into net/host parts. This meant that clients could be plugged in anywhere and just worked, without any DHCP servers, and since each Netware server was allocated its own internal 32-bit network address, it was trivial to install multiple network cards for load balancing and/or redundancy:
If a single link went down, all traffic would automatically be rerouted to the other interface, while having a single unique server address.
This same mechanism was a key part of Software Fault Tolerant (SFT) NetWare, which used a mirrored (over a separate fast/high-bandwidth link) link to replicate all inputs between two servers: This allowed Drew Major (the chief architect) to keep the two servers in lockstep, and handle pretty much any kind of single disaster (up to and including smashing a server with a 100-ton press) without a single client drop.
As a programmer I really liked the way IPX used Async Event Blocks (AEBs) to control all send/receive operations, with optional application callbacks at interrupt time.
At one point (around 1988?) this allowed me to write an IPX-based print server under Dos, which managed to fit a dual-buffered print receiver, interrupt-driven serial and parallel port printer interfacing plus all the housekeeping needed for a TSR, inside about 1600 bytes.
This allowed 2x512 bytes as print buffers, 256 bytes as the local stack and about 300+ bytes for all the remaining code and data.
Magnetic tapes are used to store the raw data of seismic (oil) survey missions: Here in Norway we keep them in an underground temperature and humidity-controlled vault in the central part of the country.
Every 5 years all the pallets of tapes have to be taken out, re-read and copied onto newer technology tapes, but each time they find that this interval is sufficient to suffer permanent read errors on at least some tape files, which means that that particular piece of data is gone forever.
Slashdot Mirror
You're probably right. :-)
However, 256 bits is a _lot_ of bits:
The number of sub-atomic particles in the known universe has been estimated at around 1e80 (give or take a few orders of magnitude).
If we convert this number to binary, we get around 260+ bits, let's call it 256 for a nice, round number.
I.e. 256 bits is enough to address every single particle in all observable galaxies.
Terje
None of the linked articles say that the 128 bits is for the filesystem only, but I still believe you're right:
Making the entire os 128-bit would simply waste a _lot_ of memory, for zero real gain. (Rather the opposite: A larger working set always leads to slower code.)
Having 128 bits available for filesystem/storage makes it quite feasible to have globally unique addresses for everything, across huge populations of machines.
This has been done before, afair IBM has used a 128 (or 129!) bit address space for their AS400 platform, where everything is memory mapped.
I.e. there is no visible file system, you just access objects by address (which is really a handle).
I believe Amazon's cloud storage is similar, in that the only way to access a blob of data is via a 128-bit handle.
Terje
I did my MSEE thesis in 1981, working on mono-mode optical fibers. This was still pretty cutting edge at the time, but the first semi-automatic splicing units had started to arrive.
The most fascinating feature of very pure optical fibers is that they have two minima not too far apart:
At around 1200 nm the frequency dispersion is very close to zero, which means that a single pulse traveling along the fiber will suffer minimum smearing, which maximizes the possible bandwidth.
At around 1500 nm the optical damping (i.e. sum of scattering & absorption) has a minimum, which means that by using this frequency you can maximize the distance between repeaters.
Anyway, it took about 20 years (i.e. around 2001) before mono-mode fibers become standard in all new installations here in Norway, it seems like this is the normal time to go from lab prototypes to SOP.
Terje
Until about 10 years ago, there were many magnesium manufacturers around the world, including one in my home town of Porsgrunn (in Norway).
When China decided that light metals was a crucial market for them, they started a bunch of very low-tech/high-pollusion magnesium smelters, and many/most Western competitors folded.
In the latest (for the year 1998) SFT (Norwegian EPA) regulations for the Porsgrunn factory (in norwegian), the limit on some pollutants was set to maximum 1 gram/year, I suspect the Chinese smelters are many orders of magnitude above this level.
Terje
I think it was Amdahl who said that a "supercomputer is a machine which is fast enough to turn cpu-bound problems into io-bound problems", which means that disk speed could become a limiting factor.
I have trouble seeing how having SSD arrays can make a big difference though!
All current supercomputers have enough RAM to handle the entire problem set, simply because _all_ disks, including SSDs, are far slower than RAM.
A supercomputer, like those which are used by oil companies to do seismic processing, does need fast disk, but only in order to load the input data, and this is an almost totally sequential process.
Regular disk arrays are just as fast as SSD arrays for sequential IO, so unless they have found a supercomputer problem which requires significant amounts of random access disk IO, having SSDs available should only provide marginal speedups.
Terje
Disclaimer: My first job after graduation was with SINTEF, next I worked 24 years for Hydro/StatoilHydro (Norway's largest offshore oil operator), where I (among many other things) specified how the production and admin networks should be separated on each platform.
First of all: Most North Sea platforms use fiber links these days, microwave is only there as a backup in case something cuts the fiber, which means that if you want to use the radio link as your attack point, you must first locate and disable the fiber(s).
Second, the production networks, which is the only part which can directly affect platform infrastructure has significantly better security than the office/admin net.
I.e. you would first have to hack into the regular StatoilHydro network, then find a way to pass through the admin/process firewall before you could even start to try to take over one or more control computers. (And afaik none of these run any form of open source SCADA sw.)
Finally, the 'integrated operations' mentioned in the article consists of special on-shore operations rooms which have strict physical security checks: The computers inside these rooms are indeed part of the production network, they have no direct links at all to the office/admin net and/or the Internet.
Terje
I've solved this problem by having a Win XP virtual machine: I put this machine on a second monitor (or external projector) and then I don't have to worry at all about the host OS being messed up.
Alternatively I can make it fullscreen on the primary/only screen.
Terje
This might actually make sense economically for ASUS:
_Maybe_ less support calls.
_Very deep_ discounts/kickbacks from Microsoft.
Personally I am very glad that I got the Linux version of my Eee PC 901: More flash disk and more ram, for a little less money.
Currently I run the latest Ubuntu Netbook remix, and I'm very happy with it. The last time I booted it into XP must have been during Easter, to debug a Windows problem.
Terje
Thanks!
To make that mirror panorama image I needed 3 landscape format photos. In each direction I used bracketing to take 5 photos with 0.7 f stops between them, i.e. the total range was about 3 full stops or a factor of 8.
I then optimized a pano consisting of all 15 source images, merging each group of 3 with the same exposure into a separate layer.
Finally I used gradient filters, blending all 5 fixed-exposure panos into a final HDR pano.
Terje
I tried the system, using a high dynamic range pano that I'm very satisfied with, and which has received a bit of praise from other photographers:
http://norloff.org/pano/mirror5x3medium.jpg
According to the computer this image is worth 28.1 points.
I guess this means that either the image is a lot worse than I believed, or the rating system has problems with it. :-)
Terje
It is quite interesting that the only two places on the Earth with significant amounts of fjords are located in Norway and New Zealand, two countries which are located more or less on opposite sides of the globe.
The New Zealand fjords are more remote, i.e. nobody actually lives there, and there is no infrastructure for a visitor, while the west coast of Norway has been inhabited since the last ice age, and the fjord system is significantly larger.
Terje
The original article is basically describing analog computing, where the most significant bits/digits are always correct, but the noise floor can/will eat the least significant parts, right?
I optimized the world's fastest Ogg Vorbis decoder back in 2007, and verified the results of my SIMD code by comparing the 32-bit floating point value of each resulting sample with that from the reference decoder:
Even though many parts of this process works very well with just 16-20 bits, and on something like a GameBoy 12-bit is perfectly fine, there are some very crucial steps in the algorithm that needs to be bit perfect:
The most important one is where the frequency envelope is approximated by a set of Bresenham-style line segments, and every single bit in those calculations _must_ be identical to the reference bits, otherwise the final audio will diverge rapidly.
What I'm trying to say is that probabilistic computing only works for some specific algorithms, and that it can be very hard to determine which is which up front.
Terje
For the first 2-3 years of PC history, the original Microsoft Flight Simulator was _the_ PC compatibility test:
If a machine could run MSFC, then it would also run retty much every other PcDos application on the market.
The first stumble came in 1984 with the PCAT, since the 6 MHz 286 cpu in this box meant that all the carefully tuned sw timing loops ran too fast and the simulator ran about twice as fast as it should.
Terje
As long as (most) disk activity can be stopped while the screen is locked, there is a solution which is both easy and safe:
The disk key in any reasonable full disk encryption setup is stored in encrypted form, meaning that the disk password is required to decrypt/retrieve it, right?
So what's stopping us from "simply" freezing all disk activity, then erasing the disk key from memory? (Keep the encrypted key from the disk master block if you want to, otherwise just re-read it when needed.)
Only after entry of a valid disk user/password combo can the real disk key be decrypted, so until that happens any "Cold Boot" attack will be just as useless as against a machine which has been powered all the way down.
The only question seems to be if it is actually possible to stop _all_ disk activity, or if a small unencrypted partition must be set aside for absolutely required background activity?
Terje
In the day of multi-core everywhere, a possible solution seems to be:
Dedicate one core to handle both screen unlock and disk encryption, but only when locking the machine.
On this core I would use one (128 bit) or two (256 bit) SSE registers to hold the disk key, and another register to hold the unlock credentials, then setup a static communication area where the other core(s) can leave messages, in particular an attempt to unlock the machine.
The dedicated lock core would stay in a loop, comparing the content with the unlock creds (i.e. hashed/salted password) and write the disk key back to memory upon receipt of a valid entry.
Using this approach means that you don't need to mess around with MTRRs or other cache control instructions, you just need to schedule everything else onto the other core(s), including all interrupts (which would (lazily?) writeback SSE register content on a task switch).
OTOH, there are of course some obvious downsides to this approach as well, in particular the fact that the locked core cannot go into a regular sleep mode, if said mode requires an interrupt to get back out of. :-(
Terje
The interesting part, at least to me, is the fact that the developers felt they had to reinvent (very badly) the algorithm to convert between day number and year-month-day, when correct & fast functions to do so have been public domain knowledge for a _very_ long time.
It is of course easy to convert from Y-M-D to daynr (year * 365 + number of leap days + days in previous months + day), particularly if you rotate the year a bit, making March 1st the first day of the year, since that removes the need to specialcase days in March or later in leap years.
Going in the opposite direction is slightly more interesting:
The best method I've found is to take advantage of the fast reverse conversion, by first guessing the approximate year, then adjust it if the reverse calculation comes out wrong.
Using this approach makes it possible to handle any legal Gregorian date up to some millions of years in the future (when 32-bit ints will overflow) and still do the conversion in about the same time as one or two integer divisions.
Terje
This should be the proper version of the quote:
I know from the actual Novell developers (I worked for Novell in 1991-92) that on multiple occasions, Microsoft modified a new Dos version between the last beta and the actual release, in such a way that Novell's Netware client drivers stopped working.
Terje
Here in Norway authorities are trying to limit the use of studded tires,since they do chew up the asphalt pretty badly, particularly when the roads are wet from salting.
This is a problem both from the extra road maintenance it requires, and from the fact that in major cities it can lead to significant amounts of asphalt dust in the air on cold dry days. The latter is a big problem for people with asthma.
On our car we do have studded winter tires, to make trips to our cabin in the mountains of Telemark safer and more comfortable, but that means that we have to pay an additional road tax of NOK 1200 (about $200) per winter.
Terje
Oops! Mea Culpa.
You're totally right, and I really should know better. :-)
Terje
The UTC second 60 gets added at midnight only at those locations where UTC == local time, i.e. places like England.
For us in the rest of Europe, the leap second will be added an hour after local midnight, i.e. at 01:00:60 CET.
Terje
The SMS channel uses 7-bit ascii, so those 160 characters are only using 140 bytes.
Charging for receiving messages, which some US carriers seem to do, is just adding insult to injury.
Terje
Here in Norway (nearly?) all speed trap cameras use roadbed sensors which detect each vehicle axle as the car/truck passes over it.
There are two such sensors a few meters apart, and the speed trap logic will calculate both the speed the car must have had between the two sensors, and the distance between the vehicle axles.
The gear is supposedly sensitive/accurate enough that the axle distance can be measured within a cm or so.
This still leaves a lot of possible car models, but it is used as a first-order check of the license plate OCR sw.
When the ticket is mailed to the (assumed) owner of the car, it includes a copy of the photo, so the owner can verify that it is indeed the correct car and driver.
Terje
If you ever need to have more than 48 bits to address unique items on interest, on a single network segment, then you'll have a problem.
2^48 is a pretty big number though. It is big enough that every human being on the planet can have about 60.000 addresses, on every single possible IPX network segment.
IPX won't run out before you do need that many single-segment addresses, and IPv6 is doing much of the same as IPX, by (at least by default) having the 48-bit MAC as the least significant part of the 128-bit address.
Terje
Disclaimer: I spent a year (91-92) working for Novell in Utah.
That said, IPX was in many ways both more forward-looking and easier to administrate than IP networks:
Instead of statically allocated local addresses or DHCP servers, IPX use the 48-bit MAC address as the only local identifier.
IPX and IP both use 32-bit external addresses, but the IPX 32-bit address is simply the address of the network, with no addressing mask to split it into net/host parts. This meant that clients could be plugged in anywhere and just worked, without any DHCP servers, and since each Netware server was allocated its own internal 32-bit network address, it was trivial to install multiple network cards for load balancing and/or redundancy:
If a single link went down, all traffic would automatically be rerouted to the other interface, while having a single unique server address.
This same mechanism was a key part of Software Fault Tolerant (SFT) NetWare, which used a mirrored (over a separate fast/high-bandwidth link) link to replicate all inputs between two servers: This allowed Drew Major (the chief architect) to keep the two servers in lockstep, and handle pretty much any kind of single disaster (up to and including smashing a server with a 100-ton press) without a single client drop.
As a programmer I really liked the way IPX used Async Event Blocks (AEBs) to control all send/receive operations, with optional application callbacks at interrupt time.
At one point (around 1988?) this allowed me to write an IPX-based print server under Dos, which managed to fit a dual-buffered print receiver, interrupt-driven serial and parallel port printer interfacing plus all the housekeeping needed for a TSR, inside about 1600 bytes.
This allowed 2x512 bytes as print buffers, 256 bytes as the local stack and about 300+ bytes for all the remaining code and data.
Terje
Magnetic tapes are used to store the raw data of seismic (oil) survey missions: Here in Norway we keep them in an underground temperature and humidity-controlled vault in the central part of the country.
Every 5 years all the pallets of tapes have to be taken out, re-read and copied onto newer technology tapes, but each time they find that this interval is sufficient to suffer permanent read errors on at least some tape files, which means that that particular piece of data is gone forever.
Terje