Have you tried to talk another human being through a moderately complex task?
That's the level at which you'd have to work if you wanted to replace all human-computer interfaces with an AI. Does the thought send shivers down your spine?
ummmm . . . The "20-something kid who wrote the article" is actually a member of the IAB, and has been active in the Internet community for more than ten years now . ..
From the article:
About the Author
GEOFF HUSTON holds a B.Sc. and a M.Sc. from the Australian National University. He has been closely involved with the development of the Internet for the past decade, particularly within Australia, where he was responsible for the initial build of the Internet within the Australian academic and research sector. Huston is currently the Chief Scientist in the Internet area for Telstra. He is also a member of the Internet Architecture Board, and is the Secretary of the APNIC Executive Committee. He was an inaugural Trustee of the Internet Society, and served as Secretary of the Board of Trustees from 1993 until 2001, with a term of service as chair of the Board of Trustees in 1999 - 2000. He is author of The ISP Survival Guide, ISBN 0-471-31499-4, Internet Performance Survival Guide: QoS Strategies for Multiservice Networks, ISBN 0471-378089, and coauthor of Quality of Service: Delivering QoS on the Internet and in Corporate Networks, ISBN 0-471-24358-2, a collaboration with Paul Ferguson. All three books are published by John Wiley & Sons.
You should actually/read/ the article, rather than skimming it. It's a very nice piece of work, and what he/doesn't/ say is that we don't need IPv6 - rather, that the argument that we need IPv6 because we're running out of address space is most likely wrong.
You know, that site gets on my nerves. They have all sorts of arguments about why the system they like is so much better than any other, and how everything would be so wonderful if only the world used it . ..
The problem is, no matter how much they might trash instant runoff and it's variants, out here in the real world it actually works quite well. It's simple enough that everyone can understand it, and since everyone understands it they know what their votes mean. Concordet might be a wonderful system, but would you like to explain how it works to every voter in the country?
I really don't think any real-world voting system will be significantly better than instant runoff, regardless of the theoretical pros and cons. And I/really/ wish people would stop posting that link whenever it gets mentioned . ..
One of the requirements for the eVACS system was that the voter be able to cast an invalid vote - the requirements basically specified that the electronic system be as similar, functionally, as possible to the paper voting system, including things like donkey votes.
Incidentally, one of the lead developers of the system was Andrew Tridgell, of Samba fame. We got a number of presentations about eVACS from him and a few other people at the Canberra LUG as they were developing it. Very cool . ..
The thing to remember about the Itanic is that it has all the advantages of Intel's process technology and fab technology - the fact that it's a space heater while running on a 0.13um process indicates that there's something dodgy going on. Current Alphas are still on at least 0.18um, and with a less advanced process - it's hardly surprising that they run hot.
Itanium2 has turned out to be a worthwhile processor, after far too many years of hype and far far too much money thrown at it. I think that's why so many people here and elsewhere don't like it - the hype was massive, and the end result is only now showing it's teeth performance-wise, while still suffering from various other problems.
Alpha was a relic of an earlier age in the industry, as much as DEC. But it didn't/have/ to be! And a large part of the reason Alpha is dead, and will stay dead, is because of IA64 and the amount of time and money invested in it by HP and Intel. So I think a certain amount of bitching about Intel and Itanium is reasonable . ..
Interestingly, they interpret those numbers to mean that Linux gets used by hosting companies and ISPs, and/windows/ is used by the hobbyist and self-hosting groups - which is pretty much the exact opposite of the 'received wisdom' here on/.
I think those numbers and Netcraft's interpretation of them nicely backs up the claim I've seen elsewhere in this discussion that the methodology of the mi2g study is b0rken. After all, their sources seem to be executives in companies, and black hats with an interest in breaking into those kinds of companies - those sources would lead to a vast underreporting of the hobbyist and self-hosting windows users. At the same time, the fact that they report/sites/ rather than individual machines compromised means that they would vastly/overreport/ the number of Linux compromises.
The best we could do with the mi2g data would be tentative conclusions about one particular class of enterprise, and to get reasonable conclusions for/that/ we'd need to know how many individual machines were compromised, not how many sites. After all, just look at how different Netcraft's numbers were when they reported physical machines rather than hostnames/IPs . ..
This, I'm afraid is just completely wrong. In fact, I'd suggest you go back and re-read Knuth if you think this is what he's saying in his books.
Most of what you do as a programmer is make decisions about the value of your time, effort, and creativity in the context of what the problem space requires. There might be good objective reasons why red-black trees would be "better" than a simple sorted array, but if the time spent implementing your rbtrees is more than the value that their performance enhancements give to your code, why the hell should you use them? And what if your requirements can be implemented using two completely different approaches, each of which has similar overall costs, but with different tradeoffs? How can your mechanistic "there's exactly one algorithm that's best for any given situation" deal with/that/ kind of thing?
The real world, and the kind of real world problems that programming solves, are/not/ things that can be handled by a mechanistic approach. It requires human judgement, creativity, craftsmanship, and the kind of artistic flair you seem to think is utterly inappropriate. And I'd be willing to put a/lot/ of money on Knuth agreeing with/me/, and thinking/you/ are a short-sighted idiot. After all, this is a man who spent ten years developing a computer typesetting system because he didn't like the look of his equations when they came off the printing press.
Computer science is a branch of pure mathematics, but programming is/not/, and never will be. It's the difference between defining a circle, and drawing one.
Linux has had 64-bit ports since 1994. x86-64 is ridiculously new, and has/nothing/ to do with making the kernel 64-bit clean. It was the original Alpha port, and subsequent ports to every other 64-bit architecture out there, that did that.
Would you like to run Linux on your precious Sun hardware? You can: http://www.ultralinux.org
A teensy little bit of research would be useful before posting - you tend to look like less of an idiot.
Don't confuse file offsets with addresses - addresses in memory are unsigned, generally an unsigned long, whereas file offsets are signed, generally either an int or an int64_t.
The value passed to lseek() needs to be signed for API reasons (you need to be able to seek backwards in a file, hence the need for negative offsets). So, you can only access 2GB of a normal file before your offset wraps around.
However, there's a syscall called llseek(), which takes an loff_t - basically, #define loff_t int64_t - so that you can use signed 64 bit offsets.
As far as the kernel is concerned, most of the file syscalls take an loff_t for the offset, and the translation from a 32 bit userspace offset to a 64 bit kernel one is handled by libc. With a modern version of glibc using the large file stuff is fairly easy - you just define _FILE_OFFSET_BITS=64 somewhere, and rebuild . . . (it may be more complex than that - I haven't actually used large file support myself).
Addresses are actually even more complex than all that - for example, the Linux kernel can only directly address 960MB on x86; memory above that point needs to be accessed indirectly by mapping it into the lowmem area temporarily. The userspace app sees a nice flat 4GB address space, but the memory it actually uses can be all over the place.
That's something a 64 bit CPU (and a 64 bit kernel)/would/ help with - the kernel could directly address all the memory it wanted, without having to play around with bounce buffers and kmaps and the like. Breaking the 4GB limit is probably less useful in the short term than breaking the 960MB limit . . ..
The nice thing about the Hammer is that it's blindingly fast for/both/ 32 and 64 bit apps, and you can mix the two seamlessly. It should be a very good system.
The default on new systems doesn't mean it's the office suite on the majority of desktops (and hence the "default standard"). By the time most of the desktops have been replaced it/will/ be the "standard".
This isn't exactly a difficult concept, you know - perhaps you should work on your reading comprehension skills . ..
It's definitely not the Linux crowd specifically, 'cause I've been watching and participating in that group for around four years now and I've almost never seen that kind of attitude. If you're polite and considerate in your questions then you get a polite and considerate response; if you're not, you can't expect to get a good response, and you can't blame anyone for treating you like an idiot.
As for the snottiness of Linux users, well, I've seen just as much or more of that from *BSD users, particularly when talking of Linux users: just because we're not a "true" Unix doesn't mean we're crap, or idiots, or deficient, or anything like that. And yet that's the attitude I've seen from quite a number of *BSD users . . .
As always, of course, the noisy people are the snotty ones, so the impression you get from a quick glance is going to be of snotty people being offensive. This is something to keep in mind when talking about such things . ..
Under the GPL, you can read the code as much as you want, and reimpliment it as many times as you want, without any problems - the only limitation is that if you/copy/ the code, rather than just reimpliment it, you're in breach of copyright laws and hence the only right you have to distribute your code is that given by the GPL.
MS's shared source releases are made under various NDAs and license agreements. Not having seen these agreements I can't say what exactly they allow or disallow, but it's reasonable to assume that they include clauses that basically say "if you reimpliment this code, you are in breach of this agreement" - that's consistent with the proprietary software approach, so it's a reasonable assumption. Once you've seen the code, you're contaminated by the ideas - any time you work on that particular problem space in the future, there'll be the possibility that you're unthinkingly reusing some of the ideas you saw in MS's code.
See the difference? With GPLed code, you can read it all you want. With shared source code, once you've read it you can't reimpliment the ideas in that code without being at very serious risk of having MS jump down your throat, regardless of whether you're breaching copyright or not.
So, I call bullshit. Sorry, hope you do better next time.
As I understand it, the first women to legally cast a vote in an election anywhere in the world were South Australian women, in 1894. New Zealand granted them the right (a little bit) earlier, but they didn't get the chance to use it first. I may be wrong about that, though . . .
Nice nitpick, mind;-P
And it doesn't change my argument, since those New Zealand women didn't fight a war to get the vote.
There isn't a glaring spot in recorded history where a majority's 'freedom' was obtained by the abstinence of weapons.
You might like to do a bit of research into the history of the UK, or perhaps the history of Australia - the population of both countries acquired as much freedom as the US population has over the last two hundred years, and all without/any/ armed struggle. It's all been political and social reform, performed slowly and steadily.
Just as an example, you might like to know that Australia was the first place in the/world/ to give women the right to vote./That's/ real freedom, for literally half the population, obtained without the use of weapons.
Please, stop worshipping the idea of armed revolution - it worked in the US, but that doesn't mean it's the/only/ way to gain freedom.
What happens is that the ballots which nominated the candidate with the least number of first preference votes are redistributed, with this repeating until one candidate has a clear majority.
And our system was mentioned as one of the alternatives to the US one in the article - they called it a 'runoff' system. I rather like it, myself, though I reckon proportional representation might be better . ..
Though proportional representation might have seen Hanson and friends in federal parliament . . . . A scary thought.
GNAT has only been included in the core GCC distribution since 3.0, and it's still not amazingly well incorporated (you need extra tools to build it, rather than being able to build it straight out of the base tree as you can with the other supported languages). But yeah, talking about them seperately is at least a little out of date . ..
At which point they get the benefit of all the white-hat review that the project gets, so it's kind of a moot point.
Really, arguing that letting the black-hats see your code automatically leads to terrible insecurities is just plain stupid - if the code is that bad, you shouldn't be using it, regardless. If you're confident enough to use it in production, then revealing the code shouldn't be a serious issue.
Don't use qmail, use postfix. It's more secure, faster, simpler to use, and it has a much better license. Also, Weiste Venema is a much nicer person;-)
He'd need the latest version of XFree86, along with the DRI code. I/think/ the Radeon mobility is only properly supported in the CVS code, but it may have (incomplete) hardware acceleration in the base XFree86 4.2 . ..
The DRM modules in the kernel are useless without an X server and mesa libraries to support it, so it's not quite as simple as recompiling your kernel, unless you're using the right distro.
My understanding of this is that X/can/ handle cutting and pasting more than just text. The problem is, it requires negotiation between both sides of the transaction in order to find a format that they can handle. Text is handled by everything, because it's easy; the general case/isn't/ easy, so it tends not to be handled.
In any case, this/is/ something that's been fixed in the major toolkits. They don't use X's system, but the current versions support their own interoperable cutting and pasting and drag and drop and so forth.
himi
Re:I didn't make this up since I can't do ascii ar
on
Gnarly Error Messages
·
· Score: 2
That's just part of the oops text on any SPARC Linux kernel.
. . . and the "original" was made up out of whole cloth by Goldman . ..
It's a terrible thing to learn, I know, but the truth will set you free! In this case, free to appreciate Goldman's brilliance in coming up with the whole thing;-)
Hit google and look for something like "the princess bride real story bald-faced lie" and enjoy . ..
Slashdot Mirror
Have you tried to talk another human being through a moderately complex task?
That's the level at which you'd have to work if you wanted to replace all human-computer interfaces with an AI. Does the thought send shivers down your spine?
himi
From the article:
You should actually
himi
In fact, even more - the X protocol is compatible right back to the original X11 release, which is way back in the mists of time (1986, IIRC).
himi
You know, that site gets on my nerves. They have all sorts of arguments about why the system they like is so much better than any other, and how everything would be so wonderful if only the world used it . . .
/really/ wish people would stop posting that link whenever it gets mentioned . . .
The problem is, no matter how much they might trash instant runoff and it's variants, out here in the real world it actually works quite well. It's simple enough that everyone can understand it, and since everyone understands it they know what their votes mean. Concordet might be a wonderful system, but would you like to explain how it works to every voter in the country?
I really don't think any real-world voting system will be significantly better than instant runoff, regardless of the theoretical pros and cons. And I
himi
One of the requirements for the eVACS system was that the voter be able to cast an invalid vote - the requirements basically specified that the electronic system be as similar, functionally, as possible to the paper voting system, including things like donkey votes.
.
Incidentally, one of the lead developers of the system was Andrew Tridgell, of Samba fame. We got a number of presentations about eVACS from him and a few other people at the Canberra LUG as they were developing it. Very cool . .
himi
The thing to remember about the Itanic is that it has all the advantages of Intel's process technology and fab technology - the fact that it's a space heater while running on a 0.13um process indicates that there's something dodgy going on. Current Alphas are still on at least 0.18um, and with a less advanced process - it's hardly surprising that they run hot.
/have/ to be! And a large part of the reason Alpha is dead, and will stay dead, is because of IA64 and the amount of time and money invested in it by HP and Intel. So I think a certain amount of bitching about Intel and Itanium is reasonable . . .
Itanium2 has turned out to be a worthwhile processor, after far too many years of hype and far far too much money thrown at it. I think that's why so many people here and elsewhere don't like it - the hype was massive, and the end result is only now showing it's teeth performance-wise, while still suffering from various other problems.
Alpha was a relic of an earlier age in the industry, as much as DEC. But it didn't
himi
Interestingly, they interpret those numbers to mean that Linux gets used by hosting companies and ISPs, and /windows/ is used by the hobbyist and self-hosting groups - which is pretty much the exact opposite of the 'received wisdom' here on /.
/sites/ rather than individual machines compromised means that they would vastly /overreport/ the number of Linux compromises.
/that/ we'd need to know how many individual machines were compromised, not how many sites. After all, just look at how different Netcraft's numbers were when they reported physical machines rather than hostnames/IPs . . .
I think those numbers and Netcraft's interpretation of them nicely backs up the claim I've seen elsewhere in this discussion that the methodology of the mi2g study is b0rken. After all, their sources seem to be executives in companies, and black hats with an interest in breaking into those kinds of companies - those sources would lead to a vast underreporting of the hobbyist and self-hosting windows users. At the same time, the fact that they report
The best we could do with the mi2g data would be tentative conclusions about one particular class of enterprise, and to get reasonable conclusions for
himi
This, I'm afraid is just completely wrong. In fact, I'd suggest you go back and re-read Knuth if you think this is what he's saying in his books.
/that/ kind of thing?
/not/ things that can be handled by a mechanistic approach. It requires human judgement, creativity, craftsmanship, and the kind of artistic flair you seem to think is utterly inappropriate. And I'd be willing to put a /lot/ of money on Knuth agreeing with /me/, and thinking /you/ are a short-sighted idiot. After all, this is a man who spent ten years developing a computer typesetting system because he didn't like the look of his equations when they came off the printing press.
/not/, and never will be. It's the difference between defining a circle, and drawing one.
Most of what you do as a programmer is make decisions about the value of your time, effort, and creativity in the context of what the problem space requires. There might be good objective reasons why red-black trees would be "better" than a simple sorted array, but if the time spent implementing your rbtrees is more than the value that their performance enhancements give to your code, why the hell should you use them? And what if your requirements can be implemented using two completely different approaches, each of which has similar overall costs, but with different tradeoffs? How can your mechanistic "there's exactly one algorithm that's best for any given situation" deal with
The real world, and the kind of real world problems that programming solves, are
Computer science is a branch of pure mathematics, but programming is
himi
Linux has had 64-bit ports since 1994. x86-64 is ridiculously new, and has /nothing/ to do with making the kernel 64-bit clean. It was the original Alpha port, and subsequent ports to every other 64-bit architecture out there, that did that.
Would you like to run Linux on your precious Sun hardware? You can: http://www.ultralinux.org
A teensy little bit of research would be useful before posting - you tend to look like less of an idiot.
himi
Don't confuse file offsets with addresses - addresses in memory are unsigned, generally an unsigned long, whereas file offsets are signed, generally either an int or an int64_t.
/would/ help with - the kernel could directly address all the memory it wanted, without having to play around with bounce buffers and kmaps and the like. Breaking the 4GB limit is probably less useful in the short term than breaking the 960MB limit . . . .
/both/ 32 and 64 bit apps, and you can mix the two seamlessly. It should be a very good system.
The value passed to lseek() needs to be signed for API reasons (you need to be able to seek backwards in a file, hence the need for negative offsets). So, you can only access 2GB of a normal file before your offset wraps around.
However, there's a syscall called llseek(), which takes an loff_t - basically, #define loff_t int64_t - so that you can use signed 64 bit offsets.
As far as the kernel is concerned, most of the file syscalls take an loff_t for the offset, and the translation from a 32 bit userspace offset to a 64 bit kernel one is handled by libc. With a modern version of glibc using the large file stuff is fairly easy - you just define _FILE_OFFSET_BITS=64 somewhere, and rebuild . . . (it may be more complex than that - I haven't actually used large file support myself).
Addresses are actually even more complex than all that - for example, the Linux kernel can only directly address 960MB on x86; memory above that point needs to be accessed indirectly by mapping it into the lowmem area temporarily. The userspace app sees a nice flat 4GB address space, but the memory it actually uses can be all over the place.
That's something a 64 bit CPU (and a 64 bit kernel)
The nice thing about the Hammer is that it's blindingly fast for
himi
The default on new systems doesn't mean it's the office suite on the majority of desktops (and hence the "default standard"). By the time most of the desktops have been replaced it /will/ be the "standard".
.
This isn't exactly a difficult concept, you know - perhaps you should work on your reading comprehension skills . .
himi
It's definitely not the Linux crowd specifically, 'cause I've been watching and participating in that group for around four years now and I've almost never seen that kind of attitude. If you're polite and considerate in your questions then you get a polite and considerate response; if you're not, you can't expect to get a good response, and you can't blame anyone for treating you like an idiot.
.
As for the snottiness of Linux users, well, I've seen just as much or more of that from *BSD users, particularly when talking of Linux users: just because we're not a "true" Unix doesn't mean we're crap, or idiots, or deficient, or anything like that. And yet that's the attitude I've seen from quite a number of *BSD users . . .
As always, of course, the noisy people are the snotty ones, so the impression you get from a quick glance is going to be of snotty people being offensive. This is something to keep in mind when talking about such things . .
himi
Ummm . . . Bullshit.
/copy/ the code, rather than just reimpliment it, you're in breach of copyright laws and hence the only right you have to distribute your code is that given by the GPL.
Under the GPL, you can read the code as much as you want, and reimpliment it as many times as you want, without any problems - the only limitation is that if you
MS's shared source releases are made under various NDAs and license agreements. Not having seen these agreements I can't say what exactly they allow or disallow, but it's reasonable to assume that they include clauses that basically say "if you reimpliment this code, you are in breach of this agreement" - that's consistent with the proprietary software approach, so it's a reasonable assumption. Once you've seen the code, you're contaminated by the ideas - any time you work on that particular problem space in the future, there'll be the possibility that you're unthinkingly reusing some of the ideas you saw in MS's code.
See the difference? With GPLed code, you can read it all you want. With shared source code, once you've read it you can't reimpliment the ideas in that code without being at very serious risk of having MS jump down your throat, regardless of whether you're breaching copyright or not.
So, I call bullshit. Sorry, hope you do better next time.
himi
As I understand it, the first women to legally cast a vote in an election anywhere in the world were South Australian women, in 1894. New Zealand granted them the right (a little bit) earlier, but they didn't get the chance to use it first. I may be wrong about that, though . . .
;-P
Nice nitpick, mind
And it doesn't change my argument, since those New Zealand women didn't fight a war to get the vote.
himi
You might like to do a bit of research into the history of the UK, or perhaps the history of Australia - the population of both countries acquired as much freedom as the US population has over the last two hundred years, and all without
Just as an example, you might like to know that Australia was the first place in the
Please, stop worshipping the idea of armed revolution - it worked in the US, but that doesn't mean it's the
himi
Oh yes, it's so /terribly/ hard to do . . .
.
Which is why no one here in Australia has any difficulty with it . . .
Or maybe we're just smarter than your typical USAian? No, more likely we've just been taught how to do it.
Claiming that it's too hard to set up a proper electoral system, or that it's too hard for people to make use of one, is just plain stupid.
himi
Well, not in federal elections.
.
What happens is that the ballots which nominated the candidate with the least number of first preference votes are redistributed, with this repeating until one candidate has a clear majority.
And our system was mentioned as one of the alternatives to the US one in the article - they called it a 'runoff' system. I rather like it, myself, though I reckon proportional representation might be better . .
Though proportional representation might have seen Hanson and friends in federal parliament . . . . A scary thought.
himi
GNAT has only been included in the core GCC distribution since 3.0, and it's still not amazingly well incorporated (you need extra tools to build it, rather than being able to build it straight out of the base tree as you can with the other supported languages). But yeah, talking about them seperately is at least a little out of date . . .
himi
At which point they get the benefit of all the white-hat review that the project gets, so it's kind of a moot point.
Really, arguing that letting the black-hats see your code automatically leads to terrible insecurities is just plain stupid - if the code is that bad, you shouldn't be using it, regardless. If you're confident enough to use it in production, then revealing the code shouldn't be a serious issue.
himi
Because what you had to say is about right.
;-)
Don't use qmail, use postfix. It's more secure, faster, simpler to use, and it has a much better license. Also, Weiste Venema is a much nicer person
himi
I'll second rat7307 . . . and be thankful it wasn't worse . . .
himi
He'd need the latest version of XFree86, along with the DRI code. I /think/ the Radeon mobility is only properly supported in the CVS code, but it may have (incomplete) hardware acceleration in the base XFree86 4.2 . . .
The DRM modules in the kernel are useless without an X server and mesa libraries to support it, so it's not quite as simple as recompiling your kernel, unless you're using the right distro.
himi
My understanding of this is that X /can/ handle cutting and pasting more than just text. The problem is, it requires negotiation between both sides of the transaction in order to find a format that they can handle. Text is handled by everything, because it's easy; the general case /isn't/ easy, so it tends not to be handled.
/is/ something that's been fixed in the major toolkits. They don't use X's system, but the current versions support their own interoperable cutting and pasting and drag and drop and so forth.
In any case, this
himi
That's just part of the oops text on any SPARC Linux kernel.
;-)
Dave Miller has a weird sense of humour
himi
. . . and the "original" was made up out of whole cloth by Goldman . . .
;-)
.
It's a terrible thing to learn, I know, but the truth will set you free! In this case, free to appreciate Goldman's brilliance in coming up with the whole thing
Hit google and look for something like "the princess bride real story bald-faced lie" and enjoy . .
himi