In addition to the other replies regarding Coda and AFS, it should be mentioned that NFSv4 is a much-awaited improvement on NFSv3. It could turn NFS into a real alternative to SMB/CIFS in LAN setups and maybe even WebDAV in WAN setups (e.g. as in Apple's iDisk).
It supports ACLs, real/robust file-locking, encryption and authentication, compound RPCs to reduce network round-trips.
The Itanium instruction sets allows code to access between 32 and 128 general registers (aka integer registers), at the discretion of the piece of code, and 128 floating point registers. The sliding window design is for the integer registers 32-127 and can indeed be considered as a sliding window on a memory stack. It is up to each piece of code to decide how many registers it wants to use (in increments of 8 ?).
On top of that there is the ability to design a subset of the high registers (registers with an index higher than 32) as rotating. This makes modulo-pipelining worthwile by removing the requirement for register-to-register moves to push things down the (conceptual) pipeline at each iteration of the loop.
I am quite familiar with the distinction between ABI and API, and I really meant that C++ makes API evolution difficult because API changes have some much impact at the binary level, even when the language ABI is fixed. Since in my world 'ABI' == 'language ABI' (not necessarily universal, but common for compiler folks), I do not tend to think of those issues as ABI issues, but you might be correct in the more complete sense of ABI.
The "pure" language ABI issue also exists but the standard C++ ABI [*] gives some hope there. I wouldn't be surprised if we had more rounds of C++ ABI changes, but I expect those to occur years (decade?) apart, allowing for not-so-painful transitions.
[*] trivia: this standard ABI comes from the ABI standardization effort of Itanium compiler vendors ( Code Sourcery (for gcc) / HP / Intel / SGI ) to allow inter-linking of C++ binaries on the new platform. Since little was Itanium specific the gcc work benefited all platforms.
The issue is really with C++ APIs, because C++ programming interfaces typically expose implementation details (e.g. the class and/or vtable layout), so evolving APIs in a binary-compatible fashion is really difficult. Since we are talking about BeOS, you may be aware that Be was adding some padding space in their classes, to be able to add fields later without breaking ABI compatibility. Those kind of hacks only go so far.
I don't care much for Objective-C syntax (not at all actually), but it is much easier to avoid leaking implementation details at the binary level. The default in Objective-C (or at least in Apple's use of Obj-C) is pretty close to opaque C structs only accessed via functions. People have tons of experience on how to evolve such APIs in a binary-compatible fashion.
It is possible to define APIs in C++ that can evolve without breaking binary compatibility. It is just not idiomatic C++. It is also possible to produce bad APIs in C or Obj-C but problems are easier to avoid.
I know of a couple of cases of vendors stuck with egregious defects in their C++ libraries that cannot be fixed without breaking almost all C++ applications on the platform. C++ does lead to very fragile interfaces.
If the same amount of engineering work had been put into Be, there's no reason to assume it wouldn't have achieved just as smooth an integration.
There are quite a few reasons against this theory. The biggest one is that Be made the mistake of basing its API in C++ . C++ APIs do not evolve well, compared to Objective-C or plain-C APIs. This would have led to either API paralysis or to major incompatibilities between OS revisions.
I concur with the grand-parent guess, Apple would most likely be dead by now had Spindler gone for Be instead of Next.
If the Japan system is anywhere close to France's TGV, you are wrong, except for the diminishing returns part.
The TGV runs for long distances at its commercial top speed (250 km/h). Yet it doesn't achieve close to this speed on average. This is due to:
- stops (even if spaced far appart they still kill the average, mostly due to the
idle time but also to the braking/acceleration times).
Running at a theoretical 500km/h wouldn't cut the total travel time by much
unless stops were reduced even further (TGVs already don't stop very often).
- lowered speed on non-high-speed tracks
(approach to large cities (e.g., Paris, Lyon), or once out of the (incomplete)
high-speed network (e.g., after "Le Mans" on the western branch)
- high-speed portions with less than top-speed limits
Even high-speed tracks may not be straight/level enough to allow for
full speed. For example the Paris-Lyon portion of the network was opened
first (around 1981 ?) for speeds around 230km/h (or slower, I don't remember
exactly). Newer lines were built for 250km/h or higher where nature allows it.
- need to have some 'buffers' in the schedule
The train schedulers need to leave a bit of slack, otherwise the whole network
would collapse after the first 1min delay.
So the trains are not always running on the tightest possible schedule / fastest
speed, to allow to "catch-up" (on the tracks or with less time in the station) when
delays occur.
the Itanium is able to transcode PA-RISC instructions
This is not correct. One goal of the Itanium instruction set was to allow efficient software translation of PA code, but that's about all the support there is.
So are you. (well, not *completely*, I guess) short = at least 16 bits long = at least 32 bits int = at least as wide as short and no wider than long
So says the language spec.
Not at all, there is no such rule in the C standard.
IIRC the one rule that every C implementation must follow (C99) is:
1 == sizeof(char) I don't know about that, but the amd64 native data size is 32 bits
Your sentence is so unclear that it is hard to know how invalid it is. Are you talking about the 32bits 'compatibility' mode (which can be argued is not the 'real' AMD64), the instruction encoding (where, IIRC, 64bit operations indeed have a new qualifier, but this doesn't make them not native) or the ALU/register file bitsize (which is 64bit) ?
I don't see anything in AMD64 that would make your claim valid (and I am no particular fan of x86-64).
All in all you seem pretty confused about that 64 bits thing.
it's all PDF underneath which handles vectors just fine
You are correct in stating that Quartz handles vectors just fine. Quartz (split into the Quart 2D layer and the Quartz Compositor) is primarily a vector API. As all good vector APIs (e.g. SVG, Cairo), it can also deal with bitmap graphics, hence the confusion in some minds.
Yet PDF is _not_ underneath. Quartz uses the same graphics model first introduced in Postscript, then re-used in PDF/Java 2D/GDI+/Quartz/(maybe others ?) . Still, no PDF is generated/rendered in a call to NSBezierPath while rendering on screen. PDF can be generated if the graphic context requires it (typically when printing).
See this post, other posts by mpaque (Mike Paquette, one of the main developers of Quartz and previously of Next's graphics) and check the dev documentation from Apple.
The first-poster was quite misleading or is not quite grasping the layering in the OS X graphics subsystem. Quartz can handle vectors perfectly fine, as you noted. Yet the OP was also correct in stating that _Aqua_ is mostly bitmap-based (today). Once GPU acceleration is available for the Quartz layer (with Quartz 2D Extreme, see my other post in this discussion), we are likely to see more UI elements rendered from vector descriptions (at least rendered once per size and cached, I don't see the interest in re-rendering the same bits over and over).
I don't have a time marker in the stream, but Quartz 2D Extreme is demonstrated. It is the OpenGL/GPU-accelerated implementation of the Quartz 2D vector library.
The other reply to your post was also somewhat correct in stating that Apple is already using the GPU to accelerate Quartz. However it is only the compositing layer that is accelerated (Quarz Extreme, note the absence of '2D' in the name), at least until Tiger/10.4 ships. There are excellent presentations of Quartz Extreme available on the net (from Apple folks).
note that the "at least 64-bit type" C9X mandates is called long long int
Warning: nitpicking ahead.
I haven't seen such a mandate in the standard. In fact I am pretty sure that a C implementation where 'long long int' would be a 32-bit integer could be standard compliant. "long long int" == "64bit signed integer" is just a common convention, not something you should base a portable program on.
The "at least 64-bit [signed integer] type" defined in C99 is int_least64_t, which is only mandated if the C implementation supports such an integer type. And if the same implementation support the "exactly 64-bit signed integer type", aka int64_t, then it is likely (but not required) that both types are the same.
Changing %lld to %"PRId64" is a favorite past-time of mine:-(
With 32 bit processors, you need four times the memory to run the same program as an 8 bit CPU
Absolutely not. Why should it be that way ? Think about it, if one processes a byte, it can be processed in the same way on an 8bit or on a 64bit processor.
Even instruction sizes are not correlated to 'bitness' (an overloaded term). Many 8-bitters had variable-size instructions, just like an x86. In general 64-bit processors do not have 64-bit instructions. Some 32bit processors have 16-bit instructions or the option to use 16-bit instruction formats for code-size optimization (e.g., the ARM Thumb).
If one were to use exclusively N-bit pointers (where N is the 'bit-size' of the processor), then yes. But why should one be that stupid ? If one only needs 64kB of memory for an application, one can use 16bits addresses to address it all, whether on an 8-bitter or a 32-bitter. Note also that many '8-bits' processors use 16bits addresses. One doesn't go very far by having only 256 addresses.
And even if one chose to use N-bit pointers, not everything needs to be adressed by a pointer. Displacement addressing can be very useful, even on machines with gobs of memory. I work pretty exclusively on 64-bit systems with GBs of memory, yet it is often useful to save memory by saving relative offsets (or array indices) when we know that we can fit those values in 16 or 32 bits. For modern processors adding an offset to a base pointer already in registers is almost free, while blowing a cache line can cost you hundreds or thousands of cycles.
The "dialect of Scheme" was not NewtonScript but the _intended_ language for the Newton, Dylan. The project did not deliver quickly enough, and NewtonScript replaced it.
NewtonScript is based on templates rather than the traditional class-based object protocol derived from Simula (the one model many C++/Java/C# programmers associate with "object orientation").
Practicing those alternative language make you feel very restricted when you come back to more mainstream languages. I really encourage you to look at Dylan. I never had the opportunity to use NewtonScript but I intend to find out someday.
Moore predicted his Law would run out in 2012 when 1 billion transistors are fit on a chip. Looks like we're ahead of schedule.
Intel's Montecito processor has been revealed to contain 1.7 billion transistors on a chip. It should ship next year. We're way ahead of that schedule (although I don't particularly trust that 'quote' of Morre's rule).
I lived less than 5 miles from a nuclear powerplant for the first 18 years of my life. I did an internship there when they built two new reactors (I got the opportunity to sit at the central control post and moved some valves a mile away using a trackball...).
I'd happily move back there if I could find a motivating and decently paying job around the area. I'd much rather live next to a nuclear powerplant run by the damn-serious people I met there than close to any chemical plant, coal powerplant, oil processing plant. I'd even prefer to be there (on the country side) than live in a large city. I used to run and hike in the forest close to the plant, and I can tell you that it was much healthier than breathing the air of any Californian city.
About at the same distance on the 'other side' were some pershing missile silos at a NATO base. We knew we wouldn't last long if Russia decided to invade Europe...
Ultimately, the Express needs to know how to decrypt that stream. The only way for that to occur is if it receives a decode key. And that information can be captured. Or so it would seem to me.
No, it wouldn't. That's the whole point of public-key encryption. Getting hold of the public key only allows someone to encrypt data. Only the owner(s) of the private key can decrypt said data.
Karma whoring: to understand who the poster is, please check this previous post of mine.
And for a one-post description of Quartz and links to Usenet posts from "mpaque", you can see this post.
Mike's post have always impressed me, hence the apparent fanboyism of those post. And the more experience I gain in this industry, the more I respect this king of professionalism in non-official communications.
The "firmware" (the equivalent of BIOS) they have on the Altix is pretty damn smart
As are most instances of EFI firmwares. SGI might add some features to their firmware (the E in EFI stands (or stood) for Extensible), but that's what you get with EFI. I can't wait to see EFI kill the IBM PC Bios.
You'd think that someone who is the spokeperson for the Patent Office would know the difference between discovered and invented.
The latin word for 'invent' (invenio IIRC) means both what the layman calls 'invent' and 'discover'. And those semantics are still present in English (and many roman languages).
You'll also find that in many cases 'invent' and 'discover' are used interchangeably, if not by the public at large, at least in law (IIRC ship wrecks are said to be 'invented' by the explorer who found them).
So my guess is that this spokesperson used perfectly adequate terms, but his speech may be too cultivated for this audience.
are the systems onboard a modern aircraft really so fragile that my cell phone will bother them?
Yes, they are. You have to understand that navigational aids used in airplanes have been designed about 50 years ago, when EM interferences wasn't as much of a concern.
For just a report of a _pager_ causing VOR gauges anomalies, read this callback issue. I believe I have seen more of the same in other issues, although I can't be bothered to check right now.
Now you invent a new O(N*ln N) factorization, or an O(N). Does it matter? Not really. You need a longer key, yes. But it's a finite improvement. Unless they can find a O(1) factorization, the system still works. And that, is very unlikely.
I don't quite have the time to refute this in depth, but this is completely wrong. Security of cyphers based on prime factorization depends on this operation being a very hard problem. A O(N) or O(N*ln N) (or even N^2 or N^p for smallish values of p) algorithm would make breaking those codes trivial for any practical key length. Remember that N is typically the size of the key, generally with an order of magnitude of a few thousands. We are not talking one-time pads here (where the key is at least as long as the data encoded, often longer since you want some padding to avoid leaking information).
I would advise anyone in doubt to go (back?) and (re-?) read Applied Cryptography from Bruce Schneier. Warning: it's not a page-turner !
As another poster stated, this in unlikely to happen.
High-performance graphic cards will require a x16 slot, and most motherboards will only provide one x16, multiple x1 and maybe a couple of x4.
Moreover the PCI-Express specs define power limits. All the Gfx vendors requested (and got) amazingly high power limits for graphic slots. Having two Gfx boards working at the limit would blow past the cooling abilities of most cases. While it will be possible for a PC manufacturer to provide multiple such slots, this will not happen in the value segment and may only be offered at a high cost premium (if at all).
What I am hoping for is for "secondary" cards working from a 4x slot, with limited performance and limited consumption. I could use a (or two) secondary display(s) while using flight simulators (e.g., for auxiliary panels or peripheral vision).
Note also that the PCI-SIG is close to making a decision on "second generation signaling rate". The debate is between 5Gb/s/lane (ie 2 times Gen I) or 6.25Gb/s/lane. A Gen-II 4x slot would provide enough bandwidth to feed a current high-end card.
Slashdot Mirror
answering questions regarding an unreleased, unanounced apple product
You mean this secret, unreleases, unannounced Apple product?
See this mailing list message, which points to this PDF presentation.
In addition to the other replies regarding Coda and AFS, it should be mentioned that NFSv4 is a much-awaited improvement on NFSv3. It could turn NFS into a real alternative to SMB/CIFS in LAN setups and maybe even WebDAV in WAN setups (e.g. as in Apple's iDisk).
It supports ACLs, real/robust file-locking, encryption and authentication, compound RPCs to reduce network round-trips.
NFSv4
The parent is not quite correct.
The Itanium instruction sets allows code to access between 32 and 128 general registers (aka integer registers), at the discretion of the piece of code, and 128 floating point registers. The sliding window design is for the integer registers 32-127 and can indeed be considered as a sliding window on a memory stack. It is up to each piece of code to decide how many registers it wants to use (in increments of 8 ?).
On top of that there is the ability to design a subset of the high registers (registers with an index higher than 32) as rotating. This makes modulo-pipelining worthwile by removing the requirement for register-to-register moves to push things down the (conceptual) pipeline at each iteration of the loop.
Thanks for the CEO correction.
I am quite familiar with the distinction between ABI and API, and I really meant that C++ makes API evolution difficult because API changes have some much impact at the binary level, even when the language ABI is fixed. Since in my world 'ABI' == 'language ABI' (not necessarily universal, but common for compiler folks), I do not tend to think of those issues as ABI issues, but you might be correct in the more complete sense of ABI.
The "pure" language ABI issue also exists but the standard C++ ABI [*] gives some hope there. I wouldn't be surprised if we had more rounds of C++ ABI changes, but I expect those to occur years (decade?) apart, allowing for not-so-painful transitions.
[*] trivia: this standard ABI comes from the ABI standardization effort of Itanium compiler vendors ( Code Sourcery (for gcc) / HP / Intel / SGI ) to allow inter-linking of C++ binaries on the new platform. Since little was Itanium specific the gcc work benefited all platforms.
The issue is really with C++ APIs, because C++ programming interfaces typically expose implementation details (e.g. the class and/or vtable layout), so evolving APIs in a binary-compatible fashion is really difficult. Since we are talking about BeOS, you may be aware that Be was adding some padding space in their classes, to be able to add fields later without breaking ABI compatibility. Those kind of hacks only go so far.
I don't care much for Objective-C syntax (not at all actually), but it is much easier to avoid leaking implementation details at the binary level. The default in Objective-C (or at least in Apple's use of Obj-C) is pretty close to opaque C structs only accessed via functions. People have tons of experience on how to evolve such APIs in a binary-compatible fashion.
It is possible to define APIs in C++ that can evolve without breaking binary compatibility. It is just not idiomatic C++. It is also possible to produce bad APIs in C or Obj-C but problems are easier to avoid.
I know of a couple of cases of vendors stuck with egregious defects in their C++ libraries that cannot be fixed without breaking almost all C++ applications on the platform. C++ does lead to very fragile interfaces.
If the same amount of engineering work had been put into Be, there's no reason to assume it wouldn't have achieved just as smooth an integration.
There are quite a few reasons against this theory. The biggest one is that Be made the mistake of basing its API in C++ . C++ APIs do not evolve well, compared to Objective-C or plain-C APIs. This would have led to either API paralysis or to major incompatibilities between OS revisions.
I concur with the grand-parent guess, Apple would most likely be dead by now had
Spindler gone for Be instead of Next.
If the Japan system is anywhere close to France's TGV, you are wrong, except for the
diminishing returns part.
The TGV runs for long distances at its commercial top speed (250 km/h). Yet it doesn't achieve close to this speed on average. This is due to:
- stops (even if spaced far appart they still kill the average, mostly due to the
idle time but also to the braking/acceleration times).
Running at a theoretical 500km/h wouldn't cut the total travel time by much
unless stops were reduced even further (TGVs already don't stop very often).
- lowered speed on non-high-speed tracks
(approach to large cities (e.g., Paris, Lyon), or once out of the (incomplete)
high-speed network (e.g., after "Le Mans" on the western branch)
- high-speed portions with less than top-speed limits
Even high-speed tracks may not be straight/level enough to allow for
full speed. For example the Paris-Lyon portion of the network was opened
first (around 1981 ?) for speeds around 230km/h (or slower, I don't remember
exactly). Newer lines were built for 250km/h or higher where nature allows it.
- need to have some 'buffers' in the schedule
The train schedulers need to leave a bit of slack, otherwise the whole network
would collapse after the first 1min delay.
So the trains are not always running on the tightest possible schedule / fastest
speed, to allow to "catch-up" (on the tracks or with less time in the station) when
delays occur.
That they did
Correct. Itanium started its life in HP Labs as 'PA Wide Word' before the HP-Intel alliance. Things evolved a good deal after that point though.
most PA-RISC code will run unmodified on Itanium machines.
That's correct, thanks to Aries.
the Itanium is able to transcode PA-RISC instructions
This is not correct. One goal of the Itanium instruction set was to allow efficient software translation of PA code, but that's about all the support there is.
Sorry, the comment above appears quite truncated due to the use of "less than" in the rule I quoted (of course I did not preview :-( ).
Damn.
So are you. (well, not *completely*, I guess)
short = at least 16 bits
long = at least 32 bits
int = at least as wide as short and no wider than long
So says the language spec.
Not at all, there is no such rule in the C standard.
IIRC the one rule that every C implementation must follow (C99) is:
1 == sizeof(char) I don't know about that, but the amd64 native data size is 32 bits
Your sentence is so unclear that it is hard to know how invalid it is. Are you talking
about the 32bits 'compatibility' mode (which can be argued is not the 'real' AMD64), the instruction encoding (where, IIRC, 64bit operations indeed have a new qualifier, but this doesn't make them not native) or the ALU/register file bitsize (which is 64bit) ?
I don't see anything in AMD64 that would make your claim valid (and I am no particular fan of x86-64).
All in all you seem pretty confused about that 64 bits thing.
it's all PDF underneath which handles vectors just fine
You are correct in stating that Quartz handles vectors just fine. Quartz (split into the Quart 2D layer and the Quartz Compositor) is primarily a vector API. As all good vector APIs (e.g. SVG, Cairo), it can also deal with bitmap graphics, hence the confusion in some minds.
Yet PDF is _not_ underneath. Quartz uses the same graphics model first introduced in Postscript, then re-used in PDF/Java 2D/GDI+/Quartz/(maybe others ?) . Still, no PDF is generated/rendered in a call to NSBezierPath while rendering on screen. PDF can be generated if the graphic context requires it (typically when printing).
See this post, other posts by mpaque (Mike Paquette, one of the main developers of Quartz and previously of Next's graphics) and check the dev documentation from Apple.
The first-poster was quite misleading or is not quite grasping the layering in the OS X graphics subsystem. Quartz can handle vectors perfectly fine, as you noted. Yet the OP was also correct in stating that _Aqua_ is mostly bitmap-based (today). Once GPU acceleration is available for the Quartz layer (with Quartz 2D Extreme, see my other post in this discussion), we are likely to see more UI elements rendered from vector descriptions (at least rendered once per size and cached, I don't see the interest in re-rendering the same bits over and over).
Apple haven't released anything like this yet. I didn't even realise they'd announced it.
Sure they have, although you had to pay attention to spot it (Graphics & Media state of the union).
I don't have a time marker in the stream, but Quartz 2D Extreme is demonstrated. It is the OpenGL/GPU-accelerated implementation of the Quartz 2D vector library.
The other reply to your post was also somewhat correct in stating that Apple is already using the GPU to accelerate Quartz. However it is only the compositing layer that is accelerated (Quarz Extreme, note the absence of '2D' in the name), at least until Tiger/10.4 ships. There are excellent presentations of Quartz Extreme available on the net (from Apple folks).
note that the "at least 64-bit type" C9X mandates is called long long int
:-(
Warning: nitpicking ahead.
I haven't seen such a mandate in the standard. In fact I am pretty sure that a C
implementation where 'long long int' would be a 32-bit integer could be standard
compliant. "long long int" == "64bit signed integer" is just a common convention,
not something you should base a portable program on.
The "at least 64-bit [signed integer] type" defined in C99 is int_least64_t, which
is only mandated if the C implementation supports such an integer type. And if
the same implementation support the "exactly 64-bit signed integer type", aka int64_t,
then it is likely (but not required) that both types are the same.
Changing %lld to %"PRId64" is a favorite past-time of mine
Please, call them prototypes, not templates
Ah yes, sorry, you are correct. It is prototypes. Thanks for the correction.
I use 'templates' in my applications when I use a similar technique, and I forgot the official designation.
With 32 bit processors, you need four times the memory to run the same program as an 8 bit CPU
Absolutely not. Why should it be that way ? Think about it, if one processes a byte, it can be processed in the same way on an 8bit or on a 64bit processor.
Even instruction sizes are not correlated to 'bitness' (an overloaded term). Many 8-bitters had variable-size instructions, just like an x86. In general 64-bit processors do not have 64-bit instructions. Some 32bit processors have 16-bit instructions or the option to use 16-bit instruction formats for code-size optimization (e.g., the ARM Thumb).
If one were to use exclusively N-bit pointers (where N is the 'bit-size' of the processor), then yes. But why should one be that stupid ? If one only needs 64kB of memory for an application, one can use 16bits addresses to address it all, whether on an 8-bitter or a 32-bitter. Note also that many '8-bits' processors use 16bits addresses. One doesn't go very far by having only 256 addresses.
And even if one chose to use N-bit pointers, not everything needs to be adressed by a pointer. Displacement addressing can be very useful, even on machines with gobs of memory. I work pretty exclusively on 64-bit systems with GBs of memory, yet it is often useful to save memory by saving relative offsets (or array indices) when we know that we
can fit those values in 16 or 32 bits. For modern processors adding an offset to a base pointer already in registers is almost free, while blowing a cache line can cost you hundreds or thousands of cycles.
The "dialect of Scheme" was not NewtonScript but the _intended_ language for the Newton, Dylan. The project did not deliver quickly enough, and NewtonScript replaced it.
NewtonScript is based on templates rather than the traditional class-based object protocol derived from Simula (the one model many C++/Java/C# programmers associate with "object orientation").
Practicing those alternative language make you feel very restricted when you come back to more mainstream languages. I really encourage you to look at Dylan. I never had the opportunity to use NewtonScript but I intend to find out someday.
Moore predicted his Law would run out in 2012 when 1 billion transistors are fit on a chip. Looks like we're ahead of schedule.
Intel's Montecito processor has been revealed to contain 1.7 billion transistors on a chip. It should ship next year. We're way ahead of that schedule (although I don't particularly trust that 'quote' of Morre's rule).
I lived less than 5 miles from a nuclear powerplant for the first 18 years of my life. I did an internship there when they built two new reactors (I got the opportunity to sit at the central control post and moved some valves a mile away using a trackball...).
...
I'd happily move back there if I could find a motivating and decently paying job around the area. I'd much rather live next to a nuclear powerplant run by the damn-serious people I met there than close to any chemical plant, coal powerplant, oil processing plant. I'd even prefer to be there (on the country side) than live in a large city. I used to run and hike in the forest close to the plant, and I can tell you that it was much healthier than breathing the air of any Californian city.
About at the same distance on the 'other side' were some pershing missile silos at a NATO base. We knew we wouldn't last long if Russia decided to invade Europe
Ultimately, the Express needs to know how to decrypt that stream. The only way for that to occur is if it receives a decode key. And that information can be captured. Or so it would seem to me.
No, it wouldn't. That's the whole point of public-key encryption. Getting hold of the public key only allows someone to encrypt data. Only the owner(s) of the private key can decrypt said data.
That was precisely mpaque's point.
Karma whoring: to understand who the poster is, please check this previous post
of mine.
And for a one-post description of Quartz and links to Usenet posts from "mpaque", you can see this post.
Mike's post have always impressed me, hence the apparent fanboyism of those post. And the more experience I gain in this industry, the more I respect this king of professionalism in non-official communications.
The "firmware" (the equivalent of BIOS) they have on the Altix is pretty damn smart
:-)
As are most instances of EFI firmwares. SGI might add some features to their firmware (the E in EFI stands (or stood) for Extensible), but that's what you get with EFI. I can't wait to see EFI kill the IBM PC Bios.
And now EFI is released under a BSD licence
You'd think that someone who is the spokeperson for the Patent Office would know the difference between discovered and invented.
The latin word for 'invent' (invenio IIRC) means both what the layman calls 'invent' and 'discover'. And those semantics are still present in English (and many roman languages).
You'll also find that in many cases 'invent' and 'discover' are used interchangeably, if not by the public at large, at least in law (IIRC ship wrecks are said to be 'invented' by the explorer who found them).
So my guess is that this spokesperson used perfectly adequate terms, but his speech may be too cultivated for this audience.
are the systems onboard a modern aircraft really so fragile that my cell phone will bother them?
Yes, they are. You have to understand that navigational aids used in airplanes have been designed about 50 years ago, when EM interferences wasn't as much of a concern.
For just a report of a _pager_ causing VOR gauges anomalies, read this callback issue. I believe I have seen more of the same in other issues, although I can't be bothered to check right now.
Now you invent a new O(N*ln N) factorization, or an O(N). Does it matter? Not really. You need a longer key, yes. But it's a finite improvement. Unless they can find a O(1) factorization, the system still works. And that, is very unlikely.
I don't quite have the time to refute this in depth, but this is completely wrong. Security of cyphers based on prime factorization depends on this operation being a very hard problem. A O(N) or O(N*ln N) (or even N^2 or N^p for smallish values of p) algorithm would make breaking those codes trivial for any practical key length. Remember that N is typically the size of the key, generally with an order of magnitude of a few thousands. We are not talking one-time pads here (where the key is at least as long as the data encoded, often longer since you want some padding to avoid leaking information).
I would advise anyone in doubt to go (back?) and (re-?) read Applied Cryptography from Bruce Schneier. Warning: it's not a page-turner !
As another poster stated, this in unlikely to happen.
High-performance graphic cards will require a x16 slot, and most motherboards will only provide one x16, multiple x1 and maybe a couple of x4.
Moreover the PCI-Express specs define power limits. All the Gfx vendors requested (and got) amazingly high power limits for graphic slots. Having two Gfx boards working at the limit would blow past the cooling abilities of most cases. While it will be possible for a PC manufacturer to provide multiple such slots, this will not happen in the value segment and may only be offered at a high cost premium (if at all).
What I am hoping for is for "secondary" cards working from a 4x slot, with limited performance and limited consumption. I could use a (or two) secondary display(s) while using flight simulators (e.g., for auxiliary panels or peripheral vision).
Note also that the PCI-SIG is close to making a decision on "second generation signaling rate". The debate is between 5Gb/s/lane (ie 2 times Gen I) or 6.25Gb/s/lane. A Gen-II 4x slot would provide enough bandwidth to feed a current high-end card.