Slashdot Mirror

About global variables: well, *real* novices don't know about subroutines, anyhow! ;)

I'm sure Perl has modules geared towards language processing, and I might even look it up; but for some reason, I have a desire to implement that part myself at a lower level, as well. Maybe by learning lex better, for starters...

Another site I found that looks pretty useful for Perl info is "perldoc.com"; it looks like most of the 'new, bolted-on' features of perl started in 1993, with the development of Perl 5; they're debating about what'll go into Perl 6 now...

...And I like the mythology reference. :)
---
pb Reply or e-mail; don't vaguely moderate.

I haven't used exceptions; so far, it looks like a way to check for error codes after something has already screwed up, and I'm not convinced its a good approach yet. However, I'm also starting to learn Java, so I'm sure I'll see how they use it.

I'm not even a huge Perl advocate, but I learned it for my job and thought it was pretty handy, especially for getting the job done quickly. I revamped a script to add accounts, and integrated a domain registration system with a credit card processing system; (the first was written in Perl; the second had a Perl API interface, and I found a credit-card module for another processing system that was also already in Perl...) I'm sure there's a lot of Python code out there too, but Perl is quickly becoming a favored language for CGI interactions. On the server side, there's also PHP and Java now, and PHP also looks a lot like Perl (and probably like Python too...).

I haven't played with Perl's Object system much, but I know it has one, so I can't really compare those two; it seems to work pretty well, though.

I'd argue over the syntax being more familiar to CS types, because I consider myself to be one, and I never learned awk, either, but Python syntax doesn't look incomprehensible. But this is such a matter of taste that I'd fear to mention it, because syntax flamewars really are useless.

I think "my" is a feature, I just wish it was the default. However, Perl defaults to something simple for the novice--making variables global. Many other languages default to something similar. However, there's nothing wrong with telling a programmer to declare all (or almost all) of their variables with 'my' as a good programming practice; if they really want dynamic scope, they can use 'local', but they probably don't. I don't mind when Perl gives me a few options; actually, I like it. If I'm feeling Scheme-ish, I can use lexical scope and recursion; if I'm just quickly hacking, I can use global variables, iteration, and implicit looping (command-line switches for text filters...) and stuff. I'm sure you could hack a version of 'use strict' that enforces whatever particular programming paradigm you like better, (it favors 'my' variables in modules, incidentally) but that's a decision that I'd rather leave up to the programmer.

Perl can also compile to an intermediate byte-code form, and generally a well-written Perl program performs at a minimum as fast as your average interpreted language, and in a best case faster than C, (using nifty built-in data types and whatnot) but generally somewhere in between.

Incidentally, writing a simple C program is generally fastest, although there are a few instances where the C++/STL solution is faster. (the STL is incredibly well implemented on g++) Most interpreted procedural languages are generally about 10x slower, and most shell scripting languages are generally 10x slower than that, (100x slower than C!) but for some problems, certain interpreters pull ahead of the pack.

For instance, Python (and many functional languages) have a built-in arbitrary-precision number capability that is pretty well implemented. Perl has a module for this, but it is pretty slow; I think there's a faster one available, too. I know there are libraries to do this in C (like gmp), but they aren't necessarily there by default.

Not only is Perl extremely portable, and indeed already ported just about everywhere, but since it can generate code for itself in Bytecode and C, it's even more portable and flexible. (assuming you can compile the resultant C code...)

AFAIK, both Perl and Python use reference-counting garbage collectors; I know that there are a lot of great features slated for the *next* versions of Perl, and one of them on the drawing board is a real garbage collector; but that's probably on the TODO for the Python people as well. :)

Actually, I think the two are pretty even. Although I think Perl supports traditional functional programming better, I doubt many people would do it in Perl. (although I might try my hand at either writing a Scheme interpreter in Perl, or yet another Nth generation language; I'm silently debating to myself over syntax-parsing and data-type handling at the moment.) I agree that Python has a sparse looking syntax, but I'm not convinced that I like it yet, and therefore that's a style issue. Also, Perl is great for speeding up old shell scripts and migrating from sed or awk, and provides wonderful modules for CGI and database integration. I suppose Python has its own modules for this, but I like writing web pages in Perl better than writing them in HTML, and that's saying something, since I'd never use an "HTML Editor", either.

On the other hand, I think Python might make a good stepping-stone for people coming from a more academic, functional-programming background, and ultimately want to learn, say, Java. Although Perl has closer syntax, Python has some of the comforts of home, and has built-in exception handling. But ultimately, I guess it depends on what you want in a language, in the first place.
---
pb Reply or e-mail; don't vaguely moderate.

Well, I'm going to check it out because the AVI plug-in claims to already play MPEG4-encoded files (.ASF).

(But don't post too loudly, or the download site will get slashdotted! ;)
---
pb Reply or e-mail; don't vaguely moderate.

Hmm. Whether you like Quicktime or not, I'm not sure if this will fly.

Can you make a module for a proprietary program under the GPL? Wouldn't it have to be LGPL'ed?

Someone enlighten me on this one, 'cause I'm not positive about it.
---
pb Reply or e-mail; don't vaguely moderate.

If there's one thing I miss on Linux, it's good Codec support. I'd love to see a good, high-quality encoder come out of this, much like the LAME project did for mp3's.

...and if an open one is written, I'm sure all the other free OS people will be very happy too...
---
pb Reply or e-mail; don't vaguely moderate.

Well, it was just a simple example of how to add syntax, really, but notice how cleanly it integrates into the rest of Perl; that's the impressive part.

I tend to use "my", and parse "@_", but like I said before, you can always pass a single reference as an argument, or use a reference to a hash essentially to pass around a namespace...

Perl does ask for more explicit information about everything, yes, and a friend of mine told me that there is a pretty fast third-party Perl compiler that his company uses internally, (so of course I haven't gotten to see it myself... :[ ) and maybe one day the Perl->C translator will get that good. I haven't really used Tcl either, but it looks like it has its own unique, interesting syntax, like every other glue language these days...

Also, the PerlC stuff makes it really easy to just import and use headers and libraries like native Perl stuff, I think that's the real feature there. They do make it harder to implement C extensions, but again most of the time you probably don't need to do that, and CPAN has more than enough modules for doing everything else...
---
pb Reply or e-mail; don't vaguely moderate.

The interesting thing about & is that you can generate new syntax with it:

sub try (&@) {
my($try,$catch) = @_;
eval { &$try };
if ($@) {
local $_ = $@;
&$catch;
}
}
sub catch (&) { $_[0] }

try {
die "phooey";
} catch {
/phooey/ and print "unphooey\n";
};

That prints "unphooey". (Yes, there are still unresolved issues having to do with the visibility of @_. I'm ignoring that question for the moment. (But note that if we make @_ lexically scoped, those anonymous subroutines can act like closures...
(Gee, is this sounding a little Lispish? (Never mind.))))

Perl supports lexical scope through the use of 'my' variables, and closures through the use of references to anonymous subroutines. Therefore, you can basically write Scheme-style function-returning functions, if you want to...

Its built-in data-types consist of scalars, (which can be numbers, strings, some weird stuff, and references to other stuff... :) arrays and hashes, and this can be extended through modules, objects, or essentially providing other methods for the built-in data types. (for example, you can tie a hash to a database instead of using the database calls)

Perl doesn't have a built-in exception system, but it has prototypes, which basically lets you add syntax to the language; there's a simple example (in Programming In Perl, I think) that adds a try..catch construct to the language. :)

Objects were definitely added to Perl later; I don't use them very often, and indeed could write it all myself if I had to, (lexical scoping, closures, and tools for adding syntax, right? :) but, that having been said, it also doesn't look that ugly to me, (maybe ugly is in the eye of the beholder...) and I've worked with many object-based Perl modules just fine. Actually, usually they provide *both* interfaces, and support operator overloading and type-conversion as well.

Perl does have features for integrating with other languages, and I've compiled Perl programs into C before as well, (it's generally about 30-40% faster, nothing impressive--it compiles too much of the Perl runtime into it still) and it also has a bytecode format, if people want that.

Python might follow the 'principle of least surprise' for someone unfamiliar with programming languages, but Perl looks like a few popular (also ugly?) languages, and might be better for migrating old Unix hackers as needed. :)

I don't think it'd be too hard to make a pre-processor to do either behavior; actually, I think a language with a flexible front-end tokenizer would be somewhat interesting, provided people always included their modifications in the source, or the program could always convert their code back to "standard" code. :)

Yeah, the built-in types vs. objects is always interesting; for the record, I don't like how Perl does it. References can be somewhat clumsy, and I'd rather be able to determine which type a scalar *really* is than automatically convert it. At least references know what type they are, though.

Obviously a lot of people don't like Perl syntax, and here are some of my thoughts on the matter:

I didn't like having to use $, @, and % all the time, either; it makes it look like a strict BASIC variant where you'd have to specify $, #, or % for different types. However, once I learned it, I found out two things: Most of the time, you just stick $ in front of a variable, because generally you're just working with scalars. Also, it forces you to think about which types you're using, and that can often be a good thing.

The braces and semicolons are pretty familiar for anyone who has used C and Pascal. With the way I write my code, I don't think I'd want whitespace as a seperator; I'll just use a pretty-printer for that. The other alternative, parentheses... well, a lot of people don't like that either.

There are lots of default arguments to functions in Perl, and they're pretty straightforward, and well-documented. But, that having been said, you don't have to use them. Pass as many useless parameters as you like, it's perfectly legal. But I don't find the way Perl handles default values that confusing, and if I don't know, well, I could always pass a variable to a function like usual, like I probably would if I didn't know that Perl had default values...

Other than that, I think that's about it; the two languages have a lot of similar features. From what I've seen here, it looks like Python has some interesting and powerful ones, but Perl generally has more flexibility, and maybe more of a learning curve, too. (don't ask me, it only took me a couple of days to learn, and a couple of weeks to get pretty comfortable with it...)
---
pb Reply or e-mail; don't vaguely moderate.

*sigh* More nitpicking. Feel free to read my posts without actually understanding them.

Or... start debating programming language freatures. Not syntax; not grammar; not debating.

Is that so hard to understand?

If you like, you can read the *entire* series of posts yourself, and make your own conclusions, instead of picking one of them apart, out of context.

For instance:

Whether or not this is true (and I don't suppose you have a shred of proof)

I haven't seen any proof for the syntactic and styliistic "better" claims so far; why should I provide it? I *have* mentioned various different language features, and this has so far gone unnoticed.

That's no excuse for presuming to gainsay him on whether or not he had in fact used the languages in question.

My excuse for that was that he was debating syntax and the usefulness of linked lists, not lexical scope or closures. That is to say, he either managed to use Scheme without even *noticing* the useful features it provides, or didn't mention them in his reply.

You're generalizing from one poster on /. to the whole Python community?

Yes. That's how advocacy works. You play nice, and promote your language. Once you start being rude, you lose respect. You can analyze this at your leisure the beginning of this thread.

...but you don't seem to mind launching into an extended meta-debate. Personally, I think even the style debate was probably more worthwhile than a bunch of "did too, did not".

I don't think it was; I thought it was incredibly stupid, and I think this is too. But if I don't feel that you understood my post, then I will attempt to keep replying until you do.

Now here's the test. All that text before this line, what did it accomplish? Well, not much. So let's try again.

Riddle me this: does Python have lexical scope, closures, useful built-in data-types, familiar syntax, functions, variables, looping constructs, or objects? How does it help you manage a program better than, say, Perl? What does it *not* let you do that you might conceivably want to do, and how ugly are the methods used to get around this?

These are real questions, because I don't know Python. As I've said before, on the surface an average Python program looks like a Perl program without the curly brackets and the semicolons; instead it has labels and indentation and whitespace, which is strange, but still workable. Its arrays look pretty similar on the surface, it has modules and an object system, it appears to have built-in regexps, and it is also an interpreted scripting language.

So PLEASE tell me what I'm missing. To date, this entire flamewar has been completely useless, apparently based on semantics, or perhaps an incomprehensible hatred of the '@' symbol. All the Python code I've seen thus far could be run through a trivial translator to change the notation, and 90% of it would be workable Perl code, requiring little human translation.

So, if you can, tell me what's the big deal, and keep it clean this time. If you can't, well, don't reply again.
---
pb Reply or e-mail; don't vaguely moderate.

No, I was talking about syntax vs. features, but that's okay.

Thanks for the links, I might check it out some more, later. However, I don't see anything incredibly new and different as compared to Perl; I guess liking the syntax better *is* the reason to use Python, because the featureset looks relatively similar.

(I like the built-in set support, but the __main__ stuff looks like a nasty hold-over from C; so far, this is all looking like another useless flame-war over two languages of very similar functionality and very different weird syntactical limitations...)

---
pb Reply or e-mail; don't vaguely moderate.

I picked Python over Perl years ago. However, if I were to make the choice today based on the behavior of each's proponents in this discussion I'd make it the same way.

Someone else said something about Perl's lower "barriers to entry" resulting in a high percentage of its advocates being inexperienced and immature programmers. I think that's exactly right, except that the inexperience applies to advocacy as well as coding styles.

I dismiss syntax issues because that is a stylistic issue. You don't like Perl syntax, and from what I've seen, I don't like Python syntax.

Why? Well, you sit someone familiar with either C or shell script (like me) down in front of two moderately complicated Perl or Python programs, and see which one they figure out first.

Is that a fair test? No. Is that a test that goes on every day? Yes.

I dismiss syntax issues because that is a stylistic issue. You don't like Perl syntax, and from what I've seen, I don't like Python syntax.

Why? Well, you sit someone familiar with either C or shell script (like me) down in front of two moderately complicated Perl or Python programs, and see which one they figure out first. Is that a fair test? No. Is that a test that goes on every day? Yes.

But I wasn't going to ask you that question, because syntax flamewars are meaningless. Also, judging from the Python code you have on your website, well, it looks a lot like perl code, without some braces and semicolons, and if that isn't a trivial syntax issue, then I don't know what is.

You're right that Scheme's syntax is particularly easy to parse, but it isn't just about linked-lists. Built-in linked-list support is *very* handy, and Perl offers something about as powerful with its arrays; I gather Python does as well. Also, as another poster mentioned, lexically-scoped variables and closures are also potentially very handy, and this can be done in Perl as well. (by passing and returning references to anonymous subroutines and by using 'my' variables; Perl also has dynamic scoping if you need it, but you probably don't want to do that...)

It sounds like you like Python, but it doesn't sound like you've *really* used all three languages. Or rather, you seem to appreciate syntax over language features. If this is the case, then try out BASIC, and you will see my point.
---
pb Reply or e-mail; don't vaguely moderate.

Yes, that is flamebait, and I'll tell you why.

1) Perl is a pretty cool language; I've used it. Cryptic, yet powerful, much like C. Also, I like being able to write some simple, powerful text processing, without being bogged down by the details.

2) Scheme is a pretty cool language; I've used it. Simple, with interesting choices for primitives and control structures. I like being able to make and extend a program with an amazing amount of flexibility, and easily implement new features.

3) Python might very well be a cool language as well. However, I haven't used it; I'd have to try it out and find a use for it, and it looks pretty weird. However, since you've offered no actual facts for your argument, and bashed two other languages that I consider to be pretty good, (even if they are generally slower than C ;) then you haven't won any points with me; actually, you've lost a few.

4) Therefore, from (3), that's flamebait, not advocacy. Please reply with reasons that make Python a better choice than Perl or Scheme for a given problem domain, instead of "Python is so much better, and Perl and Scheme just suck". Syntax issues are irrelevant; I could probably write a tokenizer to get rid of the syntax issues involved, if I had to. Language support for features is relevant; (i.e. Scheme's choice of first-class types vs. Perl's references) also, implementation decisions are relevant (Perl and Scheme can be interpreted *or* compiled depending on the implementation, but generally are still slower than a truly compiled language because of their feature-sets, like "eval").
---
pb Reply or e-mail; don't vaguely moderate.

In that respect, it's no different from linux kernel development.

(Wow, look, 2.2.17 and 2.4.0-test7; what a jump! NOT!)

The added features are funny, though: C and C++ looking language constructs; tell me when they allow blocks and semicolons instead of whitespace and newlines, and then we'll talk. ;)
---
pb Reply or e-mail; don't vaguely moderate.

Yeah, there have been enough licensing stories on slashdot, but this one could have been interesting.

Ah well, another slashdot story I didn't see because of another slashdot bug that won't get fixed....
---
pb Reply or e-mail; don't vaguely moderate.

I remember Toshiba was feeling wishy-washy about the whole thing before, but IBM? Oh well.

I hope this doesn't set them back too much, because I want to see these things in action!
---
pb Reply or e-mail; don't vaguely moderate.

I tried to comment on stuff before, and the process they had was completely clueless.

See your tax dollars at work.

Has it gotten any better? I got an automated reply, and then nothing after that; it was *so* stupid.
---
pb Reply or e-mail; don't vaguely moderate.

I tried to comment on stuff before, and the process they had was completely clueless.

See your tax dollars at work.

Has it gotten any better? I got an automated reply, and then nothing after that; it was *so* stupid.
---
pb Reply or e-mail; don't vaguely moderate.

I'll second that.

Don't re-run slashdot, though; I miss it too much. April Fools Day from two or three years ago was priceless; last year was pitiful by comparison (and in general).

Actually, if I hadn't been here the whole time, I'm sure I'd just look at the Comments and say "What's all this stuff? Did some script kiddies get a hold of slashdot???", only to get a penis bird, a "Fuck Off", and an old-timer saying "No, son, it's always like that now. In my day..." :)
---
pb Reply or e-mail; don't vaguely moderate.

Okay, I'm running Mandrake now as well; it looks pretty slick. I hadn't gotten to try out Konquerer yet, so it'll be fun playing with all the installed software. :)
---
pb Reply or e-mail; don't vaguely moderate.

:) I know, right? That's why I made those comments about X and ncurses...

Personally, I like rhide, which is still text-mode, but...
---
pb Reply or e-mail; don't vaguely moderate.

Hmm. I don't know, my drive doesn't do it, either. I could have tried it out, but I figured it wasn't really worth it. (I read through about enabling ATA/66 on Linux; I might have to patch my kernel for that, and use hdparm, but it didn't sound like even that offered much improvement)

Mandrake has a *lot* of extra stuff; I'm installing it now, from rpmfind.org, and it's taking its time. The installer looks really cool, though, especially their partitioning tool!
---
pb Reply or e-mail; don't vaguely moderate.

Cool; I've hacked most of that into my system already, but it would be nice to see it supported out of the box.

Heck, I've got a couple of ReiserFS partitions, one of them as Software RAID-0. I've been playing around too much, I'm pretty happy with my 800 Mhz Thunderbird, myself. ;)
---
pb Reply or e-mail; don't vaguely moderate.

SDL is a wrapper, and it does some other stuff all by itself, but it's a standardized, platform-independent implementation for media stuff. I've messed with that a little, and even less with actual X internals, but I know it's possible to change the resolution on the fly, even as a regular user; I just don't know if it requires DGA. For a good example, fire up Heroes III for Linux. Also, that should give you an idea as to my gaming needs; 3D audio really is wasted there.

Actually, I think what I meant to say was, SDL is about equivalent to Direct X, and DGA lets you do some things like DirectDraw, or for that matter, SVGALib. (that is, get a full-screen console in a different graphics mode) If I missed anything, there's always OpenAL and OpenGL, but that should about cover it for multimedia APIs.

You're right; in this case, my argument is "I see no need for it, therefore it's not important". In fact, personally, that's generally my opinion on things. If, on the other hand, I think that it would be a really cool feature to have, well, then I'd want it. Example: The Office Assistant in Microsoft Office. I really see no need for it; therefore, I don't want it. :)

I couldn't tell you anything about NVIDIA benchmarks; I can tell you that I'm happy with my real-world performance with my Matrox G400. I'll happily run benchmarks between my Linux box and Windows '98; do you know of a good 3D benchmark suite? However, in any case, I don't think it's that big of a difference. When I find something I want to do that's noticably slower, I'll worry about it. Heck, I can load up an arcade game in MAME with GL support at 1280x1024x32, and it's smooth! That amazes me. Also, Q3A is pretty. :)

Is there a port of Half-Life to Linux? More to the point, do you know of any really good 3D role-playing games that I might be able to use? I couldn't get FF7 to work under Wine so far, and that's about it. I think the software-porting issue is more worrisome than the drivers, personally. And although I don't care about it, it looks like OpenAL supports 3D sound, or plans to. I haven't tried it, and don't know how mature it is yet, but I'm sure Loki will use it in a game sometime. :)

I don't play racing games; what about role-playing games? It's quite possible that I'm not enough of a gamer at heart to get it in the first place, unless side-scrollers count too...

The fact that manufacturers can sell identical products at vastly different prices based on a little configuration tweaking is pathetic. However, I didn't overclock my 800Mhz Thunderbird just because I wouldn't want to screw something up, or void the warranty. Even if it is trivially easy to do, I don't even have my box cooled very well, and I'm not much of a hardware hacker, either... :)

Well, sometimes NT can handle a week or two of uptime; even in a stable configuration, it still leaks memory. And if for some reason it isn't stable, well, then you're really in trouble. My Linux box isn't incredibly stable yet, either, but that's my problem; I'm trying out new stuff that probably isn't supported and recommended, and that's my fault. Most notably, I had to tweak arla a bit to get it to compile under kernel 2.4, and sometimes that module will die, but it doesn't bring down the whole system (it encounters a 'BUG()' in the kernel when it messes up, generally.) If I needed it for production, I'd be running kernel 2.2 and whatnot. :)

I just got a new computer, and I have an Abit KT7 board, an 800Mhz Athlon 'Thunderbird', a Matrox G400 DualHead 32MB, and an SB Live! Value... The DVD drive is a 12x Toshiba SD-M1402, and that's the only piece of hardware that isn't supported under linux. I installed Windows "Do You Want To Restart Your Computer?" '98 to test it out, and it seems to work just fine, though.

Incidentally, do you know of a good shell replacement in Win '98? I quickly tried a few of them last night, and they looked pretty unstable, or useless in the default configuration. I found a pager for Windows that's really cool, though; it's called DeskWin.
---
pb Reply or e-mail; don't vaguely moderate.

Thanks!

I tried to install 7.1 from CD, but the media was somewhat messed up, so I just went with what I knew, and did a network install of RH6.2.

How do you like Mandrake? Do you know if it would be faster/slower on an Athlon? (I don't think actual Pentium optimization would necessarily help...)
---
pb Reply or e-mail; don't vaguely moderate.

Definitely; otherwise, it would be time to protect you from my girlfriend. :)
---
pb Reply or e-mail; don't vaguely moderate.

Yes, but Scheme doesn't look like C. Read the article again, and replace 'ML' with 'Scheme', or whatever your favorite functional language is.

Also, remember:

1) BWK is sympathetic to your plight.

2) Think that perhaps one reason why he picked 'C' is that he could probably write Scheme in C if he really had to, but you could never write C in Scheme, and if you did, it'd be too slow. If you ever manage to write an optimizing C compiler in Scheme, though, hat's off to you. I'd be impressed just by the assembler... Therefore, in the long run, I think he'd be better off with his choice.

But yeah, I kinda like Scheme too. I might try writing it in Perl sometime. ;)
---
pb Reply or e-mail; don't vaguely moderate.

There's a network install image... It was somewhat buried, but I couldn't find it at all before! Has mandrake always supported doing an FTP install, or is this new?

I'd love to try it out, but (a) this is a BETA :) and (b) I just got my RedHat installation working decently on my cool new computer; I don't want to mess it up!

Oh well, I guess I could use a different partition for /usr, and whatnot, and back stuff up...
---
pb Reply or e-mail; don't vaguely moderate.

Well, watch closely. I can't stand vi. 'cat' and 'sed' are excellent tools. But I think what *he* was talking about was using some sort of text-based, interactive editor *from* the command line, and using the compiler entirely from the command line, and writing your program that way.

Hey, why isn't vi a CLI program, eh? Just 'cause it has that "EIGHT KILOBYTES of cursor positioning code"? I mean, really, what's wrong with xvi? Is it that megabyte of display-independent graphics code? Oh well. Ed. Ed is the standard. Text editor. ;)
---
pb Reply or e-mail; don't vaguely moderate.

Well, maybe it's less useful now, but it made a lot more sense when computers were more expensive, and not everyone necessarily had one. However, I think it provides a great environment for people--like a BBS where you can get all your work done! :)
---
pb Reply or e-mail; don't vaguely moderate.

It's called SDL; there's also OpenGL and OpenAL; that should be more than enough. Don't forget to thank Loki! :)
---
pb Reply or e-mail; don't vaguely moderate.

First, one question: do you think BeOS has great multimedia support? Heck, it doesn't even play DVD's! ;)

Windows and Linux and MacOS all have SDL. It supports DirectX on Windows, and DGA on X, which is the equivalent. The tests I saw for 3D acceleration didn't differ by much; it's way fast for me, even for Q3A. My speakers can't even take advantage of 3D sound decently, and I think I saw patches for all that stuff, but I really don't care yet. However, Linux *does* have great 3D acceleration, and the audio stuff is in hardware! Maybe our definitions of great differ, but the actual performance I'm seeing is pretty impressive. And I'm not saddened that I don't have 'force-feedback' on my Gravis Gamepad, I don't know of any games that support it, and I thought it was a dumb idea on the Playstation!

Yeah, Windows has more hardware support; that's because Microsoft doesn't have to write *ALL* the drivers. This situation is changing of course, and I like being able to poke around with the source code, but it'll take a while for this one to change--the corporate culture can be pretty entrenched about these things.

There are many different limited versions of Win2K. I don't care if it supports 2 processors out of the box, or what the configuration-of-the-week is; the bottom line is, Microsoft will always sell you the same product for much more by just making a minor registry tweak so you get the "new features", and I'm fundamentally opposed to that, because it's stupid; just as stupid as CPUs and overclocking, nowadays.

Well, I'd like to see the results of the tests before I draw my conclusions; you may be right. But if I did the tests, and one platform consistently crashed under certain conditions, I'd note that and put it in my review; that's NOT a feature.

Another benefit of Linux is the multitude of configuration options. Given the time and resources, I'd love to just benchmark Linux against itself! That is to say, configure one box with a standard kernel, OSS, ext2, XFree86 3.3.6, and a couple of IDE drives, and then configure another box with an optimized kernel, ALSA, reiserfs, XFree86 4.0.1, software RAID... well, in any case benchmark all the components against each other, and find out what the fastest, most stable Linux configuration is for a given hardware configuration. That isn't as straightforward in NT, because there aren't that many configuration options, and many of them aren't obvious or readily available.

Also, X has DGA, which allows direct video access. X has hardware acceleration, and there are third-party drivers that implement *better* acceleration. (I compiled UTAH-GLX for my Matrox card, and it's pretty impressive; I'm going to try the new drivers from Matrox if I try XFree86 4.0.1 again; the DRI project for it doesn't look mature yet) I realize that the way Windows does it is probably closer to the bare metal, but that way lies madness; you might as well just write a protected-mode DOS app to do it, 'cause it's about the same, except it's hooked into Windows.
---
pb Reply or e-mail; don't vaguely moderate.

Umm... Linux has support for quite a few processors out of the box, including 8, and you don't have to pay more for it. If you want a RAID card for Linux, look at the supported hardware list, just like you do when you want a RAID card for NT. If you want to test them, see where the two lists intersect. That is all.
---
pb Reply or e-mail; don't vaguely moderate.

I was writing a program for the class.

Do you know what the program was called?

That's right, 'sortuniq'.

I had already written similar code in Perl, though, while analyzing data for a simple Markov chain text hack, so I figured I'd compare the two.

Slashdot poster diverts attention from the on-topic Perl/C comparison.
---
pb Reply or e-mail; don't vaguely moderate.

No; in both cases, I wrote code for it that did not contain 'sort | uniq -c'. :)

This was our first assignment for the Operating Systems course I'm taking, CSC451. The goal is to get people up-to-speed in C.

However, once you have this program written, it's easy to hack in some tokenizing code, and get, say, each instance of a word. (or you could run something like "tr ' ' '/n'" and just cheat again. ;)

Also, implementing it together allows for speed improvements; by definition in the command 'sort | uniq -c', sort has to sort the whole input stream, and then uniq deletes the duplicates. This approach is algorithmically slower than only adding the unique elements and maintaining a count, and I wrote this approach in Perl and C. In Perl, it is impelemented with hashes, and is about 7 lines long.

#!/usr/local/bin/perl
while(<>) {
$index{$_}++;
}
foreach $word (sort keys(%index)) {
print "$index{$word}: $word";
}


The C version uses a simple binary tree structure with a reference count, and is slightly under 50 lines long. This is because, besides the simple tree code, I also have to dynamically allocate the strings to read them in up to the newline and whatnot...
---
pb Reply or e-mail; don't vaguely moderate.

WHAT???

Your solution here is "Don't use UNIX, just buy another Workstation"?

The original point was, you could get a big workstation, and have everyone run the apps they need off of that. It's cost-effective, and works great at Universities. There's a product like this for Windows too, that actually works decently: Citrix Metaframe. But X has done this on Unix, and so has telnet, for basically as long as they've been around. And if I wanted to use a real copy of VisualAge for Java at my University, that's what I'd use. If I were under Windows, I'd have to install a free X-server, too.

Just because you don't use it or understand it doesn't mean other people don't want it or need it.
---
pb Reply or e-mail; don't vaguely moderate.

How much RAM do you have?

NT loves to chew up RAM, and this isn't fixed decently yet in 2000...
---
pb Reply or e-mail; don't vaguely moderate.

Grab the FrontPage Extensions for Linux, and try to use FPExec for security--that way people who want FrontPage can use it there. If that's all you're using the Win2K box for, then format it, and install Linux, too. Once you get it working smoothly, you'll be so much happier. :)
---
pb Reply or e-mail; don't vaguely moderate.

Okay, I was with you for about the first half of that, but then your advocacy started overshadowing your facts.

First, I saw Windows 2000 Beta 3 crash on INSTALLATION, something that should never happen. The only time I've seen anything like that on Linux... well, the media was physically corrupted, and it still tried to install. :)

Linux and Windows can run each other's binaries perfectly; the problem is finding a program that completely emulates or virtualizes the x86. At the moment, I know that VMWare does a good job, and Bochs does too if you can live with how slow it is. Plex86 is in the works, and is showing promise, since it can run DOS now...

I agree about Netscape, it isn't terribly stable; however, most graphical browsers aren't, for one reason or another, *including* IE, in my experience. But Netscape has the potential to be downright horrible about it. However, X has been pretty good to me, and in my experience I've had much more trouble with gdm. (which is a reason to use xdm...)

BTW, Linux has great multimedia support. Okay, okay, let me explain. I have a Matrox G400, and the hardware acceleration is *sweet*. Also, my SB Live Value is just excellent, I love the hardware mixing, the multiple DSP's... I installed ALSA and now the MIDI patches ("soundfonts") work too, and they sound good.

It's all about picking supported hardware, though, which you still have to do for Win2K, as well. My DVD drive isn't supported, because I (a) couldn't find much information about that on the net, and (b) just bought it first, figuring I'd test it out later. I'll probably ask the developers about this, since it works under Windows. I've heard it can be made to work under VMWare too, so all I really need is some debugging info. :)

Plus support for multi-processing makes it even better. Now, I don't have more than one processor, but I might set up a dual-proc test box if I can ever find an old board for it. However, I've seen it done on Linux, and it is sweet. No paying extra for a different version that just consists of a stupid registry hack, either. It has decent multi-processing support out of the box. And I'd love to see a comparison to Win2K here, since that's one thing that's supposed to be better in 2.4.

How about that, eh, guys? Something based around Linux Kernel 2.4.0 with a bunch of stable stuff, vs. Win2KSP1, or whatever is current and patched by then. Test multi-processing, test well-supported hardware, RAID, whatever. Just test the hell out of it.

Being a real system administrator is based on experience. Now, I won't be one, because I'm going to graduate from college with a CSC major, and I'd rather be coding, but just because I *went* to college doesn't mean I've been idle, or don't know my stuff. Maybe not about Win2K, but I haven't really wanted to use it a whole lot. :)

And no, you don't have to do anything *wrong* for Win2K to crash on you. Sometimes you don't have to do anything. It's better, but it isn't perfect yet. And Microsoft has been that arrogant about it from Day 1; I don't know why they even pretend to have tech support. And how is realplayer crap? Is it just not Windows Media Player? Was it not written for Windows Internals, but instead cross-platform? As for Netscape, I'd rather run Mozilla; IE is not cross-platform, and it shouldn't be integrated into the OS file browser, and it annoys the hell out of me. I haven't tested rendering yet, but I'd want to test two equivalently dated versions. (IE 4, NS4; Current IE, Current Mozilla...)
---
pb Reply or e-mail; don't vaguely moderate.

Well, the idea behind Perl is a little bit different; it has too many decently implemented features to just be a scripting language, no matter how some people use it. It's humble, too--although it has the few useful features of Java, (packages and object-orientation, at least) it doesn't take the NIH approach and pointlessly rename everything like Java does. :)

I like C, too; because Perl is generally interpreted, and because of some of the features it has now, writing your average C-looking code in Perl isn't worth it--it'll be up to 10 times slower. However, writing code that takes advantage of Perl's features will perform much better, and can be expressed in much fewer (and easier to read) lines of code.

Examples:
- Being able to use a hash for quick lookup, or as an arbitrary name-space is really handy.
- A reference to a sub-routine functions as a closure, not as a function pointer; without this, functional programming can be more difficult to do... :)
- Arrays are readily growable, and can function as a stack, or other linear data structure.
- Extra types, like arbitrary-precision number routines, are readily available.
- CGI and database programming is ridiculously easy to do.

Finally, I wrote a program that takes arbitrary input line-by-line, and outputs sorted unique lines with a count of how many of each line it found. It took me 7 lines of Perl code, (counting the comment to run the Perl interpreter :) and 50 lines of C.

The C approach dynamically grows the strings as needed, and using a dynamic array of pointers and qsort takes up a little bit more code than using a binary tree with a reference count, but they are both around 50 lines of code.

I haven't tested the two of them against each other yet, but the Perl code should be faster in general, for big files, because the built-in hash routines are algorithmically superior. (i.e. I don't think they have a worst-case of Order-n-squared...)

So, yes, a place for everything, and everything in its place. There are many times when Perl is the right tool for the job, and C isn't. I wouldn't write an Operating System Kernel in Perl unless I could make a *really* optimized compiler for it, but for many other tasks it's a much better choice. Besides, if you *need* to write something in C, you still *can*. And if you still don't like it, well, you can write a better language in C, just like they wrote Perl. :)
---
pb Reply or e-mail; don't vaguely moderate.

No, that's the point; it really had a built-in couch, by design!


---
pb Reply or e-mail; don't vaguely moderate.

I want one of the old couch-shaped ones--that actually *would* look great in my dorm room! :)
---
pb Reply or e-mail; don't vaguely moderate.

No, a "web-pad" is like having an actual notebook that you carry around and use, sort of like a large palm pilot; a laptop is generally larger, but more importantly has to be unfolded; it's inconvenient on planes and many other places.

Of course, I probably still wouldn't get one because it would get lost or stolen too easily, but at least I could live with a web-pad...

Of course, I'd still want to run whatever OS I want; I'd be happy with one optional lap-top style port or bay for a device, at least for installation purposes. And of course, built-in networking...

It wouldn't surprise me if they had a lot of MediaGX's lying around, though... ;)
---
pb Reply or e-mail; don't vaguely moderate.

Well, you'd want some sort of encryption layer over it, for one. Also, you'd want to do redundant calculations where possible, to verify accurate results. But I think a lot of those issues have already been taken care of...

Yes, most people don't care. They know it's a screensaver, they're getting a check, and maybe they're helping someone else out. While we monitor the packets and wonder what they're actually doing, why we have no bandwidth, or why their box just tried to use an NFS exploit on their network segment... :|
---
pb Reply or e-mail; don't vaguely moderate.

It's cheaper for companies to outsource some projects to another company and have them do the computing however they can than to rent time on a mainframe.

If you design a cool screensaver to go with it, and make it run on Windows, I'm sure you'll get the support of college students everywhere, even if it beams information back to an evil corporation, does tests on nuclear missle aging, DNA analysis, or hacking your friend's box... They won't know the difference. Of course, it'd be nice to check these things for trojans too.

Yes, this is an application for Beowulf clusters as well; for massively parallel problems, it might be worth setting up shop in that business instead. I bet IBM does just that, for one, but I'm sure they'd rather sell you a mainframe, where possible... :)
---
pb Reply or e-mail; don't vaguely moderate.

This sounds like a cool little web pad, but I don't think I want to use a "Cyrix Media GX" processor running at only 166Mhz. I'm sure having all that stuff on a chip is great for production, and all your standard web-surfing, but this still won't be very powerful.

What I *really* want is the "web-pad" that works like a laptop, and has some decent specs, (say, a good desktop from a year or two ago, not three or four years...) but I gues I'll be waiting a bit longer.

And yes, if you read the article, the specs are in there; I'm sure someone will post them, regardless.
---
pb Reply or e-mail; don't vaguely moderate.

I think I saw that movie...

Good thing this is just Slashdot, so it isn't real or anything... :)
---
pb Reply or e-mail; don't vaguely moderate.

"Maybe they landed there later"...

It'll be interesting to see if they can come up with anything better. ;)
---
pb Reply or e-mail; don't vaguely moderate.

Really? Wow!

I was going to say that MainWin sucks, just based on my experiences with attempting to use Microsoft-ported products, like IE (Aieee!) on Solaris; no web browser should require kernel patches. REALLY.

...therefore, Wind/U must really suck. I guess if Wine ever stabilizes and tracks the Win32 API decently, (Ha ha... It's gotten a lot better, but I'll be impressed if and when they ever do catch up; by then, the dominant processors will probably have x86 compatibility built into the hardware...) it can be ported to other processors. (since a lot of it really is reimplemented in C)
---
pb Reply or e-mail; don't vaguely moderate.