> The Dual-Core Opterons are by far the best workstation class processors out there...
That is certainly true, but AMD also charges accordingly. Did you have a look at the prices recently? I got my Athlon64 3000+ 939 for 110 Euro at the beginning of the year, and prices have not come down a single bit since then. And especially the dual core CPUs are just beyond what the average consumer is prepared to spend.
So maybe we need a bit of pricing competition from Intel? Come on, we know your chips are inferior, but are they also cheap?:-)
> You can't simply make an extra copy of a Microsoft operating system, or virtually any other commercially-released software program for that matter.
which is really interesting. Last time I checked it was trivial to make a copy of the Windows XP installation CD. Heck, you can even download a trial version.
Activation is of course a different matter. It is new with XP, and it is a major pain in the ***. But I guess for an OS it is acceptable, especially if you also receive free security updates. Registering every single CD before playing would be fun, hm?
> overpriced Itanic whose incompatibility with x86-32 made every single potential buyer back from
It might also be the lack of performance. The current version of the Itanium always sucks compared to Xeon or Opteron, but the next version is supposed to blow away the competition...
> Zhan defended Chuanghui's sale of remarked chips, saying the company makes no attempt to hide what was done to the chips or to pass them off as more valuable processors. "I tell them the truth," he said. > But Zhan acknowledged that Chuanghui has no control over how its customers represent the remarked chips when they resell them.
Maybe I can help him out with an argument there. Obviously, the "remarked" Celerons are more expensive, since he is selling the service of remarking. The chip itself is not changed: it is still as dead slow as it always was. Charging a premium price is obviously only possible if you trick your customer, which of course means selling the "remarked" Celeron as a P4. So by setting the pricing structure of the product he makes sure that the product can only be resold using fraud.
Claiming ignorance is not going to help there, it remains a big scam. Remember the empty cache ICs in 486 boards? This is no different.
> OK, I realise I know precious little about embedded devices, but exactly why do you even need to port the code from C++ to C. Surely there's a C++ compiler for the device, but if there isn't, naturally I see the issue.
I have written lots of embedded code, and some of it in C++ (with 512kB RAM!). You may want to be careful with template instantiation and the standard libraries, but otherwise there is little reason not to do it.
And I notice how old I am suddenly feeling. My first (own!) PC had 4 MB of memory, and I spent a fortune on the upgrade to 8MB, so that X would run nicely. Heck, I was doing development under X11 with emacs and gcc... and I also used applications written in C++.
So I am positive: C++ is absolutely fine with only 8MB of memory:-)
As a sidenote: pseudo-static allocation can be extremely efficient, if done correctly. It is a bit like chuncks in glib. The right memory management for the right purpose. So for general purpose stuff (not in the critical path) you can just use malloc, why not?
> Expect that no one will be satisfied with your testimony about a proposed standard having worked well for you in the past -- everyone else will deny that your "standards" are solutions to the problems of project maintainability.
That's partly because developers are smart: they know that what works good for you is not necessarily good for them. So if you want a standard that is successful, you have to get the developers involved in creating it. Just putting something down "by force of power" is so 1930s:-)
That should be rather harmless. A 13" widescreen (16:10) has a slightly smaller area than a 12" normal screen (4:3). And on the 12" iBook, the keyboard is the biggest part, determining the size.
So if the make the whole notebook slightly wider in format, they should be able to produce a notebook with a 13" screen that is as wide but slightly smaller than the current 12" (which I am writing on, and it is just great!). Let's hope this is the way it goes, because I am kind of looking for a new notebook.
> Shoulder-surfing for passwords is extremely hard.
Where did you get that from? Reading the keys is nearly trivial (unless there are more than 8), no matter what the speed. That is just the way the brain works. Getting the order right is difficult, but you can use brute force for that. Gone is your security.
So you should say: "Sure I can move to the cubicle, but we need to implement two factor authentication then, because I can obviously not rely on factor of location any more. That will cost x000 bucks and take two man-month.":-)
The author refers to an older article about Groovy. He does not really say what it is, but it seems to be new scripting language. The Groovy interpreter is a java program. Which means that the JRE is interpreting an interpreter.
I have heard before that performance is no longer relevant, but I have seen few designs that take this opinion so serious:-). I wonder whether it is faster than my first BASIC interpreter on the CPC: about 700 floating point for loops per second, and much more in integer...
> I then came to realize that he was traversing the row-major image in columns. The cache coherency was being shot to hell because none of the cache-lines were being hit as it went from pixel to pixel.
According to my experience, this happens all the time. People just don't understand how a cache works (ok, the details can be difficult). Back in the old days, it did not matter, but nowadays getting your cache access right is one of the first things to do if you want to improve performance.
On a SPARC, you have counters that give you an instruction per clock cycle reading. Just try it on a few programs, I have seen many lurking around 0.25 or 0.3. The rest is usually wasted waiting for the cache to catch up.
> When you say while(a) a++;, you do only one add per cycle.
I heard that there is a story behind the increment operator ++: early CISC machines, such as a the PDP-11, had an "auto-increment" memory access scheme. So the optimal way to write it is actually:
while (a++) ;
which gets compiled to one instruction that does the memory access and increment, and of course the conditional jump instruction. You cannot get much faster than that.
Of course with modern RISC or superscalar architectures and optimising compilers, this kind of source code optimisation is totally void. Just use for loops: they may not be particularly nice in C, but they are easy to read, and the compile will optimise the complete loop away if possible.
> I can still remember the days when machines ran in the sub 10MHz range (yes, 10MHz is 400x slower than today's 4GHz). Software was generally responsive, functional and minimal.
Nobody is going to dispute that software got bloated over the past decade(s).
But I don't think that your memories accurately represent the historic facts. I started programming in BASIC on a CPC664 (4 MHz Z80), and it was slow. Scrolling the screen for a line took about 1/2 second, so viewing a program was bound to take some time.
Then I worked with UCSD pascal on an Apple II (1 or 7 MHz bepending on interpretation). It was painstakenly slow: compiling a program of 500 lines took a few disk swaps (despite the dual disk drive) and at least 5 minutes of compile time. All wasted by a missing semicolon or similar...
Then there was text processing. No WYSIWYG, but tron like command sequences. "Compiling" the document took a while, but the printer was the real pain: 2 hours for 25 pages in "NLQ".
And then the games. I mean, look at WoW and marvel how smoothly all the characters are drawn. Compare that to PACMAN or whatever was popular at the time, with hideous delays to your input etc. The only responsive game that I remember was Snake, and that was only because a mere 4 characters on the screen need updating during a tick:-)
So bloat has gone up, but it has not prevented software from becoming faster, more responsive, more powerful, vastly more flexible etc, because we have that increase in CPU power.
> But with an alledged 90% profit margin on Office, how much more money does MS need before they are going to fix these bugs?
It is not a question of enough money, but of sufficient return. They know that they can make lots of money with bad software quality. Would they make much more money with good software quality? I guess not. Big OEMs don't care if Office crashes in some bizarre scenario. Most end users don't, either.
And, just to be fair, Word Perfect 6 crashed all the time, Openoffice has its problems, and even TeX and LyX are full of bugs. But TeX can deal much better with it, because its modular system manages the complexity of document creation much better.
And, as a side note: writing software that never crashes is nearly trivial, you only have to use a language with defined behavior (unlike C or C++:-)). Making a program always work correctly is by all practical standards impossible.
> The thing is, the nano is thin like a cell phone.
Funny enough, I carry my mobile in the pocket all the time. I try not to put it in the same pocket with keys, but it occasionally happens. And the screen has one tiny scratch (after a year of use) that you can only see if the display is off.
Compare that to my ipod, which is usually sitting at home on a board, and it has many many scratches. So there is something about the plastic they use: it does not have what the plastic of my mobile phone has. And I don't care what it is, but it would expect Apple to do better.
> THE SOFTWARE IS PROVIDED "AS IS," WITHOUT WARRANTY OF ANY KIND.
Of course in most legal system this phrase is completely voided as soon as you pay for this software. Pay = contract = responsibility. So if SSH has a bug, a hacker gets in and you can proove negligence on the part of TFA, they have to pay for it.
Funny enough, that has nothing to do with the software itself. They could sell you OpenSSH, and they would be in the same situation.
> And is strlen() deprecated in favor of something like strnlen, or is it just deprecated with no replacement?
How is strnlen() a replacement for strlen()? Sure, if you have fixed length storage, it may do, but for dynamic strings it just doesn't work. Plus strnlen() is not conforming to any standard, so you cannot rely on the behaviour being portable.
> Has anyone else found that the images he used in the article make no sense at all?
Unfortunately there is more in the article that does make no sense. First of all, he misunderstands the reason why we have PCs. PCs are not sold because they are beautiful, consistent, minimalistic or secure, but because they run the programs that people want to run. I have installed PCs for many clueless users, but they all had some special application they wanted installed. It could be the music program they saw at their neightbours, the game for the kids, some educational DVD etc.
I am sure people would buy a "computing appliance" with an easiers user interface, better document organisation, single sign on etc, *if* it also runs the special application. But they will not trade functionality for "optical sugar". If the appliance does not run "legacy applications" simple because they don't provide a seamless user interface, the appliance is wrong, and will not sell.
I would start by making PCs easier to use. The article is prefectly right: there is a lot the typical office application does not the way it should be. Give us something better, and we will use it.
Re:So how is proprietary software less affected by
on
Trouble With Open Source?
·
· Score: 2, Insightful
> lack of... professionalism
As we all know, professionalism has two meanings. The first one is that you make money from it, but a lack of that should be no concern to the user.
The second one is that you know what you are doing. I have seen many commercial software projects, and I have rarely seen one where I had the impression that they know what they are doing. Usually they are just trying something, and then wait for user complaints that it does not work.
If you take this sense, many open source projects are very professional. At least they start out with a clear idea of what to do, and with people that enjoy what they are doing.
> S3 got a bad name, but I actually never quite saw why. Same with Cyrix. Cyrix processors ran very comparable to Intel and AMD, and there really were no major 3D accelerators at the time.
Easy to say: S3 could not keep up with the development pace. The Trio64 was still widely acclaimed, but the ViRGE was sold way to long, while other manufacturers had far superior solutions. I had a Riva 128 next, and it was a completely different class. The Radeon 7000, which was quite excellent in speed, Linux support and quality.
The Cyrix CPUs were ok, but to be honest, the AMD was quite a bit better. And of course soon only Intel would support caching for more than 64MB of memory.
> and it's all due to generous amounts of gravity.:D
Maybe it feels better to think about it in terms of "intelligent falling". It is not an accident then, but a conscious act of a divine creature. Yes, I think I am fixed up on that idea.
Very likely in fact. That should also help the embedded graphics system, and would make multi-socket systems faster. NUMA is the way to go, and software support is ready for it.
> Code translation (ala Transmeta) - Possible,
Na. *Every* single attempt of code translation has failed so far. Remember P-Code? Horribly slow, couldn't compete with CP/M. Java? Slow like a dug, especially on Suns. VMWare? That's not even translation, but it is still a dug. Transmeta, FX32!, Virtual PC on Mac etc... they all have a niche, but they can't compete with the "real deal".
> SSE4 or some other such
Why not? But it would not explain the fuzz, given that there is very little support for SSE3.
> More registers - Always a good thing, we'll see if this one happens
Done. The AMD64 architecture has twice as many registers that are twice as wide. If Intel can turn that into their own "processor revolution", then they really have a good PR department:-).
> where we were forbidden to use switch, break, and continue.
Which is a useful decision for the start. Programming is about structure, structure of your control and data flow. The fewer instructions you use, the clearer the structure gets.
Having said that, it is sometimes very hard to do without function pointers. They are useful, but they come at a later stage (in contrast to break and switch, which are just conveniences, and rather ugly ones).
> Don't read the 'article' - don't post stories like this onb/. again please.
Agreed. Just for good measure, a quote:
| In reality, many of the best researchers aren't the ones you hear a lot about, because discretion is their stock in trade.
Well, if they don't publish, you can hardly call them researchers, can you? I guess the author expects tame consultants that work for "credit" only. So: don't read the article.
To me it looks just a little bit less ugly than most other Gnome configuration. Neither visually stunning nor really functional. SuSE at least has a default theme that looks reasonably well together with KDE applications in the plastik style.
Slashdot Mirror
> The Dual-Core Opterons are by far the best workstation class processors out there...
:-)
That is certainly true, but AMD also charges accordingly. Did you have a look at the prices recently? I got my Athlon64 3000+ 939 for 110 Euro at the beginning of the year, and prices have not come down a single bit since then. And especially the dual core CPUs are just beyond what the average consumer is prepared to spend.
So maybe we need a bit of pricing competition from Intel? Come on, we know your chips are inferior, but are they also cheap?
Sherman says:
> You can't simply make an extra copy of a Microsoft operating system, or virtually any other commercially-released software program for that matter.
which is really interesting. Last time I checked it was trivial to make a copy of the Windows XP installation CD. Heck, you can even download a trial version.
Activation is of course a different matter. It is new with XP, and it is a major pain in the ***. But I guess for an OS it is acceptable, especially if you also receive free security updates. Registering every single CD before playing would be fun, hm?
> overpriced Itanic whose incompatibility with x86-32 made every single potential buyer back from
It might also be the lack of performance. The current version of the Itanium always sucks compared to Xeon or Opteron, but the next version is supposed to blow away the competition...
> Does that mean the software also enables the cache? That would be too cool.
And it also makes the 1.7 GHz Celeron run at 3.6 GHz clock speed? Now that would be really cool.
> Zhan defended Chuanghui's sale of remarked chips, saying the company makes no attempt to hide what was done to the chips or to pass them off as more valuable processors. "I tell them the truth," he said.
> But Zhan acknowledged that Chuanghui has no control over how its customers represent the remarked chips when they resell them.
Maybe I can help him out with an argument there. Obviously, the "remarked" Celerons are more expensive, since he is selling the service of remarking. The chip itself is not changed: it is still as dead slow as it always was. Charging a premium price is obviously only possible if you trick your customer, which of course means selling the "remarked" Celeron as a P4. So by setting the pricing structure of the product he makes sure that the product can only be resold using fraud.
Claiming ignorance is not going to help there, it remains a big scam. Remember the empty cache ICs in 486 boards? This is no different.
> OK, I realise I know precious little about embedded devices, but exactly why do you even need to port the code from C++ to C. Surely there's a C++ compiler for the device, but if there isn't, naturally I see the issue.
:-)
I have written lots of embedded code, and some of it in C++ (with 512kB RAM!). You may want to be careful with template instantiation and the standard libraries, but otherwise there is little reason not to do it.
And I notice how old I am suddenly feeling. My first (own!) PC had 4 MB of memory, and I spent a fortune on the upgrade to 8MB, so that X would run nicely. Heck, I was doing development under X11 with emacs and gcc... and I also used applications written in C++.
So I am positive: C++ is absolutely fine with only 8MB of memory
As a sidenote: pseudo-static allocation can be extremely efficient, if done correctly. It is a bit like chuncks in glib. The right memory management for the right purpose. So for general purpose stuff (not in the critical path) you can just use malloc, why not?
> Expect that no one will be satisfied with your testimony about a proposed standard having worked well for you in the past -- everyone else will deny that your "standards" are solutions to the problems of project maintainability.
:-)
That's partly because developers are smart: they know that what works good for you is not necessarily good for them. So if you want a standard that is successful, you have to get the developers involved in creating it. Just putting something down "by force of power" is so 1930s
> the 12" ibook is set to become a 13"
That should be rather harmless. A 13" widescreen (16:10) has a slightly smaller area than a 12" normal screen (4:3). And on the 12" iBook, the keyboard is the biggest part, determining the size.
So if the make the whole notebook slightly wider in format, they should be able to produce a notebook with a 13" screen that is as wide but slightly smaller than the current 12" (which I am writing on, and it is just great!). Let's hope this is the way it goes, because I am kind of looking for a new notebook.
> Shoulder-surfing for passwords is extremely hard.
:-)
Where did you get that from? Reading the keys is nearly trivial (unless there are more than 8), no matter what the speed. That is just the way the brain works. Getting the order right is difficult, but you can use brute force for that. Gone is your security.
So you should say: "Sure I can move to the cubicle, but we need to implement two factor authentication then, because I can obviously not rely on factor of location any more. That will cost x000 bucks and take two man-month."
Thomas
The author refers to an older article about Groovy. He does not really say what it is, but it seems to be new scripting language. The Groovy interpreter is a java program. Which means that the JRE is interpreting an interpreter.
:-). I wonder whether it is faster than my first BASIC interpreter on the CPC: about 700 floating point for loops per second, and much more in integer...
I have heard before that performance is no longer relevant, but I have seen few designs that take this opinion so serious
> I then came to realize that he was traversing the row-major image in columns. The cache coherency was being shot to hell because none of the cache-lines were being hit as it went from pixel to pixel.
According to my experience, this happens all the time. People just don't understand how a cache works (ok, the details can be difficult). Back in the old days, it did not matter, but nowadays getting your cache access right is one of the first things to do if you want to improve performance.
On a SPARC, you have counters that give you an instruction per clock cycle reading. Just try it on a few programs, I have seen many lurking around 0.25 or 0.3. The rest is usually wasted waiting for the cache to catch up.
> When you say while(a) a++;, you do only one add per cycle.
I heard that there is a story behind the increment operator ++: early CISC machines, such as a the PDP-11, had an "auto-increment" memory access scheme. So the optimal way to write it is actually:
while (a++) ;
which gets compiled to one instruction that does the memory access and increment, and of course the conditional jump instruction. You cannot get much faster than that.
Of course with modern RISC or superscalar architectures and optimising compilers, this kind of source code optimisation is totally void. Just use for loops: they may not be particularly nice in C, but they are easy to read, and the compile will optimise the complete loop away if possible.
> I can still remember the days when machines ran in the sub 10MHz range (yes, 10MHz is 400x slower than today's 4GHz). Software was generally responsive, functional and minimal.
:-)
Nobody is going to dispute that software got bloated over the past decade(s).
But I don't think that your memories accurately represent the historic facts. I started programming in BASIC on a CPC664 (4 MHz Z80), and it was slow. Scrolling the screen for a line took about 1/2 second, so viewing a program was bound to take some time.
Then I worked with UCSD pascal on an Apple II (1 or 7 MHz bepending on interpretation). It was painstakenly slow: compiling a program of 500 lines took a few disk swaps (despite the dual disk drive) and at least 5 minutes of compile time. All wasted by a missing semicolon or similar...
Then there was text processing. No WYSIWYG, but tron like command sequences. "Compiling" the document took a while, but the printer was the real pain: 2 hours for 25 pages in "NLQ".
And then the games. I mean, look at WoW and marvel how smoothly all the characters are drawn. Compare that to PACMAN or whatever was popular at the time, with hideous delays to your input etc. The only responsive game that I remember was Snake, and that was only because a mere 4 characters on the screen need updating during a tick
So bloat has gone up, but it has not prevented software from becoming faster, more responsive, more powerful, vastly more flexible etc, because we have that increase in CPU power.
> But with an alledged 90% profit margin on Office, how much more money does MS need before they are going to fix these bugs?
:-)). Making a program always work correctly is by all practical standards impossible.
It is not a question of enough money, but of sufficient return. They know that they can make lots of money with bad software quality. Would they make much more money with good software quality? I guess not. Big OEMs don't care if Office crashes in some bizarre scenario. Most end users don't, either.
And, just to be fair, Word Perfect 6 crashed all the time, Openoffice has its problems, and even TeX and LyX are full of bugs. But TeX can deal much better with it, because its modular system manages the complexity of document creation much better.
And, as a side note: writing software that never crashes is nearly trivial, you only have to use a language with defined behavior (unlike C or C++
> The thing is, the nano is thin like a cell phone.
Funny enough, I carry my mobile in the pocket all the time. I try not to put it in the same pocket with keys, but it occasionally happens. And the screen has one tiny scratch (after a year of use) that you can only see if the display is off.
Compare that to my ipod, which is usually sitting at home on a board, and it has many many scratches. So there is something about the plastic they use: it does not have what the plastic of my mobile phone has. And I don't care what it is, but it would expect Apple to do better.
Interesting. It says:
> THE SOFTWARE IS PROVIDED "AS IS," WITHOUT WARRANTY OF ANY KIND.
Of course in most legal system this phrase is completely voided as soon as you pay for this software. Pay = contract = responsibility. So if SSH has a bug, a hacker gets in and you can proove negligence on the part of TFA, they have to pay for it.
Funny enough, that has nothing to do with the software itself. They could sell you OpenSSH, and they would be in the same situation.
> And is strlen() deprecated in favor of something like strnlen, or is it just deprecated with no replacement?
How is strnlen() a replacement for strlen()? Sure, if you have fixed length storage, it may do, but for dynamic strings it just doesn't work. Plus strnlen() is not conforming to any standard, so you cannot rely on the behaviour being portable.
> Has anyone else found that the images he used in the article make no sense at all?
Unfortunately there is more in the article that does make no sense. First of all, he misunderstands the reason why we have PCs. PCs are not sold because they are beautiful, consistent, minimalistic or secure, but because they run the programs that people want to run. I have installed PCs for many clueless users, but they all had some special application they wanted installed. It could be the music program they saw at their neightbours, the game for the kids, some educational DVD etc.
I am sure people would buy a "computing appliance" with an easiers user interface, better document organisation, single sign on etc, *if* it also runs the special application. But they will not trade functionality for "optical sugar". If the appliance does not run "legacy applications" simple because they don't provide a seamless user interface, the appliance is wrong, and will not sell.
I would start by making PCs easier to use. The article is prefectly right: there is a lot the typical office application does not the way it should be. Give us something better, and we will use it.
> lack of ... professionalism
As we all know, professionalism has two meanings. The first one is that you make money from it, but a lack of that should be no concern to the user.
The second one is that you know what you are doing. I have seen many commercial software projects, and I have rarely seen one where I had the impression that they know what they are doing. Usually they are just trying something, and then wait for user complaints that it does not work.
If you take this sense, many open source projects are very professional. At least they start out with a clear idea of what to do, and with people that enjoy what they are doing.
> S3 got a bad name, but I actually never quite saw why. Same with Cyrix. Cyrix processors ran very comparable to Intel and AMD, and there really were no major 3D accelerators at the time.
Easy to say: S3 could not keep up with the development pace. The Trio64 was still widely acclaimed, but the ViRGE was sold way to long, while other manufacturers had far superior solutions. I had a Riva 128 next, and it was a completely different class. The Radeon 7000, which was quite excellent in speed, Linux support and quality.
The Cyrix CPUs were ok, but to be honest, the AMD was quite a bit better. And of course soon only Intel would support caching for more than 64MB of memory.
> and it's all due to generous amounts of gravity. :D
Maybe it feels better to think about it in terms of "intelligent falling". It is not an accident then, but a conscious act of a divine creature. Yes, I think I am fixed up on that idea.
> Possible:
:-).
> Integrated memory controller
Very likely in fact. That should also help the embedded graphics system, and would make multi-socket systems faster. NUMA is the way to go, and software support is ready for it.
> Code translation (ala Transmeta) - Possible,
Na. *Every* single attempt of code translation has failed so far. Remember P-Code? Horribly slow, couldn't compete with CP/M. Java? Slow like a dug, especially on Suns. VMWare? That's not even translation, but it is still a dug. Transmeta, FX32!, Virtual PC on Mac etc... they all have a niche, but they can't compete with the "real deal".
> SSE4 or some other such
Why not? But it would not explain the fuzz, given that there is very little support for SSE3.
> More registers - Always a good thing, we'll see if this one happens
Done. The AMD64 architecture has twice as many registers that are twice as wide. If Intel can turn that into their own "processor revolution", then they really have a good PR department
> where we were forbidden to use switch, break, and continue.
Which is a useful decision for the start. Programming is about structure, structure of your control and data flow. The fewer instructions you use, the clearer the structure gets.
Having said that, it is sometimes very hard to do without function pointers. They are useful, but they come at a later stage (in contrast to break and switch, which are just conveniences, and rather ugly ones).
> Don't read the 'article' - don't post stories like this onb /. again please.
Agreed. Just for good measure, a quote:
| In reality, many of the best researchers aren't the ones you hear a lot about, because discretion is their stock in trade.
Well, if they don't publish, you can hardly call them researchers, can you? I guess the author expects tame consultants that work for "credit" only. So: don't read the article.
> Graphite suite isn't all that special.
To me it looks just a little bit less ugly than most other Gnome configuration. Neither visually stunning nor really functional. SuSE at least has a default theme that looks reasonably well together with KDE applications in the plastik style.