Point 1 is so weak that I won't even comment it, especially as you weaken it immediately with asprintf in point 2.
For point 2, look, people currently use strcpy, strcat, sprintf (snprintf if there are sensible), so they need secure replacement for all these function: you don't change habits so easily. Beside asprintf allocates a buffer on the heap, something you don't necessarily want to do (performance, need to free later).
Point 3 is *bullshit* the point of having a standard library is to contain the common code!
If glibc had included strlcat, strlcpy, there is a real possibility that the C99 would have added them to the standard C library..
Ulrich acted really stupid when he didn't include those function into glibc, but I think that he is so stubborn that he won't ever correct his mistakes.
I'm not sure why you call Microsoft's owernship of the PC OS an aberration.. As you said every company is trying to own the pie, and I would add to commoditize the other part that they can't own: think of Sun and StarOffice, they're trying to hurt Microsoft other cash cow, but commoditising Office suite.
So everyone is try to do it, but Microsoft succeeded and they did manage to commoditise the web browser, for example to distroy Netscape, while at the same time 'proprietarising' the web using Microsoft-HTML rendering, same thing for DirectX vs OpenGL, etc.. But Bell also succeeded, Ford before, IBM, etc.. There is nothing aberrant in managing to reach a monopoly status: it's so common that laws exist to prevent that monopolies hurt (too much) consumers.
I agree and I would even go further: multi-threading is not enough for the Flash plugin. Those kind of complex plugins whose reliability cannot be trusted should run in another process. This way, if the plugin crash, the application stays alive (and there could be a right click option to trigger a restart of the plugin).
>Spill code does not actually have to hit memory as long as there are rename registers left,
In theory yes, but are you sure that x86 do it? Keeping trak of memory location seems awfully hard to do instead of just checking for RAW, WAW register dependency (which is needed for execution anyway).
Your post sounded as if register renaming was enough: my point was that 20% increase of performance from going from 8 to 16 registers is a lot considering that the surface of silicon used to contain the additional registers is ridiculously small.
You're of course right about the need to have bigger instruction to use a bigger number of registers, but I would be interested to know instruction density comparison between an ARM Thumb2 (16, 32 bits instruction with 16,32 registers which can be mixed) and x86: while x86 as a CISC is space efficient, I wonder how a RISC designed to be space efficient too (which is not a design criteria of the Alpha for example or at least not with a big priority) would fare.
I disagree about your point about 8 register not being a problem: register renaming help but if the compiler don't see the register, it may have to spill a register in memory to make room, register renaming can't do anything about it.
I think that going from 8 to 16 register has made something like a 20% improvement for the x86-64. So 1) it is a big improvement 2) 8 register is a big problem in practice: you take a 20% hit even with register renaming (in pratice the loss is even greater as the new register are disadvantaged by having to use bigger instruction to use them).
Also remember that register renaming is not only used by x86, it is used also by the RISC CPUs.
You forgot one thing in your analysis: Itanium architecture is only in the hand of Intel (maybe HP too? Don't know if they have the rights to produce CPUs), whereas x86 can be made by Intel, AMD, IBM, Cyrix, etc..
While I dislike very much the Itanium architecture (PPC, Alpha, ARM Thumb2 mmmh), it is obviously much better than the POS x86 that Intel made.. but removing competition? I'll stick with x86, thanks!
Except that Einstein had Mercure orbit has an "experimental proof" that his theory was correct, whereas string theories have nothing to support them: they could turnout to be totally bunk, we don't know yet.
They are studied because they are 'elegant', before Newton, circular orbit was the way to go because circles are 'elegant'..
Note that I don't say that studying string theory is bunk, just that being popular means nothing until actual predictions can be verified.
I bought the previous edition of the red book because it was written in the summary that it was talking about the vertex and fragment shaders which they didn't.
As you may guess, I was (and still am) quite pissed off by this false advertising, in the newsgroup an author said it was a mistake, a pretty big mistake if you ask me! Have they fixed this "mistake"?
> Sorry, but who the hell cares if subpixel aliasing is exactly the same across different OpenGL drivers or not?
Well, people who wants to make application with readable fonts.
'All you need' in practice, there is no way that all those implementors will agree to a common algorithm unless it is standardised somewhere, and even in this case, there shall some kind of stick&carrot to ensure compliance otherwise they won't bother.
He didn't say OpenGL prevents subpixel rendering, he said 'doesn't support' which is true: OpenGL does nothing to support subpixel rendering, so it doesn't support it.
Developer loss? Which developers? Certainly the Linux kernel developpers would be unhappy if they only received tainted bug reports (or very happy as these report goes probably in/dev/null very fast).. So at least those developpers are quite happy if the users do not taint their kernel!
You forget to include the bad point of using OpenGL for X: for this to be efficient, you need to use the GPU 3D acceleration, which means currently using proprietary drivers from NVidia or ATI..
No wonder, developpers are not so interested helping XGL..
> All things being equal, you should generally choose the most powerful language you can all the time.
Sorry but this sentence is not very usefull as things are *never* being equal: numbers of programmers knowing the language, completeness of the support libraries, memory usage, easiness of interfacing with a 'fast language' (if the powerful language happens to do some parts too slow)..
Also IMHO you're confusing research and usefulness: there are research language which tries to search features independent of Lisp but Ruby, Python, etc. are not especially trying to invent 'new' features, they're trying to produce a good mix of features in a way that makes it easy for the programmers to use.
If I understand the review, the idea is rendering the environement for the AI, the problem of course with this idea is that it can be very cpu consuming.. Of course you don't have to do the full rendering, but for exemple light condition should have an impact on visibility so the rendering must be quite detailed..
>IIRC someone ported Linux to one of the virtual machines and was able to run a crazy number of instances on one set of hardware.
IBM did, but noone said that this 'crazy number' of Linux VM was something usable, I think it was just a stress test. What is the point of running a 'crazy number' of VM if most of them must stay idle otherwise the computer melt down under the load?
Also no need to 'open up' the architecture of mainframes, AMD and Intel are adding their own virtualisation technology to x86, they have hyped it several times already.
Virtualisation will increase the flexibility for administrators, and allow some power usage reduction, but I'll doubt that companies will rush to dump their current hardware to have these new CPUs just because they support virtualisation..
- As said above XP doesn't work with Xen, VMWare does. - Xen is not yet compatible with NPTL, I think. This will change, of course, but this hardly makes Xen so exciting, doesn't it?
>"It's jonesy's fault! He took personal, unauthorised measures to retaliate."
And why would jonesy accept to be a scapegoat in the ensuing trial? If he has a brain, he kept traces of what he was ordered to do, for his own protection.
Plus you underestimate the effect of that bad publicity may have on companies.
> Would a big, multi-national corporation get punished for "accidentally" frying the computer of someone who was thought to be intruding into the corporation's computers? I seriously doubt it.
It makes for a nice story, but how do you find the cracker's computer? If you fry the computers who attack you, you have 99% of chance of frying the computers of guys who are only guilty of not having secured their PC enough.. And this *would not* be without consequence (assuming the corporation get caught).
As said reusable means cheap only if you have lots of flight because the reusable ship being much more expensive to build the investment must be amortised on many flights to become economical.
The space shuttle was built with an estimate of very frequent flight which never happened, thus it is very expensive.
I don't expect space flight to become much more frequent in the near future (than they were when the shuttle worked correctly) because there isn't much incentive, so I think that the new design should be as cheap as possible in itself: multiple stages and soyouz-like ship.
A flaw in a software product is totally different that having 'unsecure seatbelt': in the first one thief/crackers are trying to use it to gain money/advantage, the other one is purely a safety problem.
If you announced publicly a fault in cars which allow thief to steal cars without first contacting the cars manufacturers (I don't say this what occured here), I suppose that the company wouldn't be too much happy..
Slashdot Mirror
Yes and those reason are laughable:
Point 1 is so weak that I won't even comment it, especially as you weaken it immediately with asprintf in point 2.
For point 2, look, people currently use strcpy, strcat, sprintf (snprintf if there are sensible), so they need secure replacement for all these function: you don't change habits so easily.
Beside asprintf allocates a buffer on the heap, something you don't necessarily want to do (performance, need to free later).
Point 3 is *bullshit* the point of having a standard library is to contain the common code!
If glibc had included strlcat, strlcpy, there is a real possibility that the C99 would have added them to the standard C library..
Ulrich acted really stupid when he didn't include those function into glibc, but I think that he is so stubborn that he won't ever correct his mistakes.
I'm not sure why you call Microsoft's owernship of the PC OS an aberration..
As you said every company is trying to own the pie, and I would add to commoditize the other part that they can't own: think of Sun and StarOffice, they're trying to hurt Microsoft other cash cow, but commoditising Office suite.
So everyone is try to do it, but Microsoft succeeded and they did manage to commoditise the web browser, for example to distroy Netscape, while at the same time 'proprietarising' the web using Microsoft-HTML rendering, same thing for DirectX vs OpenGL, etc..
But Bell also succeeded, Ford before, IBM, etc..
There is nothing aberrant in managing to reach a monopoly status: it's so common that laws exist to prevent that monopolies hurt (too much) consumers.
I agree and I would even go further: multi-threading is not enough for the Flash plugin.
Those kind of complex plugins whose reliability cannot be trusted should run in another process.
This way, if the plugin crash, the application stays alive (and there could be a right click option to trigger a restart of the plugin).
>There is plenty of closed source software that supports open standards.
Support in why way?
"Embrace and extend" way so that customers are locked in a specific implementation of the standard+? Or a real support?
If we take perhaps the most used open standard: HTML. "Closed source software" support doesn't look so good..
Well, IMHO the probe that will be added in the kernel must be BSD licensed of course, and the rest will stay with the same license..
>Spill code does not actually have to hit memory as long as there are rename registers left,
In theory yes, but are you sure that x86 do it?
Keeping trak of memory location seems awfully hard to do instead of just checking for RAW, WAW register dependency (which is needed for execution anyway).
Your post sounded as if register renaming was enough: my point was that 20% increase of performance from going from 8 to 16 registers is a lot considering that the surface of silicon used to contain the additional registers is ridiculously small.
You're of course right about the need to have bigger instruction to use a bigger number of registers, but I would be interested to know instruction density comparison between an ARM Thumb2 (16, 32 bits instruction with 16,32 registers which can be mixed) and x86: while x86 as a CISC is space efficient, I wonder how a RISC designed to be space efficient too (which is not a design criteria of the Alpha for example or at least not with a big priority) would fare.
I disagree about your point about 8 register not being a problem: register renaming help but if the compiler don't see the register, it may have to spill a register in memory to make room, register renaming can't do anything about it.
I think that going from 8 to 16 register has made something like a 20% improvement for the x86-64.
So 1) it is a big improvement 2) 8 register is a big problem in practice: you take a 20% hit even with register renaming (in pratice the loss is even greater as the new register are disadvantaged by having to use bigger instruction to use them).
Also remember that register renaming is not only used by x86, it is used also by the RISC CPUs.
You forgot one thing in your analysis: Itanium architecture is only in the hand of Intel (maybe HP too? Don't know if they have the rights to produce CPUs), whereas x86 can be made by Intel, AMD, IBM, Cyrix, etc..
While I dislike very much the Itanium architecture (PPC, Alpha, ARM Thumb2 mmmh), it is obviously much better than the POS x86 that Intel made.. but removing competition?
I'll stick with x86, thanks!
Except that Einstein had Mercure orbit has an "experimental proof" that his theory was correct, whereas string theories have nothing to support them: they could turnout to be totally bunk, we don't know yet.
They are studied because they are 'elegant', before Newton, circular orbit was the way to go because circles are 'elegant'..
Note that I don't say that studying string theory is bunk, just that being popular means nothing until actual predictions can be verified.
I bought the previous edition of the red book because it was written in the summary that it was talking about the vertex and fragment shaders which they didn't.
As you may guess, I was (and still am) quite pissed off by this false advertising, in the newsgroup an author said it was a mistake, a pretty big mistake if you ask me! Have they fixed this "mistake"?
> Sorry, but who the hell cares if subpixel aliasing is exactly the same across different OpenGL drivers or not?
Well, people who wants to make application with readable fonts.
'All you need' in practice, there is no way that all those implementors will agree to a common algorithm unless it is standardised somewhere, and even in this case, there shall some kind of stick&carrot to ensure compliance otherwise they won't bother.
He didn't say OpenGL prevents subpixel rendering, he said 'doesn't support' which is true: OpenGL does nothing to support subpixel rendering, so it doesn't support it.
Developer loss? /dev/null very fast)..
Which developers?
Certainly the Linux kernel developpers would be unhappy if they only received tainted bug reports (or very happy as these report goes probably in
So at least those developpers are quite happy if the users do not taint their kernel!
You forget to include the bad point of using OpenGL for X: for this to be efficient, you need to use the GPU 3D acceleration, which means currently using proprietary drivers from NVidia or ATI..
No wonder, developpers are not so interested helping XGL..
> All things being equal, you should generally choose the most powerful language you can all the time.
Sorry but this sentence is not very usefull as things are *never* being equal: numbers of programmers knowing the language, completeness of the support libraries, memory usage, easiness of interfacing with a 'fast language' (if the powerful language happens to do some parts too slow)..
Also IMHO you're confusing research and usefulness: there are research language which tries to search features independent of Lisp but Ruby, Python, etc. are not especially trying to invent 'new' features, they're trying to produce a good mix of features in a way that makes it easy for the programmers to use.
I'd rather do programming than math, thanks.
Oh, has Haskell a debugger finally?
I think not yet..
If I understand the review, the idea is rendering the environement for the AI, the problem of course with this idea is that it can be very cpu consuming..
Of course you don't have to do the full rendering, but for exemple light condition should have an impact on visibility so the rendering must be quite detailed..
It is not as if Microsoft needs the money!
It is really too bad that Microsoft did a settlement, they should have gone all the way..
>IIRC someone ported Linux to one of the virtual machines and was able to run a crazy number of instances on one set of hardware.
IBM did, but noone said that this 'crazy number' of Linux VM was something usable, I think it was just a stress test.
What is the point of running a 'crazy number' of VM if most of them must stay idle otherwise the computer melt down under the load?
Also no need to 'open up' the architecture of mainframes, AMD and Intel are adding their own virtualisation technology to x86, they have hyped it several times already.
Virtualisation will increase the flexibility for administrators, and allow some power usage reduction, but I'll doubt that companies will rush to dump their current hardware to have these new CPUs just because they support virtualisation..
- As said above XP doesn't work with Xen, VMWare does.
- Xen is not yet compatible with NPTL, I think.
This will change, of course, but this hardly makes Xen so exciting, doesn't it?
>"It's jonesy's fault! He took personal, unauthorised measures to retaliate."
And why would jonesy accept to be a scapegoat in the ensuing trial?
If he has a brain, he kept traces of what he was ordered to do, for his own protection.
Plus you underestimate the effect of that bad publicity may have on companies.
> Would a big, multi-national corporation get punished for "accidentally" frying the computer of someone who was thought to be intruding into the corporation's computers? I seriously doubt it.
It makes for a nice story, but how do you find the cracker's computer?
If you fry the computers who attack you, you have 99% of chance of frying the computers of guys who are only guilty of not having secured their PC enough..
And this *would not* be without consequence (assuming the corporation get caught).
Through avian carrier, of course!
Yeah, right, somehow with my USB ADSL modem (speedtouch), I feel like FTP install won't work..
As said reusable means cheap only if you have lots of flight because the reusable ship being much more expensive to build the investment must be amortised on many flights to become economical.
The space shuttle was built with an estimate of very frequent flight which never happened, thus it is very expensive.
I don't expect space flight to become much more frequent in the near future (than they were when the shuttle worked correctly) because there isn't much incentive, so I think that the new design should be as cheap as possible in itself: multiple stages and soyouz-like ship.
A flaw in a software product is totally different that having 'unsecure seatbelt': in the first one thief/crackers are trying to use it to gain money/advantage, the other one is purely a safety problem.
If you announced publicly a fault in cars which allow thief to steal cars without first contacting the cars manufacturers (I don't say this what occured here), I suppose that the company wouldn't be too much happy..