The critical question is whether or not kids are really aware that what they are doing in the games is, or is not, actually like truly killing people.
It was "cute" when the two kids in Mars Attacks! used their 'obvious' skills at shoot-em-up arcade games to blow away aliens with their own ray guns; this is still merely a movie story, neatly separated from reality.
I suspect that we may be getting a confusing combination of:
Games where graphics are, at least in some ways, so "realistic" that they may be increasingly confused for the real world, and
Unusual, but well-publicized, cases of extreme violence that are so bizarre that they would normally be confused for fiction.
Concern comes in if this "breaks the abstraction barrier," and leaves kids having a hard time telling the difference between reality and fantasy.
then you're a vastly stronger man than anyone I know...
And I think that the quote actually is:
"Bureaucracies interpret communication as damage and route around it" -- Jamie Zawinski
:-)
But seriously, it's encouraging to hear that if dissent is sufficiently widespread that this "safety in numbers" does protect from things getting too bad.
That's certainly a fuller explanation of things than my knowledge can cover...
Probably not a relevant strategy...
on
New ATi 3D Chip
·
· Score: 2
Putting multiple processors onto one die is certainly an interesting idea; that doesn't directly address the "application-logic" versus "graphics-logic" issue, as the latter is evocative of different kinds of ALU manipulations.
But that word "address" is the critical thing... In order to stack many processors together, and make use of them, you need considerable memory management hardware so that those CPUs can actually address memory, and not trample on one another whilst doing so. Parallelism isn't trivial to harness...
The cases have come up have had some rather distressing results, and I agree that it is important to be aware of what is going on.
Unfortunately, to actually participate in significant ways runs people into the risk of arousing the ire of the Scientologists, and with the size of their army of private investigators and lawyers, this represents a significant risk, and one that not everyone will be willing to risk.
It might appear attractive to try to "twit" them; that is only acceptable if:
One feels extremely strongly about them, and is willing to risk suffering the consequences, or
The risks of consequences are low.
Of course, providing formally anonymous support ( e.g. - help with legal fees) to those that are "fighting fights and risking loss" might be a decent method...
I don't think so, but an illuminating question...
on
New ATi 3D Chip
·
· Score: 3
I seriously doubt that the Transmeta Crusoe will be a CPU that would be as useful for running "application" logic as it would be for running "graphix processor" logic.
The former ("application processor") tends to involve grabbing bits of memory from here and there, comparing them to other bits of memory, jumping, often adding something, and sometimes calling subroutines.
That may be a gross oversimplification, but there you go...
The latter ("graphics processor") will be doing a whole lot of operations involving XORs, filling regions with values, and even doing some tight loops oriented towards filling regions with "shading."
The graphics processor is rather more likely to find useful some operations that do "mass updates," which is rather like what a DSP does; that is quite different from the "lots-of-control-statements" that you'll get with a "conventional"/"application-oriented" CPU.
The patents that Transmeta has been granted somewhat confirm this point of view; the patents represent ways of optimizing the emulation of those "lots-of-control-statements."
There may be a real killer graphics chip right around the corner, although it is easy to argue that the last three years have involved the continuous release of successive generations of "more-and-even-more-killer" graphics processors.
I'm not sure that there is a "Transmeta" of the graphics world; it's probably not appropriate to talk about such until next February when you might conceivably be able to buy some Transmeta product...
Yes, it goes without saying that if there exist drivers for some of Windows 95, 98, NT 3.5, NT 4.0, 2000
It's far more fun to forget about that...:-)
The comparison to MMX is still reasonably fair; there has been much talk, but between the varying implementations from different vendors, the deployment of useful drivers is doubtless rather limited, with "accelerated" games coming mostly as demos that come with a particular graphics card...
As for karma, all you need do is to post things that will be perceived as interesting. If you maintain enough self-control to avoid flame-bait, and have some useful information, your karma will head up into the hundreds...
(No, there probably aren't many people with hundreds of karma points. My count is only in the "single" hundreds, not in multiple hundreds...)
This probably does imply something about it being extremely powerful (although there's probably a Kurt Vonnegut warning available)...
This may parallel (fatally, as is the case for automotive analogies) automobile mufflers; I find that the really powerful automobiles have extensive exhaust systems, whilst any car with a "wimpy" exhaust system is itself necessarily "wimpy."
A graphics card that requires inordinate amounts of power might, on the one hand, be making flashy use of electricity to make it seem cool, but might truly be providing a whopping lot of "rendering power."
Of course, the killer question is whether or not there will be XFree86 accelerator code that can actually harness this power... Otherwise, these monstrous, smoking-at-the-ears graphics boards may be paper dragons, parallelling the Intel MMX, where few if any programs actually made real use of the optimization...
The devfs code has been tracking the kernel for a goodly amount of time now; it is most certainly developed, considerably debugged, and perfection is certainly a matter in the eye of the beholder.
EGCS compatibility is somewhat different; it represents some examples of cases where Linux was not conforming to the official standards of how C is supposed to work. (Largely regarding treatment of pointer aliasing, I believe...) Linux has arguably been made buggy in doing things that C isn't supposed to support, but which GCC used to.
Conformance to standards isn't a "feature" in the way many kernel facilities are...
Consider that I didn't mention GGI as an example; it is an example of something that was initially rejected, and quite legitimately so, as the proposed implementation was not, three years ago, developed, debugged, and perfected. Interestingly, the recent framebuffer support is now the GGI support; they don't need to integrate big gobs of stuff as they have the crucial interface that they do need, with the benefit that it has made supporting some of the more obscure systems ( e.g. - Atari ST and such) easier.
This debate first came up in Issue #25, Article 2. This time it started innocently enough with a discussion of USB device number allocation. Pavel Machek pointed out that USB was finally starting to get useful, which meant it was time to allocate/dev entries for various USB devices. He allocated 32 entries for 16 devices, and Steffen Grunewald asked about other USB devices like monitors, speakers, etc.; and Dan Hollis replied, "The desperate need for devfs becomes all more clear." At this point there was no turning back. The debate raged for about a week and a half, generating over 600 posts. Linus, although back from vacation, posted nothing in any of the related threads; while Alan addressed his posts strictly to peripheral, technical details.
The thing that is particularly special about "streams" versus "blocks" is that with "streams," the "block" happens to be pathologically small.
The question is not simply of whether the "delay is acceptable;" it is of whether any delay is acceptable.
Consider the situation of running a Telnet session. You press a key, and expect the system to respond to you, updating the screen every time you press a key.
That is a case where there is a need for something rather like streaming; in effect, the communications stream needs to be able to respond to each key press, and transmit them immediately. Not only is your "two minute" delay unacceptable, I would (and sometimes do ) find a 0.5s delay to be unacceptable. If I'm running Emacs or vi across an encrypted Telnet session, I am absolutely NOT going to find it acceptable for the system to collect up two minutes worth of updates, and handle 'em all at once. (If I was running TECO, where updates are queued 'til I hit ESC, or a mainframe editor where updates are queued until I press [ENTER], that may be a different story...)
That being said, it is fairly usual for network-based transmissions to mandate block-oriented schemes, as the transmission medium is not a "stream," but rather a set of "packets" that map nicely onto "blocks."
RC4 and SEAL are notable stream ciphers; the usual distinction between a stream cipher and a block cipher is that block ciphers work with "blocks" (or "packets") of material, whereas stream ciphers work with far smaller "blocks," commonly a single word or byte. The pathological example of a stream cipher should encrypt bit-by-bit; on computers with word sizes of 32 bits, it would make considerable sense to treat a 32 bit word as the "atomic unit" being encrypted.
Whether the "atom" is a bit, byte, or word, the critical issue is that the unit of encryption is liable to be a whole lot smaller than the 56 bytes one might have in an Ethernet packet...
The common thread in public key schemes is that whether they're using discrete powers, discrete logarithms, or mapping points onto ellipsoids, they all involve the use of mathematics involving bignums. Such algorithms have the unfortunate property of being much, much slower than block-oriented algorithms such as the Feistel family that can make use of byte/block-oriented operators that are implemented vastly more efficiently on microprocessors that have instructions like ADD, MUL, XOR, AND, NOT, ROR, ROL,...
Add to the above the consideration that the bignum ciphers tend to be less secure than their "block-oriented" brethren, so that whilst (for instance) IDEA is considered pretty secure with 128 bits of key, RSA requires 1024 bits (or more) to provide similar secureness. This "bloating" of key sizes magnifies the differences in relative efficiency further, thus making it even less sensible to use RSA (or DH, or the "Lucas" variant, or...) as alternatives to the private key ciphers.
But on top of all that, which is a mouthful, you're not talking about block ciphers, but rather stream ciphers, which are a different class still, as they encrypt byte-by-byte, that doubtless magnify the inefficiencies of the public key encryption bignum math further.
It surely is like unto free software in that it promotes the free availability of literature.
It may not use the GPL, per se; it may not attempt to challenge copyright in the way that RMS seeks to challenge the notion of proprietary software.
But it certainly represents an analogue to free software.
Books are rather less ephermal than computer software, as the Gutenberg Project surely shows that there is literature a hundred years old that is still worth reading, whilst much of the computer software of ten years ago isn't worth using. (The "computer literature of UNIX and Lisp" representing occasional literate exceptions...)
There used to be somewhat wild claims about the value of the Gutenberg Project; as it has grown from nothingness into being a fairly significant library with diverse users, the values have become clearer.
The project has suffered from some texts being of somewhat questionable quality; their transcriptions of some religious works have been useful in bringing in both a touch of religious fervor, to more actively stiumulate verification, as well as in perhaps pulling in some of the "scribely" skills mostly associated with religious traditions.
I think they had some problems with some of the early OCR technology, finding accuracy to be a bit low. Time, independent OCR attempts on differently published editions of books, and learning curve can provide improving results...
The way that Project Gutenberg gets material is by people contributing the often rather substantial effort of typing in material, as well as working to verify its correctness.
That really is a quite considerable cost, in much the same way that the production of "free" software requires substantial effort.
It is somewhat unfortunate that there have been such peculiar positions as:
A friendly dissuasion from this yielded the first posting of a document in electronic text, and Project Gutenberg was born as Michael stated that he had "earned" the $100,000,000 because a copy of the Declaration of Independence would eventually be an electronic fixture in the computer libraries of 100,000,000 of the computer users of the future.
It did not add to the project's credibility when they on the one hand indicated that their funding was maxxing out at around $30K per year, whilst claiming that they were producing "billions" of dollars in value. (Note that the PostgreSQL HOWTO suffers from the same sort of thing...)
A claim of $30K on the one hand, and $Billions on the other, do not reconcile very well.
Not unlike the situation with the FSF, they could probably more readily use contributions of time rather than of money, although some of both doubtless prove valuable to some degree...
This is also true in Canada, and is likely true in many other jurisdictions.
It's quite a dilemna; if they include components that have licensing agreements that require some degree of consent on the part of the user, they require an "adult's" consent.
It is particularly a problem for software that requires something like unto the "dastardly" MSFT EULA; it is less of an issue with Free Software, but even there, there is some need to be able to enforce the terms of GPL, XFree86 License, and other such licenses, and that can certainly be problematic for the young'uns.
A more pointed question, that isn't directly relevant to this particular situation:
Can a minor consent to release code under the GPL when they may not be legally able to establish contracts?
The fact that we might like the answer to be yes does not necessarily make it so...
That certainly sounds like a good idea; one not-so-minor problem; MLL uses the Mozilla Public License, which is not compatible with GPLed code as documented in the MPL FAQ:
18.How can GPL code be incorporated into the Communicator code base?
Under our reading of the GPL, it will not be possible to incorporate code covered by the GPL into the Communicator source code base. It is also not possible to use GPLed code and NPLed code together in a Larger Work. This is different for LGPL code. It is possible to create a larger work using LGPLed code that can then be used in conjunction with NPLed code through an API..
There tends to be a "retrospective" issue roughly every ten years for magazines like Scientific American that supplies these sorts of predictions.
SCI AM admittedly tends to be a bit more serious than, say, Popular Science, which has been "predicting" hypersonic airliners fairly much continuously since the 1950s.
In order to support the huge stock value, RHAT needs to have some revenue stream. (That old passe concept of fundamental analysis rears its ugly head...)
Sales of Cygwin and such represent sales. Since the product is already developed, such sales may even come at virtually no cost.
There's obviously not too likely to be immense changes to GCC (note: it's not called EGCS anymore... ); it might be reasonably argued that RHAT is acting to counter VA Linux Systems, as VA has lately been involved with the IA-64 deployement of GCC.
As for eCos, I suspect that it's not something RHAT will care much about. I also suspect that it hadn't yet become a substantial revenue stream for Cygnus. That bodes somewhat ill for it getting much continued support, although that's no guarantee.
I'm actually rather more interested in hearing what RHAT policy is on Source Navigator and such; it would be a rather positive step if they are released under (L)GPL, and rather distressing if they are not...
Slashdot Mirror
It was "cute" when the two kids in Mars Attacks! used their 'obvious' skills at shoot-em-up arcade games to blow away aliens with their own ray guns; this is still merely a movie story, neatly separated from reality.
I suspect that we may be getting a confusing combination of:
- Games where graphics are, at least in some ways, so "realistic" that they may be increasingly confused for the real world, and
- Unusual, but well-publicized, cases of extreme violence that are so bizarre that they would normally be confused for fiction.
Concern comes in if this "breaks the abstraction barrier," and leaves kids having a hard time telling the difference between reality and fantasy.And I think that the quote actually is:
But seriously, it's encouraging to hear that if dissent is sufficiently widespread that this "safety in numbers" does protect from things getting too bad.
That's certainly a fuller explanation of things than my knowledge can cover...
But that word "address" is the critical thing... In order to stack many processors together, and make use of them, you need considerable memory management hardware so that those CPUs can actually address memory, and not trample on one another whilst doing so. Parallelism isn't trivial to harness...
Unfortunately, to actually participate in significant ways runs people into the risk of arousing the ire of the Scientologists, and with the size of their army of private investigators and lawyers, this represents a significant risk, and one that not everyone will be willing to risk.
It might appear attractive to try to "twit" them; that is only acceptable if:
Of course, providing formally anonymous support ( e.g. - help with legal fees) to those that are "fighting fights and risking loss" might be a decent method...
- The former ("application processor") tends to involve grabbing bits of memory from here and there, comparing them to other bits of memory, jumping, often adding something, and sometimes calling subroutines.
- The latter ("graphics processor") will be doing a whole lot of operations involving XORs, filling regions with values, and even doing some tight loops oriented towards filling regions with "shading."
The graphics processor is rather more likely to find useful some operations that do "mass updates," which is rather like what a DSP does; that is quite different from the "lots-of-control-statements" that you'll get with a "conventional"/"application-oriented" CPU.That may be a gross oversimplification, but there you go...
The patents that Transmeta has been granted somewhat confirm this point of view; the patents represent ways of optimizing the emulation of those "lots-of-control-statements."
There may be a real killer graphics chip right around the corner, although it is easy to argue that the last three years have involved the continuous release of successive generations of "more-and-even-more-killer" graphics processors.
I'm not sure that there is a "Transmeta" of the graphics world; it's probably not appropriate to talk about such until next February when you might conceivably be able to buy some Transmeta product...
It's far more fun to forget about that... :-)
(No, there probably aren't many people with hundreds of karma points. My count is only in the "single" hundreds, not in multiple hundreds...)
This may parallel (fatally, as is the case for automotive analogies) automobile mufflers; I find that the really powerful automobiles have extensive exhaust systems, whilst any car with a "wimpy" exhaust system is itself necessarily "wimpy."
A graphics card that requires inordinate amounts of power might, on the one hand, be making flashy use of electricity to make it seem cool, but might truly be providing a whopping lot of "rendering power."
Of course, the killer question is whether or not there will be XFree86 accelerator code that can actually harness this power... Otherwise, these monstrous, smoking-at-the-ears graphics boards may be paper dragons, parallelling the Intel MMX, where few if any programs actually made real use of the optimization...
EGCS compatibility is somewhat different; it represents some examples of cases where Linux was not conforming to the official standards of how C is supposed to work. (Largely regarding treatment of pointer aliasing, I believe...) Linux has arguably been made buggy in doing things that C isn't supposed to support, but which GCC used to.
Conformance to standards isn't a "feature" in the way many kernel facilities are...
Consider that I didn't mention GGI as an example; it is an example of something that was initially rejected, and quite legitimately so, as the proposed implementation was not, three years ago, developed, debugged, and perfected. Interestingly, the recent framebuffer support is now the GGI support; they don't need to integrate big gobs of stuff as they have the crucial interface that they do need, with the benefit that it has made supporting some of the more obscure systems ( e.g. - Atari ST and such) easier.
We still have the situation that GCC v2.95 Or Higher Still Out Of Favor For 2.2.3pre11
(That has changed recently, but Linus was refusing "EGCS compatibility" patches for rather a while there...)
Recently discussed.
The question is not simply of whether the "delay is acceptable;" it is of whether any delay is acceptable.
Consider the situation of running a Telnet session. You press a key, and expect the system to respond to you, updating the screen every time you press a key.
That is a case where there is a need for something rather like streaming; in effect, the communications stream needs to be able to respond to each key press, and transmit them immediately. Not only is your "two minute" delay unacceptable, I would (and sometimes do ) find a 0.5s delay to be unacceptable. If I'm running Emacs or vi across an encrypted Telnet session, I am absolutely NOT going to find it acceptable for the system to collect up two minutes worth of updates, and handle 'em all at once. (If I was running TECO, where updates are queued 'til I hit ESC, or a mainframe editor where updates are queued until I press [ENTER], that may be a different story...)
That being said, it is fairly usual for network-based transmissions to mandate block-oriented schemes, as the transmission medium is not a "stream," but rather a set of "packets" that map nicely onto "blocks."
Remember stream ciphers != block ciphers.
RC4 and SEAL are notable stream ciphers; the usual distinction between a stream cipher and a block cipher is that block ciphers work with "blocks" (or "packets") of material, whereas stream ciphers work with far smaller "blocks," commonly a single word or byte. The pathological example of a stream cipher should encrypt bit-by-bit; on computers with word sizes of 32 bits, it would make considerable sense to treat a 32 bit word as the "atomic unit" being encrypted.
Whether the "atom" is a bit, byte, or word, the critical issue is that the unit of encryption is liable to be a whole lot smaller than the 56 bytes one might have in an Ethernet packet...
Add to the above the consideration that the bignum ciphers tend to be less secure than their "block-oriented" brethren, so that whilst (for instance) IDEA is considered pretty secure with 128 bits of key, RSA requires 1024 bits (or more) to provide similar secureness. This "bloating" of key sizes magnifies the differences in relative efficiency further, thus making it even less sensible to use RSA (or DH, or the "Lucas" variant, or ...) as alternatives to the private key ciphers.
But on top of all that, which is a mouthful, you're not talking about block ciphers, but rather stream ciphers, which are a different class still, as they encrypt byte-by-byte, that doubtless magnify the inefficiencies of the public key encryption bignum math further.
It may not use the GPL, per se; it may not attempt to challenge copyright in the way that RMS seeks to challenge the notion of proprietary software.
But it certainly represents an analogue to free software.
Books are rather less ephermal than computer software, as the Gutenberg Project surely shows that there is literature a hundred years old that is still worth reading, whilst much of the computer software of ten years ago isn't worth using. (The "computer literature of UNIX and Lisp" representing occasional literate exceptions...)
There used to be somewhat wild claims about the value of the Gutenberg Project; as it has grown from nothingness into being a fairly significant library with diverse users, the values have become clearer.
The project has suffered from some texts being of somewhat questionable quality; their transcriptions of some religious works have been useful in bringing in both a touch of religious fervor, to more actively stiumulate verification, as well as in perhaps pulling in some of the "scribely" skills mostly associated with religious traditions.
I think they had some problems with some of the early OCR technology, finding accuracy to be a bit low. Time, independent OCR attempts on differently published editions of books, and learning curve can provide improving results...
That really is a quite considerable cost, in much the same way that the production of "free" software requires substantial effort.
It is somewhat unfortunate that there have been such peculiar positions as:
It did not add to the project's credibility when they on the one hand indicated that their funding was maxxing out at around $30K per year, whilst claiming that they were producing "billions" of dollars in value. (Note that the PostgreSQL HOWTO suffers from the same sort of thing...)A claim of $30K on the one hand, and $Billions on the other, do not reconcile very well.
Not unlike the situation with the FSF, they could probably more readily use contributions of time rather than of money, although some of both doubtless prove valuable to some degree...
It's quite a dilemna; if they include components that have licensing agreements that require some degree of consent on the part of the user, they require an "adult's" consent.
It is particularly a problem for software that requires something like unto the "dastardly" MSFT EULA; it is less of an issue with Free Software, but even there, there is some need to be able to enforce the terms of GPL, XFree86 License, and other such licenses, and that can certainly be problematic for the young'uns.
A more pointed question, that isn't directly relevant to this particular situation:
The fact that we might like the answer to be yes does not necessarily make it so...
- System for dynamic sharing of local and remote displays by maintaining a list of best-match resources - HP
- Method and system for on demand downloading of module to enable remote control of an application program over a network - Tridia Corporation, Atlanta, GA
The latter might be the patent in question; GraphOn doesn't seem to be inclined to indicat what the patent is...See the Mnemonic Web Site; this is, admittedly, pretty vaporwarish...
This is doubtless not proof against the serious cryptographers of the NSA, but it would be most entertaining to have a PalmPilot utility for it...
SCI AM admittedly tends to be a bit more serious than, say, Popular Science, which has been "predicting" hypersonic airliners fairly much continuously since the 1950s.
I think that they called them feelies in Brave New World...
(Feel free to modify words in that sentence so as to provide bad jokes. There are ample options available...)
And boy, will that ever give us more bandwidth to support the increasing numbers of cellular phones!
(Um, oops... How do you get the fibre cables out to the phones?)
Sales of Cygwin and such represent sales. Since the product is already developed, such sales may even come at virtually no cost.
There's obviously not too likely to be immense changes to GCC (note: it's not called EGCS anymore... ); it might be reasonably argued that RHAT is acting to counter VA Linux Systems, as VA has lately been involved with the IA-64 deployement of GCC.
As for eCos, I suspect that it's not something RHAT will care much about. I also suspect that it hadn't yet become a substantial revenue stream for Cygnus. That bodes somewhat ill for it getting much continued support, although that's no guarantee.
I'm actually rather more interested in hearing what RHAT policy is on Source Navigator and such; it would be a rather positive step if they are released under (L)GPL, and rather distressing if they are not...