> Is this funny, insightful or flamebait -- you be the judge.
Yes, yes it is.
Python is for a different sort of mindset than Perl, a mindset that is less comfortable with having multiple different ways to accomplish the same thing, more comfortable with having one obvious way to do things, a mindset that prefers objectual programming over contextual or functional programming, a mindset that doesn't think significant whitespace is evil. If you find that you don't like Perl, then you should give Python a try, as you might like that. (Conversely, if you find that you don't like Python, you should try Perl. They're really quite different in style.) The languages are both VHLLs, and so they're both suitable for modern programming (as opposed to, say, C, which is not, unless you're doing some inherently low-level stuff that *requires* micromanaging resources, such as device drivers, bootloaders, kernels, &c).
I recommended Perl not because Python is bad, but because Perl is what I use and what I know. (I tried Python briefly, but it didn't really take for me. I don't like its typing system. That's just a personal preference.) I don't wince when people start new projects in Python, like I do when they start new projects in C.
> Everquest, IMHO, beats the hell out of any text adventure I ever played, ever!
I saw a guy playing Everquest for about an hour once. He was an experienced player at the game, but during the whole hour (I was bored; my other choice, besides watching him, was to listen to people yack about sports and junk), he didn't actually *accomplish* anything in the game. He killed some bad things and picked up a couple of items, then visited a city. Whoo. Sure made me wonder why he pays a monthly fee for this. I think you have to be into the whole RPG thing.
The best computer game probably that I have ever played is Curses, although Descent and Scorched Earth were pretty good too, in their day, and are still fun from time to time.
> and to my delight discovered that the Linux port of the Inform parser ran > these games perfectly
It wouldn't be the Inform parser (to use that, you'd need source, but the source would be in ZIL and would not be compatible with Inform...) but the z-machine emulator (probably Frotz). Also, if it surprised you that you could run the games in Linux, you obviously aren't the least bit familiar with the IF community. z-machine (version 3) binaries are probably the third most portable format, after ASCII text and HTML3.2. There are z-machine emulators for types of computer systems that you've never heard of, 8-bit microcomputers, university minicomputers, mainframes, handheld devices too small and unpowerful to have Perl or Java, systems that don't have a GUI, systems that *only* have a GUI and no text-mode library, systems without a filesystem, most programmable calculators, and certain brands of wristwatches. You name a data format, it's less portable (except, as mentioned, ASCII text and HTML3.2).
Wow, that was weird. It looked fine in preview. Let's try this again...
The difference is that XML-handling libraries all handle this automagically (usually by encoding angle brackets within text data). Yes, it's possible to have a library that does other escaping schemes automatically, but there's still the issue of human-readability...
These will parse out to the same thing. And yes, if the records are all this simple, and all *the same*, XML is unnecessary. But the minute the records get even remotely complex, especially if some of the records have bits of information that other records don't have, the human readability gets lost in a sea of stuff like
Then you need a better structure than CSV. Is XML the only option? No. But XML has the advantage of being fairly intuitive and strongly resembling something (HTML) that everyone and his dog (thinks he sort of) knows.
Yeah, it's longer. One order of magnitude longer than the CSV, not so much longer than some of the other options. In many circumstances, the extra length is a good tradeoff. I don't understand the desire to bash XML every time it comes up, just because it's a buzzword. Sure, it's a buzzword, and using XML doesn't really add inherent value, but it doesn't detract, either. I still maintain, it's a perfectly valid choice.
> BTW: I manage [stuff]
That's nice. I'm TCG at a public library. We work daily (as does every library) with a format called "MARC Records", and let me tell you, XML looks mighty attractive.
> By moving from comma-delimited to XML you don't solve the problem, you just > move it. What happens if someone includes text in a record that just happens > to close your field?
The difference is that XML-handling libraries all handle this automagically (usually by encoding 12Biff; > Biff
These will parse out to the same thing. And yes, if the records are all this simple, and all *the same*, XML is unnecessary. But the minute the records get even remotely complex, especially if some of the records have bits of information that other records don't have, the human readability gets lost in a sea of stuff like
Then you need a better structure than CSV. Is XML the only option? No. But XML has the advantage of being fairly intuitive and strongly resembling something (HTML) that everyone and his dog (thinks he sort of) knows.
462-3203
468-1708
Yeah, it's longer. One order of magnitude longer than the CSV, not so much longer than some of the other options. In many circumstances, the extra length is a good tradeoff. I don't understand the desire to bash XML every time it comes up, just because it's a buzzword. Sure, it's a buzzword, and using XML doesn't really add inherent value, but it doesn't detract, either. I still maintain, it's a perfectly valid choice.
> BTW: I manage [stuff]
That's nice. I'm TCG at a public library. We work daily (as does every library) with a format called "MARC Records", and let me tell you, XML looks mighty attractive.
Perl isn't called a "glue language" for no reason. You can stick *anything* together with it. Need to process an image using Gimp's filters, resize it, and insert it into an OpenOffice document? No problem, Perl can do that. (You need the Gimp/Perl bindings, which most distros make a separate package from the Gimp itself, but installing them easy. If you want the script to be portable at all, you also want Archive::Zip. If portability doesn't matter you can backtick out to the info-zip version of zip instead.) Need to automatically retrieve a webpage, fill out and submit a series of forms, parse the resulting page, extract some data, and insert that into the document too? No problem. (You want WWW::Mechanize and HTML::Tree.) I could go on, but you get the idea. When it comes to automating common repetitive tasks, Perl is awesome, and the modules on the CPAN have most of the work already done.
If all you want is to press a key on the keyboard and have a series of key strokes punched in, get yourself a macro-equipped keyboard. (Avant makes the top-of-the-line ones, but there are cheaper ones out there too.) But if you want to make things happen automatically while you sleep, read slashdot, and do other unproductive things, learn Perl. Also learn to use cron.
The traditional COME FROM statement isn't good enough for me. I demand the facility for *computed* COME FROM statements. I want to be able to use a COME FROM statement that calls a function to determine what line to COME FROM. Moreover, with threaded intercal, I want to be able to call a multithreaded function in order to determine what line(s) to COME FROM.
> parsing a comma delimited file when the records are reasonably simple > in structure
Have you ever worked with real data? Real data has commas within some of the records -- so then you switch to allowing records to be quoted, or commas to be escaped. Then you get data with newlines embedded in the records, so you have to allow those to be quoted or escaped too (unless you have a fixed number of columns per row, which is the exception rather than the rule). So you establish a rule that entries which start with ' or " are quoted, and you go to the end quote mark even if there are embedded commas and newlines. Then you have entries with embedded quote marks -- both kinds of them.
Bah. It's more complicated wheel than you think, and XML handles all this stuff. There are other formats that handle it too, but XML is a perfectly cromulent choice and is more human-readable than average.
Yes, it uses a few extra bytes, but the number of bytes can still be described as O(n) -- i.e., the size grows only linearly with the amount of data that have to be represented. Squabbling over whether the file is 10k or 100k is, this century, misguided. There are more important things programmers should spend their time on than saving a few bytes. Robustness, for example, is far more important to the end user (and, in terms of maintenance, to the programmer) than a few bytes one way or the other.
> So you are saying that Windows is better than Linux because more people use it?
No, I was talking about an archive file format, and specifically about selecting an archive file format for distributing stuff on the internet. Using RAR or bzip2 for that is like sending richtext email or using browser-specific markup in a web page.
Additionally, how many people *use* something is almost always irrelevant. What I was talking about was how many people have software (any software) that's capable of opening the format -- i.e., ubiquity.
> were there any wide-spread, legitimate uses of.RAR?
RAR was heavily used in Germany, among the gamer community. A lot of Descent players for example distributed their custom levels, missions, textures, hogfile utilities, savegame editors, and whatnot in RAR format. It was annoying; I had to go hunt down and download a RAR extractor just to install some of the stuff.
The usual argument was that RAR was "better" than ZIP either because of the compression rates or because of the partial recoverability or whatever. My opinion on the matter has always been that for distributing stuff over the internet, the most ubiquitous format is automatically the best, so ZIP is better than RAR irrespective of technical issues, due to compatility concerns. By the same reasoning, gzip is automatically better than bzip2, and no amount of technical superiority makes a good enough reason to use bzip2 over gzip. Frankly, for anything that's not inherently *nix-specific, ZIP is better than gzip for the same reason. Not everyone agrees with me about this, obviously.
> Just today, I read that the Netherlands was the country where the people > were the LEAST happy after the switch to the Euro, in comparison with > other Euro countries.
Okay, but how much common sense can you expect out of a people who live below sea level within a stone's throw of the sea? I suspect they have to be a little bit wild and crazy just to keep their sanity.
> Now we can have Washington, Lincoln, and...um...
Washington, Lincoln, and Reagan. Don't wince; he fits right in. Washington, despite his reputation as a military hero, was politically a Whig; today the Whig party is known as the Republican party. Lincoln was officially the Republican party's first elected candidate after the reorganisation, and the more conservative parts of the party today (the fire-breathing Reaganites if you will) hold views that are closer to those held by Washington and Lincoln than the views of the more liberal ("moderate") portions of the party.
The Democratic party are the progeny of men like Thomas Jefferson and FDR. I don't know who their third guy would be; they don't seem to have had a strong president lately. Clinton was too (politically) moderate to really be representative. Maybe their third strong president would be JFK, but more likely someone yet future.
> I can't think of any applications that I would rather have tightly integrated > than a AV prog and a decent firewall.
You lack imagination then. There are lots of things that I'd rather have tightly integrated with the OS than superfluous antivirus software. (The firewall is another matter, but it's also off-topic for this thread.)
What would I rather have integrated with the OS than AV software? How about a secure shell server? How about an X11 server so that GUI apps can be run over the incoming and outgoing ssh connections? Gosh, wouldn't that be nice? How about a thing that automatically checks with a network time server on the internet and keeps the system time accurate? Wouldn't it be nice if the OS came with Perl and a working CPAN.pm out of the box? Which brings up another point -- what about a full development environment, complete with compilers or interpreters for several popular languages?
Antivirus software should be integrated with the mail server, but it doesn't necessarily need to be integrated with the OS.
> but can you identify spam before opening it 100% of the time?
Not with certitude, no. About 2% of the time I have to look at the message body to be sure. Nevertheless, this nonsense about humans only being 99.8% accurate is based on the *average* human, and that figure is dragged way down by a relative few who lack any kind of discernment at all, and a somewhat larger minority whose accuracy is less than what it ought to be because they are careless.
> Is it really common practice to develop in something other than the > current tree? In my experience, everyone involved in a project is expected > to work in the most current version of the tree, and to update their local > working copy first thing every day (and several times throughout the day).
This expectation is problematic, because it effectively prevents anyone on a dialup connection from being able to contribute. By the time they get their CVS tree updated, it's well past time to start updating it again.
A lot of people around here have been getting decent results from the temp work services. Seems that some of the employers in the area don't hire anyone directly anymore; they get temps, and if they like one, then they offer them a full-time position after a couple of months.
It also seems that people who mail resumes aren't as likely to get a job as people who hand-deliver them.
As for internet job boards, I never imagined anyone would take them very seriously, until I started getting a lot of questions from users about them. It seems a lot of people are under the impression that if they submit their resume someplace on line, a job will magically find them. Huh? Who wants to hire someone so lazy that they don't even want to apply for individual jobs, but just wait for their ship to come in?
> Also you have no way of knowing the email address it will come from to add > it to a whitelist.
You almost always know the domain it's going to come from, and you almost always know (within a couple of minutes) when it's going to come, so you could set your filter to a mode where it holds probably-spam messages in quarantine and use a web interface to pick the one in question off the list.
False positives that can be *predicted* aren't the problem. What worries me more is the ones that would surprise us. Like I said upthread, if I have to go through the list of all the spam messages looking for false positives, then the system is no better than what I have now, wherein (most of) my spam stays in my inbox and almost all of my legitimate mail gets picked up by various regex filters and sorted into folders. Then I look through the list of messages in the inbox and mass-move them out to a spam folder, but I glance over the list as I do it, checking for legit messages that my filters missed. Any spam filtering method that proposes to beat this approach has to absolutely guarantee to get zero false positives, and I have to believe it. Only then can I stop looking through the list for the occasional message that should have gone into the real mail folder.
Newsletters and announcement lists are one way, but they send mail only once every week/month/whatever. Spammers send 24/7 pretty much. I'm not sure how well the method deals with that difference, but it is potentially possible to devise one that does.
Discussion lists of course are a no-brainer, because there's traffic going out from the users to the list.
The other way to deal with announcement lists of course is to have the user add them to a whitelist when they sign up for the list. This would not be something you'd want to do at an ISP level (at least not for all users -- maybe for users who knowingly sign up for it), but it would be something people who get a lot of spam could resort to relatively painlessly; it's already a multi-step process to sign up for most such lists, giving them your address in usually a web-form, getting a confirmation message, going to the special tokenized address it gives you... adding one extra step to that process (whitelist the sender) would be an annoyance, but for those of us who get a lot of spam it would be less of an annoyance than the spam.
I must say, I am dubious about the claims of no false positives, but if it proves to be true, sign me up. False positives are the bane of bayesian filtering -- what good is it if you have to go through the spam folder to make sure there aren't any false positives? At that point you might as well filter your real mail off into folders, let the spam fall into the inbox, and go through it there to check for real mail that got missed. (This is what I currently do, although I filter some spam off into folders using methods that don't get false positives, so that I don't have to look through them. Filtering on character set is my most effective technique for this; it can't possibly get false positives because the idea of a legitimate message in a character set I can't read is as far as I'm concerned inherently oxymoronic; even on the off chance that the sender is not a spammer, the message is still not one that I can usefully read.)
> It seems to me that the Linux/Open Source community has already chosen.net
Sure, but what do toplevel domain suffices have to do with Java?</rimshot> Seriously, apart from a small handful of Mono and.GNU developers and fans, I think most people in the OSS community are utterly ignoring.NET. What's perhaps more telling is that most people in the Windows development community are also apparently ignoring.NET. (Well, sortof. They use the VB.NET and C# compilers, but they don't write their software any differently than before; to them it's just the next version of VB or Visual C++. In other words, the existence of.NET doesn't actually matter to them.)
> it's sad really... There are much more complaints about Sun and Java than > against.net and Microsoft on this site. I just can't figure it out.
There are more (meaningful) complaints about Sun and Java because they're more relevant. (Actually, there are plenty of complaints about Microsoft too, but you'll notice that they're mostly terse jibes. This is because the complaints that would have substance don't need to be stated; they are already well-understood by all concerned.)
Java has a pretty good following. About as good as Python, approximately. Which is to say, setting aside the Most Ubiquitous Lanuage Ever (i.e., C) as unfair competition entrenched for historical reasons, Java still scores at best a very distant third place after Perl and C++, which are vastly more popular. The success of C++ can be linked to that of C, since it's based on it. The reasons for the success of Perl are less obvious, but I think most of them can be attributed directly to the personality of Larry Wall. For example, chapters 1 and 2 of the Camel book do an impressive job (typically) of making people like the language; these chapters are very typical of Wall's writing style. (Yes, there were two coauthors, but those chapters reek of Larry Wall. Compare them to e.g. the Apocalypse articles; you can just *tell* they're written by the same author.)
I think it's naive of Sun to dismiss Perl because it's a "scripting language". Perl is not Perl 3 anymore. Nevertheless, I also think it's naive of ESR to say that Java's place has, due to licensing restrictions, been effectively ceded to Perl and Python. Python is not so much more popular than Java that "effectively ceded" makes any sense, and I don't think it's at all clear that Perl's popularity is mostly due to licensing. If anything, the Perl community is very divided on the issue of licensing. Perl runs on a wide assortment of platforms, most of them proprietary, and is very popular among sysadmins and powerusers on e.g. Windows. Licensing? Mostly irrelevant. You can download it legally without paying money, what else matters? There is a bias toward *nix in the Perl community, but proprietary unices are not considered inferior or looked down upon, at least not generally. (Well, UnixWare is, but that's another matter.) My take on this is that there's a bias toward *nix *mostly* because *nix systems all come with Perl out of the box. The Perl community would dearly love to see ActiveState and Microsoft collaborate to include (a decently recent version of) Perl on Windows systems out of the box; that would be the icing on the cake for Perl's ubiquity, which is already fairly impressive. (The decorative flowers on the icing would be a working CPAN.pm included with the MS/AS OOTB offering, but that's perhaps too much to hope.)
> Going back on topic, let me share what I've learned about troubleshooting > hardware issues. First, let me stress that it's usually not a hardware issue.
Slashdot Mirror
> Is this funny, insightful or flamebait -- you be the judge.
Yes, yes it is.
Python is for a different sort of mindset than Perl, a mindset that is less
comfortable with having multiple different ways to accomplish the same thing,
more comfortable with having one obvious way to do things, a mindset that
prefers objectual programming over contextual or functional programming, a
mindset that doesn't think significant whitespace is evil. If you find that
you don't like Perl, then you should give Python a try, as you might like that.
(Conversely, if you find that you don't like Python, you should try Perl.
They're really quite different in style.) The languages are both VHLLs, and
so they're both suitable for modern programming (as opposed to, say, C, which
is not, unless you're doing some inherently low-level stuff that *requires*
micromanaging resources, such as device drivers, bootloaders, kernels, &c).
I recommended Perl not because Python is bad, but because Perl is what I
use and what I know. (I tried Python briefly, but it didn't really take for
me. I don't like its typing system. That's just a personal preference.) I
don't wince when people start new projects in Python, like I do when they
start new projects in C.
> Everquest, IMHO, beats the hell out of any text adventure I ever played, ever!
I saw a guy playing Everquest for about an hour once. He was an experienced
player at the game, but during the whole hour (I was bored; my other choice,
besides watching him, was to listen to people yack about sports and junk),
he didn't actually *accomplish* anything in the game. He killed some bad
things and picked up a couple of items, then visited a city. Whoo. Sure
made me wonder why he pays a monthly fee for this. I think you have to be
into the whole RPG thing.
The best computer game probably that I have ever played is Curses, although
Descent and Scorched Earth were pretty good too, in their day, and are still
fun from time to time.
> and to my delight discovered that the Linux port of the Inform parser ran
> these games perfectly
It wouldn't be the Inform parser (to use that, you'd need source, but the source
would be in ZIL and would not be compatible with Inform...) but the z-machine
emulator (probably Frotz). Also, if it surprised you that you could run the
games in Linux, you obviously aren't the least bit familiar with the IF
community. z-machine (version 3) binaries are probably the third most portable
format, after ASCII text and HTML3.2. There are z-machine emulators for types
of computer systems that you've never heard of, 8-bit microcomputers, university
minicomputers, mainframes, handheld devices too small and unpowerful to have
Perl or Java, systems that don't have a GUI, systems that *only* have a GUI
and no text-mode library, systems without a filesystem, most programmable
calculators, and certain brands of wristwatches. You name a data format, it's
less portable (except, as mentioned, ASCII text and HTML3.2).
Yeah, I forgot the closing / in my name tags. But the XML library would be
doing that part automatically, normally.
Wow, that was weird. It looked fine in preview. Let's try this again...
The difference is that XML-handling libraries all handle this automagically
(usually by encoding angle brackets within text data). Yes, it's possible
to have a library that does other escaping schemes automatically, but
there's still the issue of human-readability...
> <LUSER><UID>12<UID><NAME>Biff</NAME></LUSER>
> <LUSER UID="12"><NAME>Biff</NAME></LUSER&g t;
These will parse out to the same thing. And yes, if the records are all this
simple, and all *the same*, XML is unnecessary. But the minute the records
get even remotely complex, especially if some of the records have bits of
information that other records don't have, the human readability gets lost
in a sea of stuff like
LUSER 7125,Johnson,Biff,G.,,Jr.,,462-3203,44833
LUSER 6784,Johnston,Maria,,Taylor,,,468-1708,44833
Then you need a better structure than CSV. Is XML the only option? No.
But XML has the advantage of being fairly intuitive and strongly resembling
something (HTML) that everyone and his dog (thinks he sort of) knows.
<luser id="7125" zip="44833">
<name last="Johnson" first="Biff" middle="G." suffix="Jr.">
<phone>462-3203</phone></luser>
<luser id="6784" zip="44833">
<name last="Johnston" first="Maria" maiden="Taylor">
<phone>468-1708</phone></luser>
Yeah, it's longer. One order of magnitude longer than the CSV, not so much
longer than some of the other options. In many circumstances, the extra
length is a good tradeoff. I don't understand the desire to bash XML every
time it comes up, just because it's a buzzword. Sure, it's a buzzword, and
using XML doesn't really add inherent value, but it doesn't detract, either.
I still maintain, it's a perfectly valid choice.
> BTW: I manage [stuff]
That's nice. I'm TCG at a public library. We work daily (as does every
library) with a format called "MARC Records", and let me tell you, XML
looks mighty attractive.
> By moving from comma-delimited to XML you don't solve the problem, you just
> move it. What happens if someone includes text in a record that just happens
> to close your field?
The difference is that XML-handling libraries all handle this automagically
(usually by encoding 12Biff;
> Biff
These will parse out to the same thing. And yes, if the records are all this
simple, and all *the same*, XML is unnecessary. But the minute the records
get even remotely complex, especially if some of the records have bits of
information that other records don't have, the human readability gets lost
in a sea of stuff like
LUSER 7125,Johnson,Biff,G.,,Jr.,,462-3203,44833
LUSER 6784,Johnston,Maria,,Taylor,,,468-1708,44833
Then you need a better structure than CSV. Is XML the only option? No.
But XML has the advantage of being fairly intuitive and strongly resembling
something (HTML) that everyone and his dog (thinks he sort of) knows.
462-3203
468-1708
Yeah, it's longer. One order of magnitude longer than the CSV, not so much
longer than some of the other options. In many circumstances, the extra
length is a good tradeoff. I don't understand the desire to bash XML every
time it comes up, just because it's a buzzword. Sure, it's a buzzword, and
using XML doesn't really add inherent value, but it doesn't detract, either.
I still maintain, it's a perfectly valid choice.
> BTW: I manage [stuff]
That's nice. I'm TCG at a public library. We work daily (as does every
library) with a format called "MARC Records", and let me tell you, XML
looks mighty attractive.
Perl isn't called a "glue language" for no reason. You can stick *anything*
together with it. Need to process an image using Gimp's filters, resize it,
and insert it into an OpenOffice document? No problem, Perl can do that.
(You need the Gimp/Perl bindings, which most distros make a separate package
from the Gimp itself, but installing them easy. If you want the script to
be portable at all, you also want Archive::Zip. If portability doesn't
matter you can backtick out to the info-zip version of zip instead.) Need to
automatically retrieve a webpage, fill out and submit a series of forms, parse
the resulting page, extract some data, and insert that into the document too?
No problem. (You want WWW::Mechanize and HTML::Tree.) I could go on, but you
get the idea. When it comes to automating common repetitive tasks, Perl is
awesome, and the modules on the CPAN have most of the work already done.
If all you want is to press a key on the keyboard and have a series of key
strokes punched in, get yourself a macro-equipped keyboard. (Avant makes the
top-of-the-line ones, but there are cheaper ones out there too.) But if you
want to make things happen automatically while you sleep, read slashdot, and
do other unproductive things, learn Perl. Also learn to use cron.
> so, you're only 98% accurate?
No, but I achieve my accuracy by knowing when the headers alone aren't
enough to be sure and examining the body in those cases.
The traditional COME FROM statement isn't good enough for me. I demand the
facility for *computed* COME FROM statements. I want to be able to use a
COME FROM statement that calls a function to determine what line to COME FROM.
Moreover, with threaded intercal, I want to be able to call a multithreaded
function in order to determine what line(s) to COME FROM.
> parsing a comma delimited file when the records are reasonably simple
> in structure
Have you ever worked with real data? Real data has commas within some of the
records -- so then you switch to allowing records to be quoted, or commas to
be escaped. Then you get data with newlines embedded in the records, so you
have to allow those to be quoted or escaped too (unless you have a fixed number
of columns per row, which is the exception rather than the rule). So you
establish a rule that entries which start with ' or " are quoted, and you go
to the end quote mark even if there are embedded commas and newlines. Then
you have entries with embedded quote marks -- both kinds of them.
Bah. It's more complicated wheel than you think, and XML handles all this
stuff. There are other formats that handle it too, but XML is a perfectly
cromulent choice and is more human-readable than average.
Yes, it uses a few extra bytes, but the number of bytes can still be described
as O(n) -- i.e., the size grows only linearly with the amount of data that have
to be represented. Squabbling over whether the file is 10k or 100k is, this
century, misguided. There are more important things programmers should spend
their time on than saving a few bytes. Robustness, for example, is far more
important to the end user (and, in terms of maintenance, to the programmer)
than a few bytes one way or the other.
Are you kidding? kill -9 is for wussies. Real men use init 1.
> So you are saying that Windows is better than Linux because more people use it?
No, I was talking about an archive file format, and specifically about
selecting an archive file format for distributing stuff on the internet.
Using RAR or bzip2 for that is like sending richtext email or using
browser-specific markup in a web page.
Additionally, how many people *use* something is almost always irrelevant.
What I was talking about was how many people have software (any software)
that's capable of opening the format -- i.e., ubiquity.
> were there any wide-spread, legitimate uses of .RAR?
RAR was heavily used in Germany, among the gamer community. A lot of Descent
players for example distributed their custom levels, missions, textures,
hogfile utilities, savegame editors, and whatnot in RAR format. It was
annoying; I had to go hunt down and download a RAR extractor just to install
some of the stuff.
The usual argument was that RAR was "better" than ZIP either because of the
compression rates or because of the partial recoverability or whatever. My
opinion on the matter has always been that for distributing stuff over the
internet, the most ubiquitous format is automatically the best, so ZIP is
better than RAR irrespective of technical issues, due to compatility concerns.
By the same reasoning, gzip is automatically better than bzip2, and no amount
of technical superiority makes a good enough reason to use bzip2 over gzip.
Frankly, for anything that's not inherently *nix-specific, ZIP is better than
gzip for the same reason. Not everyone agrees with me about this, obviously.
> Just today, I read that the Netherlands was the country where the people
> were the LEAST happy after the switch to the Euro, in comparison with
> other Euro countries.
Okay, but how much common sense can you expect out of a people who live
below sea level within a stone's throw of the sea? I suspect they have to
be a little bit wild and crazy just to keep their sanity.
You've been playing too much interactive fiction.
> Now we can have Washington, Lincoln, and...um...
Washington, Lincoln, and Reagan. Don't wince; he fits right in. Washington,
despite his reputation as a military hero, was politically a Whig; today the
Whig party is known as the Republican party. Lincoln was officially the
Republican party's first elected candidate after the reorganisation, and the
more conservative parts of the party today (the fire-breathing Reaganites if
you will) hold views that are closer to those held by Washington and Lincoln
than the views of the more liberal ("moderate") portions of the party.
The Democratic party are the progeny of men like Thomas Jefferson and FDR.
I don't know who their third guy would be; they don't seem to have had a
strong president lately. Clinton was too (politically) moderate to really
be representative. Maybe their third strong president would be JFK, but
more likely someone yet future.
> I can't think of any applications that I would rather have tightly integrated
> than a AV prog and a decent firewall.
You lack imagination then. There are lots of things that I'd rather have
tightly integrated with the OS than superfluous antivirus software. (The
firewall is another matter, but it's also off-topic for this thread.)
What would I rather have integrated with the OS than AV software? How about
a secure shell server? How about an X11 server so that GUI apps can be run
over the incoming and outgoing ssh connections? Gosh, wouldn't that be nice?
How about a thing that automatically checks with a network time server on
the internet and keeps the system time accurate? Wouldn't it be nice if the
OS came with Perl and a working CPAN.pm out of the box? Which brings up
another point -- what about a full development environment, complete with
compilers or interpreters for several popular languages?
Antivirus software should be integrated with the mail server, but it doesn't
necessarily need to be integrated with the OS.
> but can you identify spam before opening it 100% of the time?
Not with certitude, no. About 2% of the time I have to look at the message
body to be sure. Nevertheless, this nonsense about humans only being 99.8%
accurate is based on the *average* human, and that figure is dragged way down
by a relative few who lack any kind of discernment at all, and a somewhat
larger minority whose accuracy is less than what it ought to be because they
are careless.
> Is it really common practice to develop in something other than the
> current tree? In my experience, everyone involved in a project is expected
> to work in the most current version of the tree, and to update their local
> working copy first thing every day (and several times throughout the day).
This expectation is problematic, because it effectively prevents anyone on
a dialup connection from being able to contribute. By the time they get
their CVS tree updated, it's well past time to start updating it again.
A lot of people around here have been getting decent results from the temp
work services. Seems that some of the employers in the area don't hire
anyone directly anymore; they get temps, and if they like one, then they
offer them a full-time position after a couple of months.
It also seems that people who mail resumes aren't as likely to get a job
as people who hand-deliver them.
As for internet job boards, I never imagined anyone would take them very
seriously, until I started getting a lot of questions from users about them.
It seems a lot of people are under the impression that if they submit their
resume someplace on line, a job will magically find them. Huh? Who wants
to hire someone so lazy that they don't even want to apply for individual
jobs, but just wait for their ship to come in?
> Also you have no way of knowing the email address it will come from to add
> it to a whitelist.
You almost always know the domain it's going to come from, and you almost
always know (within a couple of minutes) when it's going to come, so you
could set your filter to a mode where it holds probably-spam messages in
quarantine and use a web interface to pick the one in question off the list.
False positives that can be *predicted* aren't the problem. What worries
me more is the ones that would surprise us. Like I said upthread, if I
have to go through the list of all the spam messages looking for false
positives, then the system is no better than what I have now, wherein (most
of) my spam stays in my inbox and almost all of my legitimate mail gets
picked up by various regex filters and sorted into folders. Then I look
through the list of messages in the inbox and mass-move them out to a spam
folder, but I glance over the list as I do it, checking for legit messages
that my filters missed. Any spam filtering method that proposes to beat
this approach has to absolutely guarantee to get zero false positives, and
I have to believe it. Only then can I stop looking through the list for
the occasional message that should have gone into the real mail folder.
> Most mailinglists and newsletters are one way
Newsletters and announcement lists are one way, but they send mail only
once every week/month/whatever. Spammers send 24/7 pretty much. I'm not
sure how well the method deals with that difference, but it is potentially
possible to devise one that does.
Discussion lists of course are a no-brainer, because there's traffic going
out from the users to the list.
The other way to deal with announcement lists of course is to have the user
add them to a whitelist when they sign up for the list. This would not be
something you'd want to do at an ISP level (at least not for all users --
maybe for users who knowingly sign up for it), but it would be something
people who get a lot of spam could resort to relatively painlessly; it's
already a multi-step process to sign up for most such lists, giving them
your address in usually a web-form, getting a confirmation message, going
to the special tokenized address it gives you... adding one extra step to
that process (whitelist the sender) would be an annoyance, but for those of
us who get a lot of spam it would be less of an annoyance than the spam.
I must say, I am dubious about the claims of no false positives, but if it
proves to be true, sign me up. False positives are the bane of bayesian
filtering -- what good is it if you have to go through the spam folder to
make sure there aren't any false positives? At that point you might as well
filter your real mail off into folders, let the spam fall into the inbox,
and go through it there to check for real mail that got missed. (This is
what I currently do, although I filter some spam off into folders using
methods that don't get false positives, so that I don't have to look through
them. Filtering on character set is my most effective technique for this; it
can't possibly get false positives because the idea of a legitimate message
in a character set I can't read is as far as I'm concerned inherently
oxymoronic; even on the off chance that the sender is not a spammer, the
message is still not one that I can usefully read.)
> It seems to me that the Linux/Open Source community has already chosen .net
.GNU developers and fans, .NET. What's .NET. (Well, sortof. They use the VB.NET and .NET doesn't actually matter to them.)
.net and Microsoft on this site. I just can't figure it out.
Sure, but what do toplevel domain suffices have to do with Java?</rimshot>
Seriously, apart from a small handful of Mono and
I think most people in the OSS community are utterly ignoring
perhaps more telling is that most people in the Windows development community
are also apparently ignoring
C# compilers, but they don't write their software any differently than before;
to them it's just the next version of VB or Visual C++. In other words, the
existence of
> it's sad really... There are much more complaints about Sun and Java than
> against
There are more (meaningful) complaints about Sun and Java because they're
more relevant. (Actually, there are plenty of complaints about Microsoft too,
but you'll notice that they're mostly terse jibes. This is because the
complaints that would have substance don't need to be stated; they are already
well-understood by all concerned.)
Java has a pretty good following. About as good as Python, approximately.
Which is to say, setting aside the Most Ubiquitous Lanuage Ever (i.e., C)
as unfair competition entrenched for historical reasons, Java still scores
at best a very distant third place after Perl and C++, which are vastly more
popular. The success of C++ can be linked to that of C, since it's based on
it. The reasons for the success of Perl are less obvious, but I think most
of them can be attributed directly to the personality of Larry Wall. For
example, chapters 1 and 2 of the Camel book do an impressive job (typically)
of making people like the language; these chapters are very typical of Wall's
writing style. (Yes, there were two coauthors, but those chapters reek of
Larry Wall. Compare them to e.g. the Apocalypse articles; you can just *tell*
they're written by the same author.)
I think it's naive of Sun to dismiss Perl because it's a "scripting language".
Perl is not Perl 3 anymore. Nevertheless, I also think it's naive of ESR to
say that Java's place has, due to licensing restrictions, been effectively
ceded to Perl and Python. Python is not so much more popular than Java that
"effectively ceded" makes any sense, and I don't think it's at all clear that
Perl's popularity is mostly due to licensing. If anything, the Perl community
is very divided on the issue of licensing. Perl runs on a wide assortment of
platforms, most of them proprietary, and is very popular among sysadmins and
powerusers on e.g. Windows. Licensing? Mostly irrelevant. You can download
it legally without paying money, what else matters? There is a bias toward
*nix in the Perl community, but proprietary unices are not considered inferior
or looked down upon, at least not generally. (Well, UnixWare is, but that's
another matter.) My take on this is that there's a bias toward *nix *mostly*
because *nix systems all come with Perl out of the box. The Perl community
would dearly love to see ActiveState and Microsoft collaborate to include
(a decently recent version of) Perl on Windows systems out of the box; that
would be the icing on the cake for Perl's ubiquity, which is already fairly
impressive. (The decorative flowers on the icing would be a working CPAN.pm
included with the MS/AS OOTB offering, but that's perhaps too much to hope.)
> Going back on topic, let me share what I've learned about troubleshooting
> hardware issues. First, let me stress that it's usually not a hardware issue.
Ah, I see that you use Windows.
> > Note to Daryl: Sue the OS/2 users too.
> What? Both of them?
There are way more than two. At least two orders of magnitude more.