Init being the grandfather of every Linux process on every Linux system (except in highly specialized applications), it better be simple, clean, fast and efficient. Something with an XML parser violates at least two if not three of those qualifications.
I don't think we need to stick with old fashioned init forever, though. I like some of the ideas brought up by this approach:
Eh... all true, but the battery part. At least, I'm making an educated guess. Here in Telecom Corridor in Richardson, TX, Nortel's facility has (or at least, at one time, had) battery capacity to run Dallas for a week, and they don't even switch calls... just make switches.
Of course, that is the PSTN, and I suppose cell providers aren't held to nearly the same standard.
Hans... I use your wonderful reiser3 filesystem. I really do support your innovations and hope that a happy medium can be met with the guys at LKML (I do understand their concerns).
When I first read about Reiser4, I knew immediately that it would blow the pants off all competition. Please don't stop innovating -- even if getting Reiser4 merged is a long battle, I think it's going to be better for computing and humanity as a whole.
True, this laptop doesn't seem to exclude laptops, but what is a company that boldly advertises 98% browser penetration doing limiting their product from even further growth, when its popularity is an essential selling point in the first place?
A. If you want bleeding edge features long before your distribution provides them to you, it's your choice to decide to be technical and build your own kernel. The other option is that you use whatever your distribution gives you. The third option is that you use Windows, and get virtually nothing for your $100+ every time an upgrade comes out.
Oh, by the way, there is strong resistence to breaking APIs in the kernel development community. Generally, it only happens with kernel-related systems like the deprecation of DEVFS - and even then, they leave it around and available and marked as on its way to the grave.
If your software breaks when you upgrade the kernel, chances are that you don't know what you're doing and should opt for the distribution's stock kernel. If it doesn't suit you, pick another distribution... choices and all.
B. This has nothing to do with the kernel, and while I'll grant that the desktop environments don't provide universal system control, this situation is gradually getting better.
C. Man pages are pretty damn informative. Some systems like KDE are lacking help in certain areas. It would be nice to have more of a universal help center, if you will - perhaps some of the free books available online could be distributed with the distribution?
I'm referring to the standard (if you could call it that) of dealing with time. I've been developing portal software for a while now, and it's becoming increasingly clear to me that the most difficult problems to conquer in computer science aren't "how do I make it secure?" or "how do I make it perform" or "how do I make it reliable", but "how do I make it follow the local standards of time perfectly as the software is deployed and used internationally?"
Leap years, leap seconds, months with uneven numbers of days, nothing is an even multiple of ten, some people follow daylight savings, some don't, hell - not everyone even uses the Gregorian calendar. I do *not* envy the developers of the libraries that have to deal with all of this nonsense, but I'm damn glad they've done so in order for the rest of us not to have to deal with it.
If you'll refer to one of my other replies in this thread, I link DJB's notes about UTC and TAI. UTC is broken, and moreover, the POSIX rules for operating systems and time are totally broken:
============= The main obstacle is POSIX. POSIX is a ``standard'' designed by a vendor consortium several years ago to eliminate progress and protect the installed base. The behavior of the broken localtime() libraries was documented and turned into a POSIX requirement.
Fortunately, the POSIX rules are so outrageously dumb---for example, they require that 2100 be a leap year, contradicting the Gregorian calendar---that no self-respecting engineer would obey them. =============
Well, it's certainly a) remote, because you don't have to have a local user account on the system in order to exploit it. I suppose b) depends on whether or not root loads the file in question.
Sorry, the original post just seemed like a really silly attack on DJB. People make them all the time because the only other legitimate grounds on which to attack him is his personality.
And if the legislators ruled pi to be exactly 3, I'm sure Just Some Guy would immediately switch to software packages that recognized the rule. It wouldn't be a "benefit" that the competition still saw pi as 3.1415.
You really need to clarify 2-B. If someone merely loads a file, rather than deliberately executing it, and the result is that code is run (as point 2-C implies), then it is DEFINITELY a security hole.
Think of it like this... someone e-mails you a JPEG. You view it, and now you're a spambot.
So DJB's tools perfectly implementing the standard isn't a benefit because other people decided to do it wrong? In what fucking world does that make sense? I don't have any problems - I spent about an hour setting the whole cluster up to sync time, and it works flawlessly, never requiring maintenence or consideration or monitoring.
As for ntpd relying on the kernel, clockspeed doesn't, so I don't even have to worry about it.
You suggested I consider switching to OpenNTPD, but you've provided absolutely zero good reasons to do so.
Like him or not, he's the only software author I'm familiar with that has written a package as large as qmail that gets distributed and used all over the Internet (even Hotmail used it for some point, and kept using it for a while after Microsoft bought them)... and, what's this? No one's ever found a security hole in any of his packages?
People hate him for his attitude... but frankly, I find it downright hilarious, because not once have I heard a brutal comment from DJB that wasn't based 100% in fact.
And I sleep well at night knowing my cluster is not going to get hacked.
Oh, and on the subject of hitting Stratum-1 servers... I'm not too worried about it. An NTP client may be configured to hit them every hour, or some such nonsense, but as I stated in my post, every time I hit NIST I double the amount of time I wait before I hit them again.
We had to move our cluster onto a new UPS about a month ago, so I just have a 33 day uptime on my local Stratum-2, but as you can see:
---------------------- Sleeping 1228800 seconds... before: 2005-08-14 23:36:57.248578000000000000 after: 2005-08-14 23:36:57.218957999778524040 before: 2005-08-14 23:36:57.268270000000000000 after: 2005-08-14 23:36:57.268270000333328132 ---------------------- Sleeping 2457600 seconds...... it will be 28 and a half days before my cluster touches NIST again. After that, it will be 56 days... etc. If you notice from the log output, the previous interval was 14 days, and in those 14 days we only drifted 3 hundredths of a second.
I doubt any Stratum-1 guys want to punch me for syncing at the intervals I do...
The fact that clockspeed hasn't been updated since October 1998 makes absolutely no difference to me. DJB got the design right -- it accounts for leap seconds, it syncs the clock, and if I lose my internet connection for a month I'm still within a second of the atomic clock.
NTP is based on UTC and doesn't handle leap seconds as gracefully as TAI. Further discussion:
Includes an SNTP client, TAI client, TAI server, and clock correction program. It's very simple and it keeps my entire cluster to within a very small amount of drift of the atomic clock, with the sync interval doubling at every sync.
I use SNTP to get Stratum-1 time from NIST, then TAI to serve Stratum-2 time to my cluster.
Not really. Basically, I have to expand on my point a bit to explain.
I think that the reason Java has been so successful is what amounts to good marketing on Sun's part. They got the buzzword out, but more importantly, they handed it over to universities as a tool to teach students about programming.
So rather than ending up with graduates that understand the operating system and programming, you end up with students that just understand programming, and Java programming at that. It's not a problem for them, because they'll probably find a nice job writing code somewhere.
But the problem is they're poorly trained - they never got more than a passing glance at the container in which their programs run. They are either taught or leave school thinking that they shouldn't have to worry about what's outside their container.
Hence, we have bad code. If Grandma wants to write herself some code to organize her recipes, fine. I just don't want Grandma to get hired to develop a large web portal, because despite whatever reality the hand-holder languages are trying to create, a web portal is a complicated thing. She'd then be trying to build a car out of legos, and all she understands is legos. Thankfully, there are still people building cars out of metal and lots of custom parts that know all about engines and performance and fuel efficiency and concrete.
Actually, you'd dereference the array by saying @{$_[0]}, or you could do it like:
my ($var1, $var2, $var3) = @_;
or
my $var1 = shift; my $var2 = shift; my $var3 = shift;
then
my @ar = @$var2;
The semantics are pretty similar to C... by default, you pass by value (remember, a string in C like "foo" ends up providing you a pointer to a 4-byte null terminated foo in your data section).
I see absolutely nothing that doesn't make sense / isn't consistent. By contrast, the semantics make it really easy to build big structures:
That's really easy. You can make the list like [1,2,3] which returns a list reference, or you can take the list you already made, @list, and pass by reference: \@list. I don't see what's hard about that. The syntax is different than C, but then again, every language varies.
I mention Java once in my post... do you have your reading glasses on?
The reason I mention Java here is because it is the epitome of languages that are very specifically designed with the intent of forcing someone's idea of 'good design'. Well guess what... what's good design to you is shitty design to me.
Of course, you could write bad Perl code... and so could I. But then again, with a language like Perl, we have the possibility to write any kind of code we want, because as Larry Wall so eloquently put it:
"This is Perl, not fascism."
What makes Perl a power tool in my mind? Did you even read my post? AUTOLOAD, for one. Or how about regular expressions?
I'd be happy to list off some more:
* Lack of strong typing * www.CPAN.org - nuff said * mod_perl and its near-infinite flexibility * Very flexible syntax * Dynamic on-the-fly runtime inheritence (and with a little help from AUTOLOAD, this can be Dynamic on-the-fly *per-instance* inheritence) * Lambda closures
There's a reason they call Perl the swiss army chainsaw of UNIX programming.
KDE comes close to the ease of use of the windows GUI.
Are you using the same KDE and Windows I am? KDE blows the pants off Windows in terms of ease of use. Then again, I probably fall into the 'power-user' category and lean on features like KIO pretty heavily...
Get started improving Ruby then, because Perl 6's object model that you call a cruft sandwich with a side-order of bloat is about to kick *everyone's* ass in OO flexibility. I'll speak to you again when you're inheriting my Perl 6 objects in your Ruby code, thanks to Parrot.
Uh, you said the "linuxy model"... didn't you mean to say BSD? You know... OpenBSD, NetBSD, FreeBSD, DragonflyBSD?
If you knew anything about Linux kernel development, you'd know that it works about like this:
1. One or more members of the community think Linux needs x. 2. Issue gets bitched about on LKML. Baby jesus cries. 3. One or more patches that implement x are developed. 4. Issue gets bitched about on LKML. Linus watches quietly. 5. Eventually, the patch authors even merge the best of their work, or one patch is clearly better than the other (skip to #6). Often, this is when Linus wakes up and makes his executive decision. 6. Issue gets bitched about on LKML. Patch gets merged into a patchset. 7. Adventurous users tinker with their new toy. 8. Patch gets merged into mainline.
The model works well enough that Linux doesn't get forked.
In fact, Reiser4 is trying to dock against mainline right now, and it hasn't happened yet because Hans implemented his own layer underneath the VFS, and kernel developers *hate* competing methods.
I still have yet to run into unreadable perl code that wasn't purpousely obfuscated. In the past, I did see a lot of code that didn't make sense, but that is because Perl broke the traditional rules and let you do whatever you want, and I wasn't as talented or experienced as the Perl developer whose code I was reading.
Calling Perl an outdated development habit is one hundred percent your opinion, and has no basis in fact whatsoever. I still use Perl because it is still very modern. Between a very flexible syntax, tons of features (many of which were unique or close to being unique until your so-called 'modern' languages saw fit to borrow them from Perl), and CPAN, I have absolutely no reason to stop.
I haven't used python much... but I will say that claiming "large Web frameworks" is something Perl lacks is total bullshit (look at Amazon.com, one of the most advanced shops out there... they run on HTML::Mason and mod_perl). Large web frameworks is actually one of the areas where Perl shines brightest, and as far as I'm convinced, no competing language can beat it in enough ways at once to even begin to take its title.
If what you say about Python's syntax is true, then I'm sure that it's better for n00bs. But make no mistake - no syntax is powerful enough to stop n00bs from writing shitty code, and when your language is such that it is dominated with this class of programmer, you're going to end up with crap code, again and again and again and again and again.
Moreover, there are some modern "technologies" like Java that I will never code in, because I demand flexibility and performance out of my apps. It's not at all about being manly -- it's about not writing shitty software.
There are situations where it's irresponsible to use any language. Perhaps that's why we don't have a mod_x86asm? I certainly never claimed to be implementing kernels in Perl.
I'm thrilled (rolleyes) that Sun wants to "embrace" the Open Source community again with a "free" technology.
It's true that Solaris 10 has a few handy features Linux may be currently missing.
But Linux has *far* more developers, and will continue to until Solaris 10 becomes portable to over 20 architectures and begins to include tons of hardware support.
And while they're working on closing that gap, Linux will tie up any loose ends. When Sun surfaces from their driver-writing festival to get their bearings, they're going to be eating Linux's dust.
Don't get me wrong... I'm not a Solaris hater per se - in fact, I think it's the closest thing Linux has to UNIX competition at this point. Calling it a "Linux Killer", though, is damn foolish.
Besides -- how are they going to manage to get a thriving community of brilliant open source developers to work on Solaris when it's looud and clear just what Sun thinks of real open source?
To some degree, that's probably true. And certainly, the trend of abandoning quality in favor of time to market is deeply rooted in the commercial software enterprise (which is why you end up with so many disasters in that arena).
Speaking specifically of perl, though, it's very possible to rapidly prototype and deploy applications if you know what you're doing. Last year, a colleague and I picked up HTML::Mason and inside of two weeks wrote a robust Voice-over-IP portal that far surpassed the available competition in terms of functionality. It wasn't quite production quality when it hit the tradeshow floor, though it was damn close, which is very respectable given the deadlines and the fact that it was the first time either of us had ever done any kind of serious work with HTML::Mason or Asterisk.
To continue on the story a bit, the 'competing' portals included with many high-end commercial VoIP PBXs seem almost exclusively implemented in Java, and it hurts -- even over our office LAN, their portals still feel very slow (and they're running on very respectable Sun hardware that otherwise spends its life idle). Our portal, on the other hand, responded to page clicks so fast you would think it was a dual xeon serving static pages off a 7-spindle RAID array.
The bottom line is that quality only seems to matter to smart people... the rest of the world will happily eat shit if you put it on a bun, and even after the health problems, they'll come right back for more.
I've been asking myself a lot lately why so many people seem to hate Perl. After spending the last few years going from comfortably familiar to extremely familiar with the syntax and features, I think I have the answer.
When you really get down into the guts of perl, you get to do all kinds of crazy nifty things with XS, AUTOLOAD, regular expressions, etc. Perl's syntax is such that once you're intimately familiar with it, you can be either very expressive or very concise.
A lot of code ends up going the concise route because when you know what you're doing, it's easier to write (less keystrokes). Then perl newbies / passer-byers take a look at it, don't understand it, and freak out and say that perl is crap.
Then perhaps they're threatened because there's a huge community of smart perl programmers that manage to upstage them constantly.
To zoom out on the issue a bit, I'm really sick and tired of this current movement in computer science where so many think that programming should be made into some kind of simple task that anyone can do. Hence you end up with languages like Java that hold your hand really really tight and refuse to let go. Is Grandma writing software really a good thing? Or should we save it for the people who at least have a passing familiarity with computers & networks; hell, someone who might even know a little bit about the basic mechanisms in a typical UNIX kernel?
(I refuse to drive a car built out of legos... I don't care that the technology enabled your three year old to do it... it's a high speed highway, damnit, and my life is on the line!)
Make no mistake - there's still an undergound of brilliant developers that understand their systems inside out and produce amazing, high performance code. Many of them are in the open source community. And we refuse to let go of our power tools. You may use whatever language you like, but expect a well-deserved ass kicking if you get in our face and try to tell us you know better.
Slashdot Mirror
Init being the grandfather of every Linux process on every Linux system (except in highly specialized applications), it better be simple, clean, fast and efficient. Something with an XML parser violates at least two if not three of those qualifications.
I don't think we need to stick with old fashioned init forever, though. I like some of the ideas brought up by this approach:
http://smarden.org/runit/
which is based on Daniel Bernstein's daemontools.
Eh... all true, but the battery part. At least, I'm making an educated guess. Here in Telecom Corridor in Richardson, TX, Nortel's facility has (or at least, at one time, had) battery capacity to run Dallas for a week, and they don't even switch calls... just make switches.
Of course, that is the PSTN, and I suppose cell providers aren't held to nearly the same standard.
Hans... I use your wonderful reiser3 filesystem. I really do support your innovations and hope that a happy medium can be met with the guys at LKML (I do understand their concerns).
When I first read about Reiser4, I knew immediately that it would blow the pants off all competition. Please don't stop innovating -- even if getting Reiser4 merged is a long battle, I think it's going to be better for computing and humanity as a whole.
True, this laptop doesn't seem to exclude laptops, but what is a company that boldly advertises 98% browser penetration doing limiting their product from even further growth, when its popularity is an essential selling point in the first place?
A. If you want bleeding edge features long before your distribution provides them to you, it's your choice to decide to be technical and build your own kernel. The other option is that you use whatever your distribution gives you. The third option is that you use Windows, and get virtually nothing for your $100+ every time an upgrade comes out.
Oh, by the way, there is strong resistence to breaking APIs in the kernel development community. Generally, it only happens with kernel-related systems like the deprecation of DEVFS - and even then, they leave it around and available and marked as on its way to the grave.
If your software breaks when you upgrade the kernel, chances are that you don't know what you're doing and should opt for the distribution's stock kernel. If it doesn't suit you, pick another distribution... choices and all.
B. This has nothing to do with the kernel, and while I'll grant that the desktop environments don't provide universal system control, this situation is gradually getting better.
C. Man pages are pretty damn informative. Some systems like KDE are lacking help in certain areas. It would be nice to have more of a universal help center, if you will - perhaps some of the free books available online could be distributed with the distribution?
I'm referring to the standard (if you could call it that) of dealing with time. I've been developing portal software for a while now, and it's becoming increasingly clear to me that the most difficult problems to conquer in computer science aren't "how do I make it secure?" or "how do I make it perform" or "how do I make it reliable", but "how do I make it follow the local standards of time perfectly as the software is deployed and used internationally?"
Leap years, leap seconds, months with uneven numbers of days, nothing is an even multiple of ten, some people follow daylight savings, some don't, hell - not everyone even uses the Gregorian calendar. I do *not* envy the developers of the libraries that have to deal with all of this nonsense, but I'm damn glad they've done so in order for the rest of us not to have to deal with it.
If you'll refer to one of my other replies in this thread, I link DJB's notes about UTC and TAI. UTC is broken, and moreover, the POSIX rules for operating systems and time are totally broken:
=============
The main obstacle is POSIX. POSIX is a ``standard'' designed by a vendor consortium several years ago to eliminate progress and protect the installed base. The behavior of the broken localtime() libraries was documented and turned into a POSIX requirement.
Fortunately, the POSIX rules are so outrageously dumb---for example, they require that 2100 be a leap year, contradicting the Gregorian calendar---that no self-respecting engineer would obey them.
=============
Well, it's certainly a) remote, because you don't have to have a local user account on the system in order to exploit it. I suppose b) depends on whether or not root loads the file in question.
Sorry, the original post just seemed like a really silly attack on DJB. People make them all the time because the only other legitimate grounds on which to attack him is his personality.
And if the legislators ruled pi to be exactly 3, I'm sure Just Some Guy would immediately switch to software packages that recognized the rule. It wouldn't be a "benefit" that the competition still saw pi as 3.1415.
You really need to clarify 2-B. If someone merely loads a file, rather than deliberately executing it, and the result is that code is run (as point 2-C implies), then it is DEFINITELY a security hole.
Think of it like this... someone e-mails you a JPEG. You view it, and now you're a spambot.
So DJB's tools perfectly implementing the standard isn't a benefit because other people decided to do it wrong? In what fucking world does that make sense? I don't have any problems - I spent about an hour setting the whole cluster up to sync time, and it works flawlessly, never requiring maintenence or consideration or monitoring.
As for ntpd relying on the kernel, clockspeed doesn't, so I don't even have to worry about it.
You suggested I consider switching to OpenNTPD, but you've provided absolutely zero good reasons to do so.
Like him or not, he's the only software author I'm familiar with that has written a package as large as qmail that gets distributed and used all over the Internet (even Hotmail used it for some point, and kept using it for a while after Microsoft bought them)... and, what's this? No one's ever found a security hole in any of his packages?
People hate him for his attitude... but frankly, I find it downright hilarious, because not once have I heard a brutal comment from DJB that wasn't based 100% in fact.
And I sleep well at night knowing my cluster is not going to get hacked.
Oh, and on the subject of hitting Stratum-1 servers... I'm not too worried about it. An NTP client may be configured to hit them every hour, or some such nonsense, but as I stated in my post, every time I hit NIST I double the amount of time I wait before I hit them again.
... ... ... it will be 28 and a half days before my cluster touches NIST again. After that, it will be 56 days... etc. If you notice from the log output, the previous interval was 14 days, and in those 14 days we only drifted 3 hundredths of a second.
We had to move our cluster onto a new UPS about a month ago, so I just have a 33 day uptime on my local Stratum-2, but as you can see:
----------------------
Sleeping 1228800 seconds
before: 2005-08-14 23:36:57.248578000000000000
after: 2005-08-14 23:36:57.218957999778524040
before: 2005-08-14 23:36:57.268270000000000000
after: 2005-08-14 23:36:57.268270000333328132
----------------------
Sleeping 2457600 seconds
I doubt any Stratum-1 guys want to punch me for syncing at the intervals I do...
The fact that clockspeed hasn't been updated since October 1998 makes absolutely no difference to me. DJB got the design right -- it accounts for leap seconds, it syncs the clock, and if I lose my internet connection for a month I'm still within a second of the atomic clock.
NTP is based on UTC and doesn't handle leap seconds as gracefully as TAI. Further discussion:
http://cr.yp.to/proto/utctai.html
http://cr.yp.to/proto/taiclock.txt
DJB's clockspeed package:
http://cr.yp.to/clockspeed.html
Includes an SNTP client, TAI client, TAI server, and clock correction program. It's very simple and it keeps my entire cluster to within a very small amount of drift of the atomic clock, with the sync interval doubling at every sync.
I use SNTP to get Stratum-1 time from NIST, then TAI to serve Stratum-2 time to my cluster.
Not really. Basically, I have to expand on my point a bit to explain.
I think that the reason Java has been so successful is what amounts to good marketing on Sun's part. They got the buzzword out, but more importantly, they handed it over to universities as a tool to teach students about programming.
So rather than ending up with graduates that understand the operating system and programming, you end up with students that just understand programming, and Java programming at that. It's not a problem for them, because they'll probably find a nice job writing code somewhere.
But the problem is they're poorly trained - they never got more than a passing glance at the container in which their programs run. They are either taught or leave school thinking that they shouldn't have to worry about what's outside their container.
Hence, we have bad code. If Grandma wants to write herself some code to organize her recipes, fine. I just don't want Grandma to get hired to develop a large web portal, because despite whatever reality the hand-holder languages are trying to create, a web portal is a complicated thing. She'd then be trying to build a car out of legos, and all she understands is legos. Thankfully, there are still people building cars out of metal and lots of custom parts that know all about engines and performance and fuel efficiency and concrete.
Actually, you'd dereference the array by saying @{$_[0]}, or you could do it like:
my ($var1, $var2, $var3) = @_;
or
my $var1 = shift;
my $var2 = shift;
my $var3 = shift;
then
my @ar = @$var2;
The semantics are pretty similar to C... by default, you pass by value (remember, a string in C like "foo" ends up providing you a pointer to a 4-byte null terminated foo in your data section).
I see absolutely nothing that doesn't make sense / isn't consistent. By contrast, the semantics make it really easy to build big structures:
$hashref->{key1}->{key1a}->{key1aa}->[0]
That's really easy. You can make the list like [1,2,3] which returns a list reference, or you can take the list you already made, @list, and pass by reference: \@list. I don't see what's hard about that. The syntax is different than C, but then again, every language varies.
I mention Java once in my post... do you have your reading glasses on?
The reason I mention Java here is because it is the epitome of languages that are very specifically designed with the intent of forcing someone's idea of 'good design'. Well guess what... what's good design to you is shitty design to me.
Of course, you could write bad Perl code... and so could I. But then again, with a language like Perl, we have the possibility to write any kind of code we want, because as Larry Wall so eloquently put it:
"This is Perl, not fascism."
What makes Perl a power tool in my mind? Did you even read my post? AUTOLOAD, for one. Or how about regular expressions?
I'd be happy to list off some more:
* Lack of strong typing
* www.CPAN.org - nuff said
* mod_perl and its near-infinite flexibility
* Very flexible syntax
* Dynamic on-the-fly runtime inheritence (and with a little help from AUTOLOAD, this can be Dynamic on-the-fly *per-instance* inheritence)
* Lambda closures
There's a reason they call Perl the swiss army chainsaw of UNIX programming.
KDE comes close to the ease of use of the windows GUI.
Are you using the same KDE and Windows I am? KDE blows the pants off Windows in terms of ease of use. Then again, I probably fall into the 'power-user' category and lean on features like KIO pretty heavily...
Get started improving Ruby then, because Perl 6's object model that you call a cruft sandwich with a side-order of bloat is about to kick *everyone's* ass in OO flexibility. I'll speak to you again when you're inheriting my Perl 6 objects in your Ruby code, thanks to Parrot.
Uh, you said the "linuxy model" ... didn't you mean to say BSD? You know... OpenBSD, NetBSD, FreeBSD, DragonflyBSD?
If you knew anything about Linux kernel development, you'd know that it works about like this:
1. One or more members of the community think Linux needs x.
2. Issue gets bitched about on LKML. Baby jesus cries.
3. One or more patches that implement x are developed.
4. Issue gets bitched about on LKML. Linus watches quietly.
5. Eventually, the patch authors even merge the best of their work, or one patch is clearly better than the other (skip to #6). Often, this is when Linus wakes up and makes his executive decision.
6. Issue gets bitched about on LKML. Patch gets merged into a patchset.
7. Adventurous users tinker with their new toy.
8. Patch gets merged into mainline.
The model works well enough that Linux doesn't get forked.
In fact, Reiser4 is trying to dock against mainline right now, and it hasn't happened yet because Hans implemented his own layer underneath the VFS, and kernel developers *hate* competing methods.
I still have yet to run into unreadable perl code that wasn't purpousely obfuscated. In the past, I did see a lot of code that didn't make sense, but that is because Perl broke the traditional rules and let you do whatever you want, and I wasn't as talented or experienced as the Perl developer whose code I was reading.
Calling Perl an outdated development habit is one hundred percent your opinion, and has no basis in fact whatsoever. I still use Perl because it is still very modern. Between a very flexible syntax, tons of features (many of which were unique or close to being unique until your so-called 'modern' languages saw fit to borrow them from Perl), and CPAN, I have absolutely no reason to stop.
I haven't used python much... but I will say that claiming "large Web frameworks" is something Perl lacks is total bullshit (look at Amazon.com, one of the most advanced shops out there... they run on HTML::Mason and mod_perl). Large web frameworks is actually one of the areas where Perl shines brightest, and as far as I'm convinced, no competing language can beat it in enough ways at once to even begin to take its title.
If what you say about Python's syntax is true, then I'm sure that it's better for n00bs. But make no mistake - no syntax is powerful enough to stop n00bs from writing shitty code, and when your language is such that it is dominated with this class of programmer, you're going to end up with crap code, again and again and again and again and again.
Moreover, there are some modern "technologies" like Java that I will never code in, because I demand flexibility and performance out of my apps. It's not at all about being manly -- it's about not writing shitty software.
There are situations where it's irresponsible to use any language. Perhaps that's why we don't have a mod_x86asm? I certainly never claimed to be implementing kernels in Perl.
I'm thrilled (rolleyes) that Sun wants to "embrace" the Open Source community again with a "free" technology.
It's true that Solaris 10 has a few handy features Linux may be currently missing.
But Linux has *far* more developers, and will continue to until Solaris 10 becomes portable to over 20 architectures and begins to include tons of hardware support.
And while they're working on closing that gap, Linux will tie up any loose ends. When Sun surfaces from their driver-writing festival to get their bearings, they're going to be eating Linux's dust.
Don't get me wrong... I'm not a Solaris hater per se - in fact, I think it's the closest thing Linux has to UNIX competition at this point. Calling it a "Linux Killer", though, is damn foolish.
Besides -- how are they going to manage to get a thriving community of brilliant open source developers to work on Solaris when it's looud and clear just what Sun thinks of real open source?
To some degree, that's probably true. And certainly, the trend of abandoning quality in favor of time to market is deeply rooted in the commercial software enterprise (which is why you end up with so many disasters in that arena).
Speaking specifically of perl, though, it's very possible to rapidly prototype and deploy applications if you know what you're doing. Last year, a colleague and I picked up HTML::Mason and inside of two weeks wrote a robust Voice-over-IP portal that far surpassed the available competition in terms of functionality. It wasn't quite production quality when it hit the tradeshow floor, though it was damn close, which is very respectable given the deadlines and the fact that it was the first time either of us had ever done any kind of serious work with HTML::Mason or Asterisk.
To continue on the story a bit, the 'competing' portals included with many high-end commercial VoIP PBXs seem almost exclusively implemented in Java, and it hurts -- even over our office LAN, their portals still feel very slow (and they're running on very respectable Sun hardware that otherwise spends its life idle). Our portal, on the other hand, responded to page clicks so fast you would think it was a dual xeon serving static pages off a 7-spindle RAID array.
The bottom line is that quality only seems to matter to smart people... the rest of the world will happily eat shit if you put it on a bun, and even after the health problems, they'll come right back for more.
I've been asking myself a lot lately why so many people seem to hate Perl. After spending the last few years going from comfortably familiar to extremely familiar with the syntax and features, I think I have the answer.
When you really get down into the guts of perl, you get to do all kinds of crazy nifty things with XS, AUTOLOAD, regular expressions, etc. Perl's syntax is such that once you're intimately familiar with it, you can be either very expressive or very concise.
A lot of code ends up going the concise route because when you know what you're doing, it's easier to write (less keystrokes). Then perl newbies / passer-byers take a look at it, don't understand it, and freak out and say that perl is crap.
Then perhaps they're threatened because there's a huge community of smart perl programmers that manage to upstage them constantly.
To zoom out on the issue a bit, I'm really sick and tired of this current movement in computer science where so many think that programming should be made into some kind of simple task that anyone can do. Hence you end up with languages like Java that hold your hand really really tight and refuse to let go. Is Grandma writing software really a good thing? Or should we save it for the people who at least have a passing familiarity with computers & networks; hell, someone who might even know a little bit about the basic mechanisms in a typical UNIX kernel?
(I refuse to drive a car built out of legos... I don't care that the technology enabled your three year old to do it... it's a high speed highway, damnit, and my life is on the line!)
Make no mistake - there's still an undergound of brilliant developers that understand their systems inside out and produce amazing, high performance code. Many of them are in the open source community. And we refuse to let go of our power tools. You may use whatever language you like, but expect a well-deserved ass kicking if you get in our face and try to tell us you know better.