Anyone who's actually had to deal with ASN.1 or SNMP will think twice about instantly embracing another Rose protocol. (Last I heard, though, he had admitted that using ASN.1 was probably a bad idea.)
"Was Gates really a snide poser whose vision of shoddy upgrade-driven software and world domination crystallized at the age of 3?"
Considering that on the first microcomputer, he was the first person to charge for software and whine about people copying it - when he didn't even write it himself ---
When you write a CGI in perl, you almost always use the CGI module. You don't have to worry about coding regcomp and regexec calls, you don't have to deal with manually allocating memory. You just write your code and are done with it instead of having to continually reinvent the wheel. (Personally, I believe that my time is far more valuble than the computer's.)
perl is one of the few actual examples of code reuse, FWIW.
SMP is decidedly unsexy in a lot of ways, but it's _hard_ to do right and in a sane way. One of the reasons I like BeOS is because not only does it have fine-grained SMP, but it also encourages - nay, requires - threading in all sorts of places, thus vastly boosting the benefits of having multiple processors.
When we hit the limits of Moore's law, we'll _have_ to scale to more processors - and then SMP will be horribly important to even casual users.
The altogether-too-many versions of Linux out there are already a big concern for some people; for instance, on the perl5-porters list there has been a rather large thread about telling one linux from another, due to differences in what works and what does not. So far, it's proving rather difficult indeed to sort out what all the versions are.
What would really do service to the community is for the various distributions to get their act together and work on some common method of identifying exactly what is being run. As a side effect, this would also make dealing with forks easier.
Knapsacks have been tossed by the wayside; quantum computing, if it'll work, is blasting away at factoring (if the NFS doesn't beat it into the ground all by itself); elliptic fields are being restrained by patents. What's the Next Big Thing for crypto gonna be?
I've ported perl to a new OS and I've written my own modules, so I feel I have a relatively valid viewpoint on perl's internals.
Basically, the internal datastructures are hoary. They're awful to dig through, and even worse to try and modify. Even writing external modules for use in perl can be horribly nasty because of the structures involved, the reference counting, etc.
I'd say at this point there are about 10-20 people (at most) who are competent to go and change the guts of perl. That's not a large number, especially when they don't have all that many tuits.
One of the prime motivations of rewriting perl in C++ is so that things will be modularized so that the knowledge barrier is greatly reduced. Right now, you need to know how _everything_ works before you can modify _anything_.
I'll be quite glad to get rid of things like return sv_2mortal(newSVpv(ret,len));, thank you very much.
"Why is Linux not used for X, when Y uses Linux for Z"?
That kinda argument completely ignores the fact that X may be completely different than Z.
Incidentally, the current crop of opers may be mostly newbies, but the Real Old crowd have been around for quite a long time, and they've know precisely how and why the *BSD and Linux TCP stacks suck.
It's also the devil you know vs the devil you don't, too.
On the other hand I've been running Linux on that same box (updated processors recently) for well over a year and while the SMP performance has certainly improved recently, I've never had stability problems.
This shows one of the main differences of philosophy between the Linux and *BSD camps - Linux's philosophy seems to be "get it out there, even if it's broken", whereas BSD's is "it'll be Done Right, even if it takes us several years to do so, and don't release anything in progress."
Linux SMP for quite a long time, simply put, wasn't. It wasn't symmetric, and it would block as soon as it hit the kernel. It was SMP in exactly the same way as SunOS.
FWIW, this may have changed recently. I'm sure there will be half a million zealots ready to pounce on me for it, though.
I, who work for an unnamed NSP with an OC-48 backbone (that's over 2 Gigabits/sec), have seen that one of the major limitations isn't the bandwidth, but being able to route the damn packets. Nobody really has routers yet that are too terribly stable at that high a bandwidth.
There's still a fair bit of dark fibre from the Qwest buildout, too...
IMHO, what's going to be one of the major bottlenecks in domestic networks is the local loop that goes to your house and getting local fiber from the CO to elsewhere - not the backbones.
In addition, if you try and simulate something like the stretching of plastic, it's an inherently linear problem. No amount of parallelism can speed that sort of thing up.
Beowulfs just don't deal well with closely-related parallel tasks... they're just fine and dandy with things like mandelbrot sets, though, where none of the iterations depend on each other.
2. That was the eighties, my good man. Less than twenty years ago. (earlier part of this century?)
3. Buyer of Union Pacific. Railroad lines mean preestablished right of way.
MCI stands for 'Microwave Communication, Inc.'; they got their start doing point-to-point CB-like service, I believe, and then branched out into long distance.
Nobody seems to know how or why Worldcom got to where it is now.:)
L3 is currently doing OK, since nobody likes MFS and Worldcom much any more. (This also explains why UUNET turned into a bunch of bastards after Worldcom bought 'em... originally they were the only commercial inet presence, the only place where you didn't have to know the secret ARPA/NFS handshake to get a net connection, nor had to deal with the NFS AUP.)
Frontier is the former Rochester Telephone Company. Ain't a Baby Bell. (The data portions of Frontier were only bought like last year, too.)
Global Crossing's management is made up of some _heavy_ players - I think the CEO (or former CEO) of AT&T is on the GBLX board.
(in addition, the data unit of Frontier [GlobalCenter, neé ISI/PrimeNet] only has a couple hundred employees, yet is forecasted to provide a very very large chunk of Frontier's profits.)
The Baby Bells have been trying to get back together for years; that should surprise nobody. They started doing so right after they were allowed to do so again.
However, more and more people in the data/IP industry are convinced that relatively soon, data will be regarded as a mere commodity; it won't matter who you buy from, unless you've got stupendous amounts of capacity. IP will effectively become another utility.
One of the main reasons why buying out Frontier is so attractive is that Frontier participated in the last Qwest fibre buildout, and now Frontier has excess fibre capacity; Global Crossings, on the other hand, is laying tons of trans-oceanic fibre (and its only real competitor right now is the CW unit.) Lots o' trans-ocean and lots o' trans-US fibre complement each other nicely... and trans-{Atlantic, Pacific} capacity is still sufficiently rare that it won't be considered a mere commodity in the near term.
Sarathy Gurusamy made the first announcement of all of this to perl5-porters about two weeks or so ago, and it was discussed quite to death. (Read the archives if you're interested.)
Things seem resolved for now, unless ActiveState changes things... and if they do, the perl5-porters group will have quite a lot to say about it.
But for now, things seem just hunky dory.
BIFFSTER, perl porter
Re:The scarcity is still just "approaching"
on
IP Address Shortage
·
· Score: 1
"Where is IPv6 hard to implement?" The fact that only recently have some of the core APIs been ratified by the IETF should give some sort of indication, for one.:) There's still quite a bit to do.
There are at least three independent implementations of IPv6: Sun's, INRIA, and... hell. can't remember offhand.
Re:Only 10% of the IP addresses are used?
on
IP Address Shortage
·
· Score: 1
Uh, this is bullshit, and has been so for the past coupla years.
CIDR lets you allocate along bit boundaries; the modern notation for a class of addresses is 1.2.3.4/5, where 5 is the number of bits in the bitmask. 8 is equiv to class A, 16 to B, and 24 to C.
We're not in danger of running out anytime soon, but we'll have to adopt IPv6 if we want internet toasters to be commonplace. (Then we'll get to look forward to "somebody hax0r3d my refrigerator, man!"
I hate to say this, Taco, but I had hoped for a slightly less biased description of the article. I had expected various rabid Linux types to defend it to death against each other, but not for the Linux bias to show up right at the top.
FWIW, a lot of people I know who have been using unices for quite a while have an anti-linux bent. (I know that I certainly have some negative feelings about it from back when you had to include some inane just to get PATH_MAX.)
It's about the increase in computer power, not RSA
on
RSA slightly broken
·
· Score: 3
Shamir has designed on paper a parallel machine that can crack 512 bit keys in a 'reasonable' amount of time.
All this heralds is that computing power has acheived another milestone, and that it's gotten easier/faster to factor numbers - and thus crack crypto.
Let it be pointed out, though, that the difficulty increase for each bit increase is exponential, not linear, so 768/1024/2048 bit RSA keys should be safe for quite some time...
It's a poorly-kept secret on certain routing-related IRC channels that the team in question is from Exodus.
Why egcs and gcc 2.8 split in the first place
on
egcs to become gcc
·
· Score: 1
From what I've heard (and this is all hearsay), the guy who used to be in charge of gcc 2.7 and 2.8 actually did do some work on the compiler, but he ONLY did it for his paying customers, and didn't release any of the modified source back into the FSF tree.
I've also heard assertions that the only reason gcc-2.8 was released as quickly as it was is because of the pressures of the egcs release.
Slashdot Mirror
After an extensive hymen inspection, I can guarantee you that yes, she is a virgin.
Anyone who's actually had to deal with ASN.1 or SNMP will think twice about instantly embracing another Rose protocol. (Last I heard, though, he had admitted that using ASN.1 was probably a bad idea.)
"Was Gates really a snide poser whose vision of shoddy upgrade-driven software and world domination crystallized at the age of 3?"
Considering that on the first microcomputer, he was the first person to charge for software and whine about people copying it - when he didn't even write it himself ---
Yes.
When you write a CGI in perl, you almost always use the CGI module. You don't have to worry about coding regcomp and regexec calls, you don't have to deal with manually allocating memory. You just write your code and are done with it instead of having to continually reinvent the wheel. (Personally, I believe that my time is far more valuble than the computer's.)
perl is one of the few actual examples of code reuse, FWIW.
SMP is decidedly unsexy in a lot of ways, but it's _hard_ to do right and in a sane way. One of the reasons I like BeOS is because not only does it have fine-grained SMP, but it also encourages - nay, requires - threading in all sorts of places, thus vastly boosting the benefits of having multiple processors.
When we hit the limits of Moore's law, we'll _have_ to scale to more processors - and then SMP will be horribly important to even casual users.
The altogether-too-many versions of Linux out there are already a big concern for some people; for instance, on the perl5-porters list there has been a rather large thread about telling one linux from another, due to differences in what works and what does not. So far, it's proving rather difficult indeed to sort out what all the versions are.
What would really do service to the community is for the various distributions to get their act together and work on some common method of identifying exactly what is being run. As a side effect, this would also make dealing with forks easier.
Knapsacks have been tossed by the wayside; quantum computing, if it'll work, is blasting away at factoring (if the NFS doesn't beat it into the ground all by itself); elliptic fields are being restrained by patents. What's the Next Big Thing for crypto gonna be?
I've ported perl to a new OS and I've written my own modules, so I feel I have a relatively valid viewpoint on perl's internals.
Basically, the internal datastructures are hoary. They're awful to dig through, and even worse to try and modify. Even writing external modules for use in perl can be horribly nasty because of the structures involved, the reference counting, etc.
I'd say at this point there are about 10-20 people (at most) who are competent to go and change the guts of perl. That's not a large number, especially when they don't have all that many tuits.
One of the prime motivations of rewriting perl in C++ is so that things will be modularized so that the knowledge barrier is greatly reduced. Right now, you need to know how _everything_ works before you can modify _anything_.
I'll be quite glad to get rid of things like
return sv_2mortal(newSVpv(ret,len));, thank you very much.
"Why is Linux not used for X, when Y uses Linux for Z"?
That kinda argument completely ignores the fact that X may be completely different than Z.
Incidentally, the current crop of opers may be mostly newbies, but the Real Old crowd have been around for quite a long time, and they've know precisely how and why the *BSD and Linux TCP stacks suck.
It's also the devil you know vs the devil you don't, too.
Linux SMP for quite a long time, simply put, wasn't. It wasn't symmetric, and it would block as soon as it hit the kernel. It was SMP in exactly the same way as SunOS.
FWIW, this may have changed recently. I'm sure there will be half a million zealots ready to pounce on me for it, though.
I, who work for an unnamed NSP with an OC-48 backbone (that's over 2 Gigabits/sec), have seen that one of the major limitations isn't the bandwidth, but being able to route the damn packets. Nobody really has routers yet that are too terribly stable at that high a bandwidth.
There's still a fair bit of dark fibre from the Qwest buildout, too...
IMHO, what's going to be one of the major bottlenecks in domestic networks is the local loop that goes to your house and getting local fiber from the CO to elsewhere - not the backbones.
That seems to be what ESR is saying. "We've got Linux, what else do we need? Linux is the One True Operating System!"
Personally, I'm glad that (to use his cited example) OSF/1, er, Digital Unix, er, Tru64 is still around.
Lack of diversity is always bad.
--BIFFSTER, BeOS and NetBSD wanker
In addition, if you try and simulate something like the stretching of plastic, it's an inherently linear problem. No amount of parallelism can speed that sort of thing up.
Beowulfs just don't deal well with closely-related parallel tasks... they're just fine and dandy with things like mandelbrot sets, though, where none of the iterations depend on each other.
http://www.pdl.cs.cmu.edu/RAIDframe/ is the URL for CMU's RAIDframe project.
Dunno whether it works with Linux, but it's already been integrated into NetBSD. (http://www.cs.usask.ca/staff/oster/raid.html)
1. And Lucent and Bell Labs.
:)
2. That was the eighties, my good man. Less than twenty years ago. (earlier part of this century?)
3. Buyer of Union Pacific. Railroad lines mean preestablished right of way.
MCI stands for 'Microwave Communication, Inc.'; they got their start doing point-to-point CB-like service, I believe, and then branched out into long distance.
Nobody seems to know how or why Worldcom got to where it is now.
L3 is currently doing OK, since nobody likes MFS and Worldcom much any more. (This also explains why UUNET turned into a bunch of bastards after Worldcom bought 'em... originally they were the only commercial inet presence, the only place where you didn't have to know the secret ARPA/NFS handshake to get a net connection, nor had to deal with the NFS AUP.)
Frontier is the former Rochester Telephone Company. Ain't a Baby Bell. (The data portions of Frontier were only bought like last year, too.)
(in addition, the data unit of Frontier [GlobalCenter, neé ISI/PrimeNet] only has a couple hundred employees, yet is forecasted to provide a very very large chunk of Frontier's profits.)
The Baby Bells have been trying to get back together for years; that should surprise nobody. They started doing so right after they were allowed to do so again.
However, more and more people in the data/IP industry are convinced that relatively soon, data will be regarded as a mere commodity; it won't matter who you buy from, unless you've got stupendous amounts of capacity. IP will effectively become another utility.
One of the main reasons why buying out Frontier is so attractive is that Frontier participated in the last Qwest fibre buildout, and now Frontier has excess fibre capacity; Global Crossings, on the other hand, is laying tons of trans-oceanic fibre (and its only real competitor right now is the CW unit.) Lots o' trans-ocean and lots o' trans-US fibre complement each other nicely... and trans-{Atlantic, Pacific} capacity is still sufficiently rare that it won't be considered a mere commodity in the near term.
Sarathy Gurusamy made the first announcement of all of this to perl5-porters about two weeks or so ago, and it was discussed quite to death. (Read the archives if you're interested.)
Things seem resolved for now, unless ActiveState changes things... and if they do, the perl5-porters group will have quite a lot to say about it.
But for now, things seem just hunky dory.
BIFFSTER, perl porter
There are at least three independent implementations of IPv6: Sun's, INRIA, and... hell. can't remember offhand.
If you're interested in more info on IPv6, check out Sun's site, and the IETF ipng working group info page
Uh, this is bullshit, and has been so for the past coupla years.
CIDR lets you allocate along bit boundaries; the modern notation for a class of addresses is 1.2.3.4/5, where 5 is the number of bits in the bitmask. 8 is equiv to class A, 16 to B, and 24 to C.
We're not in danger of running out anytime soon, but we'll have to adopt IPv6 if we want internet toasters to be commonplace. (Then we'll get to look forward to "somebody hax0r3d my refrigerator, man!"
BIFFSTER, network perfesshunal
I hate to say this, Taco, but I had hoped for a slightly less biased description of the article. I had expected various rabid Linux types to defend it to death against each other, but not for the Linux bias to show up right at the top.
FWIW, a lot of people I know who have been using unices for quite a while have an anti-linux bent. (I know that I certainly have some negative feelings about it from back when you had to include some inane just to get PATH_MAX.)
Shamir has designed on paper a parallel machine that can crack 512 bit keys in a 'reasonable' amount of time.
All this heralds is that computing power has acheived another milestone, and that it's gotten easier/faster to factor numbers - and thus crack crypto.
Let it be pointed out, though, that the difficulty increase for each bit increase is exponential, not linear, so 768/1024/2048 bit RSA keys should be safe for quite some time...
maybe 10 years? HHOS.
It's a poorly-kept secret on certain routing-related IRC channels that the team in question is from Exodus.
From what I've heard (and this is all hearsay), the guy who used to be in charge of gcc 2.7 and 2.8 actually did do some work on the compiler, but he ONLY did it for his paying customers, and didn't release any of the modified source back into the FSF tree.
I've also heard assertions that the only reason gcc-2.8 was released as quickly as it was is because of the pressures of the egcs release.
It's vaguely akin to PPP; all it does is say "these are blocks of data that are in FOO format". This is nothing terribly complicated or undocumented.
To rehashe an old phrase, "It's the codecs, stupid!"