> I think it's safe to say that the NSA, with it's largest budget out of any intelligence agency in the U.S, has probably cracked the 100 TF mark ? It's a shame we will never no what kind of muscle they can flex.
This kind of conspiracy theory seems very common; but it never sounded very convincing to me. This is simply a major logistic problem: While a thing like Manhattan Project was possible by being nearly self-sustaining, I seriously doubt NSA can secretly keep a state-of-the-art processor fab running. Nor can they secretly get such large supplies from any commercial company: How would IBM for example prevent all it's employees from leaking the information, if they forked a few 100000 Power processors for NSA?...
> It's not as if the analog spectrum is close to saturated by current VHF/UHF broadcasts.
Actually, TV broadcasting is the single application eating up by far the biggest part of the available spectrum. Even with only a few channels available.
> but rather the much higher earnings potential for cable, with it's lower cost of service
This pretty much contradicts about anything I have heard about that matter so far.
The general opinion is that central, wireless solutions are considerably *cheaper* than serving each and every single customer individually with wires. Many see wireless solutions as the only realistic way to provide people in thinly settled areas with fast internet connection, for example.
I don't think it's a coincidence that you get broadcast for free, while cable needs to be funded by considerable monthly fees...
The advantage of wires is higher bandwith (because they can use the whole frequency spectrum, and also the transport media are generally more optimal); but certainly not price.
There seems to be some misunderstanding here. It's not like the people here generally don't like the switch to digital broadcast, and only do not oppose it because they are "good Germans". While there is some inertia about anything new, most people actually consider the move to be a *very good* thing. At least that's my impression.
Americans may have a stronger tendency to oppose things they do not like; but I doubt they will have a fundamentally different opinion about the merits of digital broadcasting.
The point ist that *Ubutu didn't make (most of) this changes*; rather, they have adopted them from Debian.
This might not matter much technically; but psychologically, it is a completely different thing. The original sentence sounds like Ubuntu was a big innovator, and Debian just plagiated from them.
What do you base that claim on? Actually, it's not only alive, but also makes progress, and (contrary to most people's believe) is quite complete right now.
> but there's still an opportunity for a brilliant someone to come along and make a good microkernel OS, with all the security, stabillity, and maintainability that comes along with such an architecture.
And why would that "brilliant someone" start from scratch, instead of working on the Hurd? Just because a project suffered from mismanagement in the beginning, it doesn't mean all the great work achieved so far is worthless and needs to be redone.
Actually, the Hurd presently has, and always has had, a number of brilliant developers; it only lacks a brilliant manager:-(
> Just off the top of my head, Linux has: > - Newbie-friendly installers with lots of really nice up to date free software (Ubuntu, FC4, etc.) > - Lots of custom distributions for specialized purposes, live CDs, etc.
How are those related to the Kernel?
Note that Debian has (mostly) working variants with FreeBSD and NetBSD kernels instead of Linux.
Of course, cable is much more desirable than *analog* TV broadcast. My point was that, with broadcast switching to digital and cable still being (mostly) analog, the situation changes quite a lot: Digital broadcast offers about the same number of stations as analog cable (something around 30), and offers a better quality. Many people ask: Why still pay the fees for cable, when they can get something comparable or even better for free?
(Of course, with cable getting more digital, it will get an advantage again... But the incentive won't be nearly as big as it used to be. Which in turn makes the cable companies reluctant to do the necessary investments:-) )
Sorry for disspelling your very original fantasies... but nothing of that kind seems to be happening here in Berlin, where they did shut down analog TV broadcasts some two years ago.
The frequencies are reused for the new digital broadcasting -- there are now about five times as much stations available, and posing a considerable threat to cable television: As cable is still analog, you get the same number of channels in a better quality for free on air... Only thing you need to pay is buying the receiver (< $100) once.
Talking about Debian making "the same improvements" is factually wrong. It sounds as if Ubuntu first made some improvements over Debian, and then Debian followed suit. This is not the case. Ubuntu 5-4 is a branch/fork of Debian from a few months ago; there haven't been any fundamental changes in Debian between that and the release, only bugfixes and minor improvements. So (almost) all improvements over Woody that Sarge and Ubuntu have in common, Ubuntu has taken *from* Debian.
That is for the things they have *in common* (which is a lot). Only the differences, i.e. the improvements that Ubuntu has over Sarge, are genuine.
Claiming Sarge is similar to Ubuntu is really turning things upside down. Just because Ubuntu *released* some improvements earlier, it doesn't change the fact that they (mostly) originate from Debian.
As I said, I'm not opposed to some changes, including some conditions for inclusion in the mainstream distribution and/or a different system for managing ports, that would put more responsibility on the porters. However, the *original* proposal about dropping the architectures, was suggesting neither. It just wants to impose a few completely arbitrary conditions, with the express purpose of throwing out almost all architectures. I can only hope the proposal will not get implemented in the original form.
> when you are installing an OS over network connection into a annex server attached to the machine via a serial port, a text install is not a matter of taste.
Well, I mean it's a matter of taste if people (like me) are preferring a textual interface *in general*, while others would like to see a graphical one *where possible*. My point was that not everyone considers graphical installers the One True Thing (TM) to go for.
> Debian is meant to run on everything, whether that thing comes with a 256Meg Video card or not.
This "run on everything" is exactly the aspect they are considering to cut back on:-(
> Debian developers do not accept any role. They code what they code. Its their code, how dare you criticise it.
While the exact words are mine, and maybe I have been developing that notion myself for a while, it were actually Debian developers who made the observation I am talking about.
The real value coming from Debian today is the technology platfrom, not the end user distribution. That's a fact, and I hope the developers can accept this and sustain that value, instead of damaging it in vain attempts at (direct) market share.
Some at the Debian project make observations how Ubuntu managed to deliver a Debian variant very appealing to end users. But instead of enjoing Debian finally getting a really viable offering for typical end users this way, many see Ubuntu as a *competitor*, and try pushing absurd plans attempting to "regain" some market share from Ubuntu, at the expense of the real strengths of the Debian project.
It's really a pity to see some Debian folks trying to "beat" Ubuntu, instead of celebrating it as their own victory:-(
> If there is a real problem then issue a bug report, and if you really want to get things going in the right direct, submitt a patch.
A bug report or patch doesn't help, if the issue at hand are plans to drop most architectures from Debian.
If you believe it all comes down to bug reports and patches, you seem not to be aware of the *enormous* amount of politics, the endless discussions involved in every step the Debian project takes. I just hope the discussions will not lead to a decision that would destroy Debian's value. And by commenting on it, I try to contribute my own little bit to make Debian folks aware how people are perceiving Debian today, and what might be at stake.
I was specifically referring to the plans to throw out most architectures.
(Actually, I wouldn't generally oppose a change in the method how architectures are managed; but just throwing some out in the vain hope that this will make Debian more competitive -- like some seem to intend -- would be silly at best, and actually very harmful.)
> I think what most people are suggesting is that Ubuntu is more capable of managing Debian than Debian is.
That's totally beside the point. You do not seem to understand the relation between the two. What Ubuntu is more capable of is managing are *quick, extremely stripped down releases of Debian*. Nothing more. All the grunt work is done by the Debian developers. The reason Ubuntu was able to create a system competitive with established big distributions like RedHat in such a short time, is not that their few employees are geniuses, but that they take all the enormously valuabe work from Debian and just need to add a few little twists to them. It really only shows that Debian isn't lacking nearly as much as it may seem at first look.
> Why is Debian so behind the ball on this? Sure, its target market might not be desktop users, but it will never gain *any* marketshare in that area with that horrible installer and the GUI that looks like shit.
Actually, it would do Debian better if they stopped *trying* to get market share like this. Debian is becoming more and more a technology platform, with actual end user distributions provided by third parties like Ubuntu. Sadly, most Debian developers do not want to accept that new role, and instead are considering some changes that would cut the real strengths of Debian. (Without fulfilling the hope that it becomes a viable end user system after all.)
As for looks, I prefer the old-fashioned text based Installer over all the graphical ones. It's a matter of taste, nothing else.
I'm not sure I can explain it, without a thorough introduction on processor design...
Both RISC and CISC feed the processor with abstract instructions, telling it to "load from memory at address [op1] to register op2", "add op1 and op2, storing result in op3", "jump to address [op1]" etc.
Internally, the processor needs to translate such abstract instructions into control words for the actual units. An addition for example becomes: "register set: put register [op1] on read port 1, register [op2] on read port 2, and store to register [op3] from write port; interger ALU: do an addition (read port 1 + read port 2 + carry => write port, flags); instruction counter: increment; other units: idle". A realative jump will translate to: "register set: put register [op1] on read port 1, put register [op2] on read port 2, ignore write port; integer ALU: perform addition ignoring flags; instruction counter: load from write port; others: idle". A load from memory will be: "register set: put register [op1] on read port 1, omit read port 2, store from write port to register [op2]; load/store unit: load from address on read port 1, storing to write port; instruction counter: increment; others: idle". And so on. I guess you realize the internal control word being quite different from the external instruction.
The idea of RISC is that the translation from the abstract instruction to the internal control word gets easiear with the regular instruction word layout, and (more importantly) an abstract instruction can always be transformed to a single internal control word (executed in one cycle) as we are avoiding complex instructions.
Note that in a superscalar architecture, it is actually possible to put *several* instructions into a single internal control word, so they are exectued in parallel, as long as they don't use the same units and/or registers. If it is also Out-Of-Order, the instructions to execute in parallel are chosen dynamically (on execution time).
In a VLIW architecture on the other hand, the (very long) instruction word already contains precise instructions for all internal units, telling each one what to do in the current cycle. No transformation is necessary on execution time.
> Full implementation of the production version will be even slicker. Unlike the Chinese model, where citizens know they've've crossed the line (because the request for that "interesting" URL was blocked, or because the email to that "interesting" person never got delivered), the live system will simply log the data for future reference and cross-archiving - it'll be done automatically, avoiding the problem that crashed the alpha site under heavy load.
> Give a subversive enough rope, and he'll hang himself. And unlike the beta site, the production version will enable society to track its unreliable elements until they've exposed all of their secrets and, by extension, all of their friends' secrets.
> Absolute social control, with minimal loss of economic productivity, and (unlike China), practically no diminishment of civilian morale, because everyone thinks they're still free-as-in-speech.
There is a very basic and simple flaw in your reasoning: If people do not know about a borderline they better not cross, almost *everyone* will follow "subversive" ideas -- after all, that's what comes naturally.
The major problem of totalitarian systems pretending to be "social" is finding a route where on the one hand people have enough fear not to follow "subversive" ideas openly, but at the same time oppression is not too open, so most people can still fool themselfs into believing things are mostly good.
This was the case in GDR (I know it), this is the case in China, and it will be the case in *any* totalitarion system that is not *openly* oppressive.
> So what's in it for them? How do they feel about what they do? Anyone have a link to any information about them?
That's actually the same for the management of a typical greedy coorparation for example.
For most people, their work easily becomes an end in itself. Once they are working towards some goal, social implications do not matter. "Good" is anything that helps the goal, and "bad" is anything that works against it.
> For that matter, the "original" Pentium processor (not product line) wasn't even x86 compatible!
??? Sure the Pentium was x86 compatible; it was actually believed to be called 80586 for a long time, until the new branding was announced fairly shortly before the release...
> I think you're confused with what I was saying about MMX
I believe I understood your original meaning. (Or least this second explanation hasn't given my any new insight...)
My point is that, regardless of the limitations of MMX, SSE isn't really obsoleting MMX, but adding another extension besides it; they both can and should be used when appropriate, even in parallel.
> I think to seriously be adopted, though, it needs to be handled automatically by the compiler (like gcc 4.1 plans).
The Intel compilers do this kind of auto-vectorization for a couple of years now.
I completely agree that those SIMD units won't get wider usage without such technology; I was assuming it in my statement. gcc following Intel's lead now is really amazing:-)
> VLIW really is like another layer of abstraction designed to simplify out-of-order execution from the processor point-of-view.
VLIW is actually quite the the opposite: It's much *nearer* to how the processor operates internally. The instruction word precisely describes what each unit is supposed to do, so the processor doesn't need decoding, dynamic issuing etc.
It allows for better peak unit utilization, at the expense of less flexibility (no reordering) for unpredictable events, considerably bigger code (resulting in worse performance when code doesn't fit in L1 cache), and absolutely no flexibility for new ISA-compatible models.
The result is that VLIW is really good only for typical DSP applications.
> Intel basically made a VLIW for CISC called EPIC (Explicitly Parallel Instruction Computing).
EPIC is an attempt to alleviate the mentioned disadvantages of VLIW, while trying to keep as much as possible of its advantages. This is achieved mostly by introducing a few additional mechanisms (predication bits, instruction bundles, rotating registers etc.), intended to make up for the missing layer of indirection present in other architectures.
It is completely unrelated to CISC. I wonder how you got that idea.
The article you linked is quite interesting BTW, throwing in lots of information bits, but also extremely confusing...
As a GPL hardliner, I decidedly put it in the non-evil camp as well. But only in this context.
Generally, such exceptions for otherwise GPL'd software are not uncommon. They are always a compromise: The copyleft is somewhat weakened to be able to do something important that wouldn't be possible otherwise. (In this case, using the not yet free components.) By restricting the exception to the fixed set of interfaces, abuse can be prevented quite well however.
By leaving the option to change the list of allowed interfaces, they can reduce it by and by, as they replace the non-free components with free ones. Once they are down to none, they will remove the exception alltogether.
This way, they have the possibility to release the core under GPL already, while not fully done with freeing the whole application yet.
The important part is that you can use a perfectly free program, as long as you stick to the core. If you want to take a compromise and use one of the non-free components however, the license doesn't prevent that.
Of course, such a license could be abused theoretically, by putting all useful functionality into the proprietary modules, thus tricking all users into using the non-free parts. This would effectively make the application non-free. That's the risk with every license that doesn't consequently enforce copyleft.
Summing up: With a loosened copyleft, the license is still perfectly free, just like BSD or other lincenses without copyleft can be perfectly free. And just like BSD, it could be abused. (Though the potential is smaller due to the limited exception.)
Lots of comments are suggesting that IBM doesn't really care, as Apple is a small customer anyways etc. The more I think about it, the more I believe it will actually hurt IBM quite badly.
While the number of Apple processors might not have been considerable, the PPC Macs were an extremely important enabler: All those geeks getting Apple hardware and porting GNU/Linux or whatever favourite free software they have, made PPC the best supported plattform besides x86. For most, Apple was an affordable entry into the PPC world.
Now this is gone. Neither the various game consoles nor IBM's servers will draw even remotely that much attention to PowerPC.
Until now, I believed PowerPC to be the only one of the "big" architectures to prevail besides x86/x64 and ia64, in the mid-term future. (Embedded is a different story.) Now I doubt it quite a lot.
I won't go into how absurd your guesses are; but your claims are even worse. AMD pushed Linux? what kind of crap is that? AMD even supported MS in the antitrust trail; actually, I don't remember them ever doing *anything* for free software. (Even Intel does more, though not really much...)
> So not only has Apple dumped IBM, they also appear to be planning to dump gcc.
I very much doubt it.
Not only is gcc the only ObjectiveC compiler I know of. It's actually *their own developement*! (Remember: NeXT -- the creator of most of MacOS X bought out by Apple -- not only invented ObjectiveC, but also implemented it in gcc.)
Just because you get plug-in Intel compilers (the GNU/Linux variant of the Intel compilers is almost fully gcc compatible, and probably so will be the Apple variant) to boost your C/C++/Fortran apps, for those who really want that last bit of performance, doesn't mean Apple is abdannoning gcc.
> Noone with a choice would ever use GCC for a _release_ version of anything. It's just too slow. Intel cmopiler kicks it ass in every respect except price.
I really wonder why people get so worked up on a performance difference that is way under the perception level for all but a very few extreme cases...
Sure, it would be nice to see gcc able to squeeze out that extra few percent of performance; but really, if it doesn't, who cares?
Slashdot Mirror
> I think it's safe to say that the NSA, with it's largest budget out of any intelligence agency in the U.S, has probably cracked the 100 TF mark ? It's a shame we will never no what kind of muscle they can flex.
This kind of conspiracy theory seems very common; but it never sounded very convincing to me. This is simply a major logistic problem: While a thing like Manhattan Project was possible by being nearly self-sustaining, I seriously doubt NSA can secretly keep a state-of-the-art processor fab running. Nor can they secretly get such large supplies from any commercial company: How would IBM for example prevent all it's employees from leaking the information, if they forked a few 100000 Power processors for NSA?...
> It's not as if the analog spectrum is close to saturated by current VHF/UHF broadcasts.
Actually, TV broadcasting is the single application eating up by far the biggest part of the available spectrum. Even with only a few channels available.
> but rather the much higher earnings potential for cable, with it's lower cost of service
This pretty much contradicts about anything I have heard about that matter so far.
The general opinion is that central, wireless solutions are considerably *cheaper* than serving each and every single customer individually with wires. Many see wireless solutions as the only realistic way to provide people in thinly settled areas with fast internet connection, for example.
I don't think it's a coincidence that you get broadcast for free, while cable needs to be funded by considerable monthly fees...
The advantage of wires is higher bandwith (because they can use the whole frequency spectrum, and also the transport media are generally more optimal); but certainly not price.
There seems to be some misunderstanding here. It's not like the people here generally don't like the switch to digital broadcast, and only do not oppose it because they are "good Germans". While there is some inertia about anything new, most people actually consider the move to be a *very good* thing. At least that's my impression.
Americans may have a stronger tendency to oppose things they do not like; but I doubt they will have a fundamentally different opinion about the merits of digital broadcasting.
The point ist that *Ubutu didn't make (most of) this changes*; rather, they have adopted them from Debian.
This might not matter much technically; but psychologically, it is a completely different thing. The original sentence sounds like Ubuntu was a big innovator, and Debian just plagiated from them.
> The HURD is essentially dead,
:-(
What do you base that claim on? Actually, it's not only alive, but also makes progress, and (contrary to most people's believe) is quite complete right now.
> but there's still an opportunity for a brilliant someone to come along and make a good microkernel OS, with all the security, stabillity, and maintainability that comes along with such an architecture.
And why would that "brilliant someone" start from scratch, instead of working on the Hurd? Just because a project suffered from mismanagement in the beginning, it doesn't mean all the great work achieved so far is worthless and needs to be redone.
Actually, the Hurd presently has, and always has had, a number of brilliant developers; it only lacks a brilliant manager
> Just off the top of my head, Linux has:
> - Newbie-friendly installers with lots of really nice up to date free software (Ubuntu, FC4, etc.)
> - Lots of custom distributions for specialized purposes, live CDs, etc.
How are those related to the Kernel?
Note that Debian has (mostly) working variants with FreeBSD and NetBSD kernels instead of Linux.
Seems my comment was confusing...
:-) )
Of course, cable is much more desirable than *analog* TV broadcast. My point was that, with broadcast switching to digital and cable still being (mostly) analog, the situation changes quite a lot: Digital broadcast offers about the same number of stations as analog cable (something around 30), and offers a better quality. Many people ask: Why still pay the fees for cable, when they can get something comparable or even better for free?
(Of course, with cable getting more digital, it will get an advantage again... But the incentive won't be nearly as big as it used to be. Which in turn makes the cable companies reluctant to do the necessary investments
Sorry for disspelling your very original fantasies... but nothing of that kind seems to be happening here in Berlin, where they did shut down analog TV broadcasts some two years ago.
The frequencies are reused for the new digital broadcasting -- there are now about five times as much stations available, and posing a considerable threat to cable television: As cable is still analog, you get the same number of channels in a better quality for free on air... Only thing you need to pay is buying the receiver (< $100) once.
Talking about Debian making "the same improvements" is factually wrong. It sounds as if Ubuntu first made some improvements over Debian, and then Debian followed suit. This is not the case. Ubuntu 5-4 is a branch/fork of Debian from a few months ago; there haven't been any fundamental changes in Debian between that and the release, only bugfixes and minor improvements. So (almost) all improvements over Woody that Sarge and Ubuntu have in common, Ubuntu has taken *from* Debian.
That is for the things they have *in common* (which is a lot). Only the differences, i.e. the improvements that Ubuntu has over Sarge, are genuine.
Claiming Sarge is similar to Ubuntu is really turning things upside down. Just because Ubuntu *released* some improvements earlier, it doesn't change the fact that they (mostly) originate from Debian.
As I said, I'm not opposed to some changes, including some conditions for inclusion in the mainstream distribution and/or a different system for managing ports, that would put more responsibility on the porters. However, the *original* proposal about dropping the architectures, was suggesting neither. It just wants to impose a few completely arbitrary conditions, with the express purpose of throwing out almost all architectures. I can only hope the proposal will not get implemented in the original form.
> when you are installing an OS over network connection into a annex server attached to the machine via a serial port, a text install is not a matter of taste.
:-(
:-(
Well, I mean it's a matter of taste if people (like me) are preferring a textual interface *in general*, while others would like to see a graphical one *where possible*. My point was that not everyone considers graphical installers the One True Thing (TM) to go for.
> Debian is meant to run on everything, whether that thing comes with a 256Meg Video card or not.
This "run on everything" is exactly the aspect they are considering to cut back on
> Debian developers do not accept any role. They code what they code. Its their code, how dare you criticise it.
While the exact words are mine, and maybe I have been developing that notion myself for a while, it were actually Debian developers who made the observation I am talking about.
The real value coming from Debian today is the technology platfrom, not the end user distribution. That's a fact, and I hope the developers can accept this and sustain that value, instead of damaging it in vain attempts at (direct) market share.
Some at the Debian project make observations how Ubuntu managed to deliver a Debian variant very appealing to end users. But instead of enjoing Debian finally getting a really viable offering for typical end users this way, many see Ubuntu as a *competitor*, and try pushing absurd plans attempting to "regain" some market share from Ubuntu, at the expense of the real strengths of the Debian project.
It's really a pity to see some Debian folks trying to "beat" Ubuntu, instead of celebrating it as their own victory
> If there is a real problem then issue a bug report, and if you really want to get things going in the right direct, submitt a patch.
A bug report or patch doesn't help, if the issue at hand are plans to drop most architectures from Debian.
If you believe it all comes down to bug reports and patches, you seem not to be aware of the *enormous* amount of politics, the endless discussions involved in every step the Debian project takes. I just hope the discussions will not lead to a decision that would destroy Debian's value. And by commenting on it, I try to contribute my own little bit to make Debian folks aware how people are perceiving Debian today, and what might be at stake.
I was specifically referring to the plans to throw out most architectures.
(Actually, I wouldn't generally oppose a change in the method how architectures are managed; but just throwing some out in the vain hope that this will make Debian more competitive -- like some seem to intend -- would be silly at best, and actually very harmful.)
"Only occasionally does this new release differ from Ubuntu."
Duh. Wouldn't it rather be appropriate to put it the other way round?...
> I think what most people are suggesting is that Ubuntu is more capable of managing Debian than Debian is.
That's totally beside the point. You do not seem to understand the relation between the two. What Ubuntu is more capable of is managing are *quick, extremely stripped down releases of Debian*. Nothing more. All the grunt work is done by the Debian developers. The reason Ubuntu was able to create a system competitive with established big distributions like RedHat in such a short time, is not that their few employees are geniuses, but that they take all the enormously valuabe work from Debian and just need to add a few little twists to them. It really only shows that Debian isn't lacking nearly as much as it may seem at first look.
> Why is Debian so behind the ball on this? Sure, its target market might not be desktop users, but it will never gain *any* marketshare in that area with that horrible installer and the GUI that looks like shit.
Actually, it would do Debian better if they stopped *trying* to get market share like this. Debian is becoming more and more a technology platform, with actual end user distributions provided by third parties like Ubuntu. Sadly, most Debian developers do not want to accept that new role, and instead are considering some changes that would cut the real strengths of Debian. (Without fulfilling the hope that it becomes a viable end user system after all.)
As for looks, I prefer the old-fashioned text based Installer over all the graphical ones. It's a matter of taste, nothing else.
I'm not sure I can explain it, without a thorough introduction on processor design...
Both RISC and CISC feed the processor with abstract instructions, telling it to "load from memory at address [op1] to register op2", "add op1 and op2, storing result in op3", "jump to address [op1]" etc.
Internally, the processor needs to translate such abstract instructions into control words for the actual units. An addition for example becomes: "register set: put register [op1] on read port 1, register [op2] on read port 2, and store to register [op3] from write port; interger ALU: do an addition (read port 1 + read port 2 + carry => write port, flags); instruction counter: increment; other units: idle". A realative jump will translate to: "register set: put register [op1] on read port 1, put register [op2] on read port 2, ignore write port; integer ALU: perform addition ignoring flags; instruction counter: load from write port; others: idle". A load from memory will be: "register set: put register [op1] on read port 1, omit read port 2, store from write port to register [op2]; load/store unit: load from address on read port 1, storing to write port; instruction counter: increment; others: idle". And so on. I guess you realize the internal control word being quite different from the external instruction.
The idea of RISC is that the translation from the abstract instruction to the internal control word gets easiear with the regular instruction word layout, and (more importantly) an abstract instruction can always be transformed to a single internal control word (executed in one cycle) as we are avoiding complex instructions.
Note that in a superscalar architecture, it is actually possible to put *several* instructions into a single internal control word, so they are exectued in parallel, as long as they don't use the same units and/or registers. If it is also Out-Of-Order, the instructions to execute in parallel are chosen dynamically (on execution time).
In a VLIW architecture on the other hand, the (very long) instruction word already contains precise instructions for all internal units, telling each one what to do in the current cycle. No transformation is necessary on execution time.
> Full implementation of the production version will be even slicker. Unlike the Chinese model, where citizens know they've've crossed the line (because the request for that "interesting" URL was blocked, or because the email to that "interesting" person never got delivered), the live system will simply log the data for future reference and cross-archiving - it'll be done automatically, avoiding the problem that crashed the alpha site under heavy load.
> Give a subversive enough rope, and he'll hang himself. And unlike the beta site, the production version will enable society to track its unreliable elements until they've exposed all of their secrets and, by extension, all of their friends' secrets.
> Absolute social control, with minimal loss of economic productivity, and (unlike China), practically no diminishment of civilian morale, because everyone thinks they're still free-as-in-speech.
There is a very basic and simple flaw in your reasoning: If people do not know about a borderline they better not cross, almost *everyone* will follow "subversive" ideas -- after all, that's what comes naturally.
The major problem of totalitarian systems pretending to be "social" is finding a route where on the one hand people have enough fear not to follow "subversive" ideas openly, but at the same time oppression is not too open, so most people can still fool themselfs into believing things are mostly good.
This was the case in GDR (I know it), this is the case in China, and it will be the case in *any* totalitarion system that is not *openly* oppressive.
> So what's in it for them? How do they feel about what they do? Anyone have a link to any information about them?
That's actually the same for the management of a typical greedy coorparation for example.
For most people, their work easily becomes an end in itself. Once they are working towards some goal, social implications do not matter. "Good" is anything that helps the goal, and "bad" is anything that works against it.
> For that matter, the "original" Pentium processor (not product line) wasn't even x86 compatible!
:-)
??? Sure the Pentium was x86 compatible; it was actually believed to be called 80586 for a long time, until the new branding was announced fairly shortly before the release...
> I think you're confused with what I was saying about MMX
I believe I understood your original meaning. (Or least this second explanation hasn't given my any new insight...)
My point is that, regardless of the limitations of MMX, SSE isn't really obsoleting MMX, but adding another extension besides it; they both can and should be used when appropriate, even in parallel.
> I think to seriously be adopted, though, it needs to be handled automatically by the compiler (like gcc 4.1 plans).
The Intel compilers do this kind of auto-vectorization for a couple of years now.
I completely agree that those SIMD units won't get wider usage without such technology; I was assuming it in my statement. gcc following Intel's lead now is really amazing
> VLIW really is like another layer of abstraction designed to simplify out-of-order execution from the processor point-of-view.
VLIW is actually quite the the opposite: It's much *nearer* to how the processor operates internally. The instruction word precisely describes what each unit is supposed to do, so the processor doesn't need decoding, dynamic issuing etc.
It allows for better peak unit utilization, at the expense of less flexibility (no reordering) for unpredictable events, considerably bigger code (resulting in worse performance when code doesn't fit in L1 cache), and absolutely no flexibility for new ISA-compatible models.
The result is that VLIW is really good only for typical DSP applications.
> Intel basically made a VLIW for CISC called EPIC (Explicitly Parallel Instruction Computing).
EPIC is an attempt to alleviate the mentioned disadvantages of VLIW, while trying to keep as much as possible of its advantages. This is achieved mostly by introducing a few additional mechanisms (predication bits, instruction bundles, rotating registers etc.), intended to make up for the missing layer of indirection present in other architectures.
It is completely unrelated to CISC. I wonder how you got that idea.
The article you linked is quite interesting BTW, throwing in lots of information bits, but also extremely confusing...
As a GPL hardliner, I decidedly put it in the non-evil camp as well. But only in this context.
Generally, such exceptions for otherwise GPL'd software are not uncommon. They are always a compromise: The copyleft is somewhat weakened to be able to do something important that wouldn't be possible otherwise. (In this case, using the not yet free components.) By restricting the exception to the fixed set of interfaces, abuse can be prevented quite well however.
By leaving the option to change the list of allowed interfaces, they can reduce it by and by, as they replace the non-free components with free ones. Once they are down to none, they will remove the exception alltogether.
This way, they have the possibility to release the core under GPL already, while not fully done with freeing the whole application yet.
The important part is that you can use a perfectly free program, as long as you stick to the core. If you want to take a compromise and use one of the non-free components however, the license doesn't prevent that.
Of course, such a license could be abused theoretically, by putting all useful functionality into the proprietary modules, thus tricking all users into using the non-free parts. This would effectively make the application non-free. That's the risk with every license that doesn't consequently enforce copyleft.
Summing up: With a loosened copyleft, the license is still perfectly free, just like BSD or other lincenses without copyleft can be perfectly free. And just like BSD, it could be abused. (Though the potential is smaller due to the limited exception.)
Lots of comments are suggesting that IBM doesn't really care, as Apple is a small customer anyways etc. The more I think about it, the more I believe it will actually hurt IBM quite badly.
While the number of Apple processors might not have been considerable, the PPC Macs were an extremely important enabler: All those geeks getting Apple hardware and porting GNU/Linux or whatever favourite free software they have, made PPC the best supported plattform besides x86. For most, Apple was an affordable entry into the PPC world.
Now this is gone. Neither the various game consoles nor IBM's servers will draw even remotely that much attention to PowerPC.
Until now, I believed PowerPC to be the only one of the "big" architectures to prevail besides x86/x64 and ia64, in the mid-term future. (Embedded is a different story.) Now I doubt it quite a lot.
I won't go into how absurd your guesses are; but your claims are even worse. AMD pushed Linux? what kind of crap is that? AMD even supported MS in the antitrust trail; actually, I don't remember them ever doing *anything* for free software. (Even Intel does more, though not really much...)
> So not only has Apple dumped IBM, they also appear to be planning to dump gcc.
I very much doubt it.
Not only is gcc the only ObjectiveC compiler I know of. It's actually *their own developement*! (Remember: NeXT -- the creator of most of MacOS X bought out by Apple -- not only invented ObjectiveC, but also implemented it in gcc.)
Just because you get plug-in Intel compilers (the GNU/Linux variant of the Intel compilers is almost fully gcc compatible, and probably so will be the Apple variant) to boost your C/C++/Fortran apps, for those who really want that last bit of performance, doesn't mean Apple is abdannoning gcc.
> Noone with a choice would ever use GCC for a _release_ version of anything. It's just too slow. Intel cmopiler kicks it ass in every respect except price.
I really wonder why people get so worked up on a performance difference that is way under the perception level for all but a very few extreme cases...
Sure, it would be nice to see gcc able to squeeze out that extra few percent of performance; but really, if it doesn't, who cares?