Linux says to you, it's your computer, you can do whatever you want with it, if you're willing to take the time to figure out how, or -- if it can't yet be done -- figure out how to code it.
Oh, come on, that's ridiculous, and I say this in a straightforward, non-trolling way. First, it's a total cop out to say that if you don't like something, you always have the power to learn to program, learn the architecture of the Linux kernel or another massive application, figure out how to make the change you want, convince the maintainers that your change should be rolled into the master tree so you don't have to keep redoing it each you grab a new version, etc. Really, how can you even argue that?
Also note that exactly the same thing is possible under Windows, if you use open source applications. You can run Firefox under Windows and Open Office and The Gimp and gcc, and almost any UNIX application. Remember, portability is a major tenet of the UNIX philosophy. Yes, it is true that you can't change OS-level services, but does this really even remotely matter except for the handful of people who get off on kernel hacking? It's not like someone can say "Hey! I need support for filesystem X" and then whip it up. There have been 9 *Linux* people in the history of the OS that have even remotely cared about this,
Finally, Linux as an OS really only gives you the freedom to work with a UNIX-like operating system. If you don't want UNIX--perhaps because think it's living in the past--then you don't have that option. So this is not some kind of all-encompassing freedom.
Windows is insecure. We know this. Partly it is the result of the operating system and partly it is the result of bad applications. And Microsoft knows it too.
This is why Microsoft is making the bold move of promoting managed langages like C# and VB.net, and a fully managed runtime in the guise of.net. This is a huge, huge step toward eliminating buffer overruns and other trivial errors. Tens of thousands of developers are making the move right now. Any bookstore has at least 50 books on.net technologies.
In short, laugh about it now, let it distract you from what's coming, let it lull you into thinking Linux will always have the security edge, go right ahead. It won't change anything.
There is always something to be said for understanding the native language of a CPU. How can there not be? You can put it down all you want, but someone has to write the code generator for each processor. There's also much benefit from writing domain specific languages. Contrary to popular opinion, writing a compiler is fairly straightforward undergraduate project. Anyone who thinks otherwise should be ashamed to be in computer science.
But let me rewind a little.
The entire point of language design, compilers, and so on, is to make programming cleaner and more reliable. Assembly language is not an ultimate goal. Neither is C++. Learning PowerPC or x86 assembly language does a good job of explaining how those architectures work, which is not necessarily a good blueprint for the future (in the case of the x86, doubly so). This is much of the reason assembly language for popular desktop processors has fallen by the wayside. x86 assembly language is more of a mid-level language, with the processor using a huge register file behind your back and reorganzing instructions on the fly. You don't have the ultimate control, which used to be one of the primary reasons assembly language was interesting. Now you have a patched-up and ugly architecture with implementations that have been tweaked and twaddled into performing well for certain types of well-behaved applications. You can break things fairly easily on the P4, such as by putting code and data in the same 1K block, or by performing simple return stack manipulations that cause the branch predictor to fall down hard. It's all very dated and byzantine and ugly.
A better method is to design an architecture for more specific needs, one that isn't trying to be the giant 1970s C machine. Keep it clean. Keep it specific. Keep is reasonably small. This makes assembly language meaningful again, and worth knowing. For example, Ericsson prototyped a processor for their functional, concurrent language, Erlang (which is used to run many of their telephone exchanges). At 20MHz it was outrunning their damn-fast interpreted implementation on a 500MHz UltraSparc--by a factor of 30. This is where the future is. Figure out what you want to do. Once you've implemented it in software, iterated it a bunch, and nailed it completely, put it in hardware. And then there's much to be had in knowing how things work all the way down to the metal. But for modern desktop processors, no, there isn't much point. It's all too soft and vague and complex and meaningless.
While Don Knuth's assembly language MIX runs on a theoretical processor, all of the examples in The Art of Computer Programming (TAOCP) are based on it. Even as he has revised the editions, he has updated the language to be based on RISC (search Google for MMIX [google.com]), but he chose not to update the examples to a higher level language
Mod the parent up! That the most classic text in computer science uses assembly language for code examples is exactly what the original poster wanted.
"Prescott, Northwood, Extreme Edition, and the AMD Athlon 64."
In all honesty--unless you absolutely need 8GB of memory--there's little difference between these processors in terms of performance. They're all more or less in the same ballpark. Sometimes faster, sometimes slower, depending on the benchmark. None of them is a huge breakout CPU performance-wise.
Here's what's different:
PRICE: There's a lot more than a few percent variation in price.
WATTS: In exchange for your 5-15% speed boost, note that you're getting more than a 15% increase in power usage.
Do they even exist, Windows fanatics? I always have the feeling people like windows as long as they don't know anything else.
In all seriousness, that's what I've always thought of Linux fanatics. They use Linux because they don't like Windows, not because they have a thorough understanding of operating systems.
While I like some architectural decisions of UNIX/Linux, I find Windows to be much less of a headache. Yeah, you have to deal with virii and crap like that, but just keep up with patches and so on and you're fine (which you also have to do with all the various parts of Linux, but it's more of a pain). So I'd be pretty upset if Windows disappeared and I had to use Linux all the time. Actually, I'd go for OS X first, which is the best of both worlds.
x86 or not seems rather irrelevant to power consumption.
The difference is that the x86 line represents the processors used by businesses and individuals in desktop machines. If the the power requirement doubles, then this is significant. It used to be that the monitor was the biggest source of power, but this is no longer true now that LCD displays are becoming standard.
And this is the big issue with the Prescott and x86 architecture in general. Sure, Moore's law, blah, blah, blah. But diminishing returns kick in hard if power consumption goes up at the same rate, and we're seeing some scary numbers now. It already looks like we'll be past 150 watts by the end of the year. How long can this continue?
Intel marches steadily on with new chips and planned obsolescence for the old chips. I tend to feel that software is lagging in terms of taking advantage of more powerful and faster processors.
Faster processors have enabled more dynamic higher-level languages like Python, Erlang, and Smalltalk to shine. This results in more robust software, software that's also quicker to implement.
(In reality, the proper approach would be to design a CPU to run Python or Erlang or Smalltalk directly. Ericsson prototyped such a chip for Erlang, and when running at 10MHz it was outrunning the Erlang emulator on a 500MHz UltraSparc by a factor of 30. And Erlang is one of the fastest interpreted languages out there. Not to mention the power consumption was something like 1% of the UltraSparc.)
AMD had it right all along - efficient IPC and low clock speed.
Of course you don't see any AMD chips that are *clearly* head and shoulders above Intel in benchmarks, though. Maybe a few percent faster here, a few percent slower there. It's all just noise.
Intel better ramp up that clock and/or have everyone optimizing for SSE3 if they want to dominate the benchmarks.
In reality, x86 benchmarks have become all but meaningless. They're all within a short distance of each other, and each chip is faster for some things, slower than others. There hasn't been a real breakway technology CPU in a long time.
remember hearing about this in 1996 when I started my first college Computer Science class. Intel and HP, two of the biggest names in computers with a market share at that time of 98% of computers on the earth using Intel CPUs or HP design RISC CPUs (mainly Intel CPUs)
You should have gone to a better college. Intel makes a small minority of the world's processors, if you remember that 95% of all CPUs sold are used in embedded systems. One of the most popular processors is still the 8-bit 8051.
Buying coffee in a coffee shop. All I want is plain coffee with milk and sugar. No latte , no expresso, No mocca , no nothing . just plain coffee with milk and sugar damn it. Unfortunately the 5+@rbuck5 salesgirl never understands this.
Then, quite frankly, you're doing something wrong. All you do is say "I would like a coffee." Then she'll say "What size?" Pick one. Done. You put the milk and sugar in yourself. Starbucks has always sold regular coffee.
Starting your own software company is easy, but you'll probably go under. The key is coming up with something that people really like so much that they're willing to pay for it. Obviously you have to conciously avoid geek tendencies to go Linux-only or to use Emacs for a GUI and so on. But that aside, it is still tough to come up with a real niche where you have _the_ product that people want to buy. You can't just jump into an existing niche with a text editor or password manager or anything else there are fifty of already. You also can't compete with high-end applications like Maya and Photoshop. Finding the right niche, and filling it correctly, is most of the battle.
The new model is: loss leading hardware and games, profit generating subscriptions
That's a myth. It worked for Everquest and a few other games, but the bottom line is that people don't want to buy a $50 game and then pay monthly fees to keep playing. And even if they do for one game, it's not something they'll do for every or even most games they buy.
Perl: Great thing to write, but people aren't sufficently motivated to read it unless they're trying to find something to use against you:|
Oh, enough of that already. The bottom line is that a programming language you are unfamiliar with looks like gobbledygook. I suppose you think Chinese and Russian are gobbledygook, too.
I didn't see the Happy Hacking 2 Lite keyboard on the list. This got a lot of positive buzz a while back, and I'de like to see how it has held up. Anyone use this? I'm a big fan of keyboards that require less space.
64 bit gave higher precision for use on CAD workstations. Anyone who every used a Sun workstation for it's intended purpose would know this.
But the x86 FPU has always supported 64-bit operations natively. Actually, they're 80-bit operations internally. This is completley different than having a 64-bit address space, of course.
Weak typing is the opposite, where a language will implicitly convert between (possibly incompatible) types or will simply allow any operation to occur.
That's not weak typing. That's simply automatic conversion of types in some cases. Weak typing is like that of Forth, where if you add a float to an integer, the BIT PATTERNS are simply added together, as if both of them were integers.
Python is strongly, dynamically typed. If you try to perform an integer operation on a string, it will check this at runtime and raise an exception. It will not perform the operation.
Python will do similar conversions, just not for strings. For example, you can add integers and floating point values without explicit conversions. From a type view, 1 + 1.0 is exactly the same as 1 + "1". So Python is no more strongly typed here than Perl is, though I realize there's a popular compulsion to make out Python to be superior to Perl (which it is in many cases, though this isn't one of them).
Its not a religion. It doesn't force its style of thinking on you.
I agree with you overall, but Python does bow down to the temple of OOP. To me, a heavy OOP style of thinking feels very dated, even though Python has a very dynamic nature to its OOPness.
I'm banking on that most people haven't the balls to do something like that. If someone isn't prepared at all to show me the source code for their application, that immediately suggests to me that they want to hide something from me -- which is reason enough for me not to want to run their code. On the other hand, if they are prepared to show me the code, then either they have nothing to hide from me; or they are really confident that whatever it is, is really well hidden.
But it isn't hidden exploits that you care about. It's subtle bugs that allow for buffer overflows and so on, and those can only be found by a detailed code review and a full test suite, and that's still no guarantee.
If you're going to go by the "show me the code" rule, then your safest bet is to make sure the code is written in a safe language like Python, Erlang, Perl, Ruby, C#, Smalltalk, etc. Then you know that random buffer overruns are much less likely to happen. Microsoft knows this, which is why they're switching to C# for all internal application development.
Mac would suffer the same fate, as would linux, but only if everyone used the same distro. considering the hundreds of distros out there, i doubt that monoculture would ever be the same problem it is today
But really, how much difference is there between Linux distributions? Or any UNIX variant for that matter? It's just a matter of what window manager and desktop environment (if any) and such. It's still a POSIX-compliant system underneath, and the great bulk of Linux and related utilities are the same. The differences make things harder for application developers, but they don't necessarily promote something "different."
Slashdot Mirror
Linux says to you, it's your computer, you can do whatever you want with it, if you're willing to take the time to figure out how, or -- if it can't yet be done -- figure out how to code it.
Oh, come on, that's ridiculous, and I say this in a straightforward, non-trolling way. First, it's a total cop out to say that if you don't like something, you always have the power to learn to program, learn the architecture of the Linux kernel or another massive application, figure out how to make the change you want, convince the maintainers that your change should be rolled into the master tree so you don't have to keep redoing it each you grab a new version, etc. Really, how can you even argue that?
Also note that exactly the same thing is possible under Windows, if you use open source applications. You can run Firefox under Windows and Open Office and The Gimp and gcc, and almost any UNIX application. Remember, portability is a major tenet of the UNIX philosophy. Yes, it is true that you can't change OS-level services, but does this really even remotely matter except for the handful of people who get off on kernel hacking? It's not like someone can say "Hey! I need support for filesystem X" and then whip it up. There have been 9 *Linux* people in the history of the OS that have even remotely cared about this,
Finally, Linux as an OS really only gives you the freedom to work with a UNIX-like operating system. If you don't want UNIX--perhaps because think it's living in the past--then you don't have that option. So this is not some kind of all-encompassing freedom.
Windows is insecure. We know this. Partly it is the result of the operating system and partly it is the result of bad applications. And Microsoft knows it too.
.net. This is a huge, huge step toward eliminating buffer overruns and other trivial errors. Tens of thousands of developers are making the move right now. Any bookstore has at least 50 books on .net technologies.
This is why Microsoft is making the bold move of promoting managed langages like C# and VB.net, and a fully managed runtime in the guise of
In short, laugh about it now, let it distract you from what's coming, let it lull you into thinking Linux will always have the security edge, go right ahead. It won't change anything.
There is always something to be said for understanding the native language of a CPU. How can there not be? You can put it down all you want, but someone has to write the code generator for each processor. There's also much benefit from writing domain specific languages. Contrary to popular opinion, writing a compiler is fairly straightforward undergraduate project. Anyone who thinks otherwise should be ashamed to be in computer science.
But let me rewind a little.
The entire point of language design, compilers, and so on, is to make programming cleaner and more reliable. Assembly language is not an ultimate goal. Neither is C++. Learning PowerPC or x86 assembly language does a good job of explaining how those architectures work, which is not necessarily a good blueprint for the future (in the case of the x86, doubly so). This is much of the reason assembly language for popular desktop processors has fallen by the wayside. x86 assembly language is more of a mid-level language, with the processor using a huge register file behind your back and reorganzing instructions on the fly. You don't have the ultimate control, which used to be one of the primary reasons assembly language was interesting. Now you have a patched-up and ugly architecture with implementations that have been tweaked and twaddled into performing well for certain types of well-behaved applications. You can break things fairly easily on the P4, such as by putting code and data in the same 1K block, or by performing simple return stack manipulations that cause the branch predictor to fall down hard. It's all very dated and byzantine and ugly.
A better method is to design an architecture for more specific needs, one that isn't trying to be the giant 1970s C machine. Keep it clean. Keep it specific. Keep is reasonably small. This makes assembly language meaningful again, and worth knowing. For example, Ericsson prototyped a processor for their functional, concurrent language, Erlang (which is used to run many of their telephone exchanges). At 20MHz it was outrunning their damn-fast interpreted implementation on a 500MHz UltraSparc--by a factor of 30. This is where the future is. Figure out what you want to do. Once you've implemented it in software, iterated it a bunch, and nailed it completely, put it in hardware. And then there's much to be had in knowing how things work all the way down to the metal. But for modern desktop processors, no, there isn't much point. It's all too soft and vague and complex and meaningless.
While Don Knuth's assembly language MIX runs on a theoretical processor, all of the examples in The Art of Computer Programming (TAOCP) are based on it. Even as he has revised the editions, he has updated the language to be based on RISC (search Google for MMIX [google.com]), but he chose not to update the examples to a higher level language
Mod the parent up! That the most classic text in computer science uses assembly language for code examples is exactly what the original poster wanted.
"Prescott, Northwood, Extreme Edition, and the AMD Athlon 64."
In all honesty--unless you absolutely need 8GB of memory--there's little difference between these processors in terms of performance. They're all more or less in the same ballpark. Sometimes faster, sometimes slower, depending on the benchmark. None of them is a huge breakout CPU performance-wise.
Here's what's different:
PRICE: There's a lot more than a few percent variation in price.
WATTS: In exchange for your 5-15% speed boost, note that you're getting more than a 15% increase in power usage.
The PPC chips don't have the heat problems of Intel's or AMD's product. So you can use smaller and more importantly more silent fans and cooling.
In principle, yes, but have you seen how much cooling hardware is inside of the dual 2GHz G5. A heckuva lot. It weighs over 60 pounds!
Do they even exist, Windows fanatics?
I always have the feeling people like windows as long as they don't know anything else.
In all seriousness, that's what I've always thought of Linux fanatics. They use Linux because they don't like Windows, not because they have a thorough understanding of operating systems.
While I like some architectural decisions of UNIX/Linux, I find Windows to be much less of a headache. Yeah, you have to deal with virii and crap like that, but just keep up with patches and so on and you're fine (which you also have to do with all the various parts of Linux, but it's more of a pain). So I'd be pretty upset if Windows disappeared and I had to use Linux all the time. Actually, I'd go for OS X first, which is the best of both worlds.
x86 or not seems rather irrelevant to power consumption.
The difference is that the x86 line represents the processors used by businesses and individuals in desktop machines. If the the power requirement doubles, then this is significant. It used to be that the monitor was the biggest source of power, but this is no longer true now that LCD displays are becoming standard.
89-103 Watts max power dissipation
Ick. That's gonna hurt.
And this is the big issue with the Prescott and x86 architecture in general. Sure, Moore's law, blah, blah, blah. But diminishing returns kick in hard if power consumption goes up at the same rate, and we're seeing some scary numbers now. It already looks like we'll be past 150 watts by the end of the year. How long can this continue?
Intel marches steadily on with new chips and planned obsolescence for the old chips. I tend to feel that software is lagging in terms of taking advantage of more powerful and faster processors.
Faster processors have enabled more dynamic higher-level languages like Python, Erlang, and Smalltalk to shine. This results in more robust software, software that's also quicker to implement.
(In reality, the proper approach would be to design a CPU to run Python or Erlang or Smalltalk directly. Ericsson prototyped such a chip for Erlang, and when running at 10MHz it was outrunning the Erlang emulator on a 500MHz UltraSparc by a factor of 30. And Erlang is one of the fastest interpreted languages out there. Not to mention the power consumption was something like 1% of the UltraSparc.)
AMD had it right all along - efficient IPC and low clock speed.
Of course you don't see any AMD chips that are *clearly* head and shoulders above Intel in benchmarks, though. Maybe a few percent faster here, a few percent slower there. It's all just noise.
Intel better ramp up that clock and/or have everyone optimizing for SSE3 if they want to dominate the benchmarks.
In reality, x86 benchmarks have become all but meaningless. They're all within a short distance of each other, and each chip is faster for some things, slower than others. There hasn't been a real breakway technology CPU in a long time.
remember hearing about this in 1996 when I started my first college Computer Science class. Intel and HP, two of the biggest names in computers with a market share at that time of 98% of computers on the earth using Intel CPUs or HP design RISC CPUs (mainly Intel CPUs)
You should have gone to a better college. Intel makes a small minority of the world's processors, if you remember that 95% of all CPUs sold are used in embedded systems. One of the most popular processors is still the 8-bit 8051.
Buying coffee in a coffee shop. All I want is plain coffee with milk and sugar. No latte , no expresso, No mocca , no nothing . just plain coffee with milk and sugar damn it. Unfortunately the 5+@rbuck5 salesgirl never understands this.
Then, quite frankly, you're doing something wrong. All you do is say "I would like a coffee." Then she'll say "What size?" Pick one. Done. You put the milk and sugar in yourself. Starbucks has always sold regular coffee.
Starting your own software company is easy, but you'll probably go under. The key is coming up with something that people really like so much that they're willing to pay for it. Obviously you have to conciously avoid geek tendencies to go Linux-only or to use Emacs for a GUI and so on. But that aside, it is still tough to come up with a real niche where you have _the_ product that people want to buy. You can't just jump into an existing niche with a text editor or password manager or anything else there are fifty of already. You also can't compete with high-end applications like Maya and Photoshop. Finding the right niche, and filling it correctly, is most of the battle.
It's entirely possible that the authors of this virus targeted SCO, simply to make it appear that Linux zealots were responsible...
Sadly, though, it shows the reputation that Linux zealots have made for themselves, not that it is any justification for this.
The new model is: loss leading hardware and games, profit generating subscriptions
That's a myth. It worked for Everquest and a few other games, but the bottom line is that people don't want to buy a $50 game and then pay monthly fees to keep playing. And even if they do for one game, it's not something they'll do for every or even most games they buy.
Perl: Great thing to write, but people aren't sufficently motivated to read it unless they're trying to find something to use against you :|
Oh, enough of that already. The bottom line is that a programming language you are unfamiliar with looks like gobbledygook. I suppose you think Chinese and Russian are gobbledygook, too.
Only disadvantage is that it is quite expensive.
It's downright cheap if you look at the prices of the keyboards in the article!
I didn't see the Happy Hacking 2 Lite keyboard on the list. This got a lot of positive buzz a while back, and I'de like to see how it has held up. Anyone use this? I'm a big fan of keyboards that require less space.
64 bit gave higher precision for use on CAD workstations. Anyone who every used a Sun workstation for it's intended purpose would know this.
But the x86 FPU has always supported 64-bit operations natively. Actually, they're 80-bit operations internally. This is completley different than having a 64-bit address space, of course.
Weak typing is the opposite, where a language will implicitly convert between (possibly incompatible) types or will simply allow any operation to occur.
That's not weak typing. That's simply automatic conversion of types in some cases. Weak typing is like that of Forth, where if you add a float to an integer, the BIT PATTERNS are simply added together, as if both of them were integers.
Python is strongly, dynamically typed. If you try to perform an integer operation on a string, it will check this at runtime and raise an exception. It will not perform the operation.
Python will do similar conversions, just not for strings. For example, you can add integers and floating point values without explicit conversions. From a type view, 1 + 1.0 is exactly the same as 1 + "1". So Python is no more strongly typed here than Perl is, though I realize there's a popular compulsion to make out Python to be superior to Perl (which it is in many cases, though this isn't one of them).
Its not a religion. It doesn't force its style of thinking on you.
I agree with you overall, but Python does bow down to the temple of OOP. To me, a heavy OOP style of thinking feels very dated, even though Python has a very dynamic nature to its OOPness.
I'm banking on that most people haven't the balls to do something like that. If someone isn't prepared at all to show me the source code for their application, that immediately suggests to me that they want to hide something from me -- which is reason enough for me not to want to run their code. On the other hand, if they are prepared to show me the code, then either they have nothing to hide from me; or they are really confident that whatever it is, is really well hidden.
But it isn't hidden exploits that you care about. It's subtle bugs that allow for buffer overflows and so on, and those can only be found by a detailed code review and a full test suite, and that's still no guarantee.
If you're going to go by the "show me the code" rule, then your safest bet is to make sure the code is written in a safe language like Python, Erlang, Perl, Ruby, C#, Smalltalk, etc. Then you know that random buffer overruns are much less likely to happen. Microsoft knows this, which is why they're switching to C# for all internal application development.
Mac would suffer the same fate, as would linux, but only if everyone used the same distro. considering the hundreds of distros out there, i doubt that monoculture would ever be the same problem it is today
But really, how much difference is there between Linux distributions? Or any UNIX variant for that matter? It's just a matter of what window manager and desktop environment (if any) and such. It's still a POSIX-compliant system underneath, and the great bulk of Linux and related utilities are the same. The differences make things harder for application developers, but they don't necessarily promote something "different."