> You're ignoring the reality of the situation. I run a medium-size, > ad-supported website. Last month, I made about $350 from popunder > advertising, $70 from 468x60 banners. I can't run the site on $70. > I barely break even with the $420 total (hosting costs of $250, > syndicated data costs of $200).
Well, I haven't studied the exact business model of your particular site, but there seem to be quite a few sites out there doing just fine without popups; perhaps you could do a case study on one or two of them and see how they pay the bills. Or you could continue to defend your broken business model, which as you admit is barely paying the bills.
As far as claims that the internet will die without popup revenue, that's just plain stupid. The internet was already a tremendous resource sporting a wide assortment of valuable information before the web was invented, to say nothing of javascript. Is it possible some sites will die without popup revenue? Sure; let them die; millions of others will take their place.
> And no TV without advertising? Would that be a bad thing?
Our television antenna died in a wind storm in August. I don't miss it at all. It had gotten so bad, I actually dreaded the times when other people would be home because they would turn it on, and it was nothing but a superfluous source of annoying noise. I have no plans to ever subject myself to television again. Oh, that was August of 2001, BTW.
Go thou to xulplanet and get
thyself the
prefs
toolbar. You need this anyway, to turn page colours off
and on and easily change your user-agent string.
> If they're checking stuff with JS, it's easy to make JS lie > about what's happening
Or just turn off scripting.
> and if they're looking to see if image requests come through... > well, it's easy to request but not display a pop-up.
Yes, but that would consume bandwidth and, more importantly, the time it takes you to mess with it. (Though, if you really want to fool around, it should be trivial to request the item but immediately drop or cancel the request and not retrieve most of it, if it is of any size at all...) Also, caches will cause spurious blocks if they go that way.
So yeah, they used Javascript, which puts you back to turning off javascript like you used to have to do in the bad old days before browsers had fine-grained capability policies. IMO, it's easier to just go to another site.
I'd +1 Informative you, but I already posted in this thread. Sheesh, javascript, they're just full of holes and asking to be abused. I bet you could use the javascript to change the cookie and let yourself into the site.
> (Perhaps the mozilla crew will make a nice interface for per-site > javascript blocking.)
Actually, if I'm not mistaken, a nice interface is all that's lacking. If you want to mess with capability policies, you can do that now. However, it's not worth the trouble; it's easier to just find another site. When AltaVista's advertising got out of control (more than four animated banners per page), I switched to Google, which I've been using since. I _could_ have used a proxy to block the ads, but it would have been a waste of time; switching to Google accomplished the same thing without taking up any of my time maintaining a block list.
> Non intrusive (like non animated gif or java) banners are a-ok
Agreed. I have no problem with advertising per se. Ordinary banners I don't complain about; occasionally, I even follow one. (So far, on occasions that I've followed one, the ad has always been narrowly targeted for the specific content of the page I was viewing; e.g., an ad for shell accounts ("Panix" IIRC) on a website that provided information about using Unix. Ads like that I'm not unhappy about at all. Most of the ones on/. don't bother me too, although the squarish ones that get embedded in the story are mildly annoying because of the way they screw up the layout. But not annoying enough that I'd actually _do_ anything about it, like block them or anything.) If you want me to see your ads, just present them as regular ordinary ads. I have no problem with that.
Popups, however, are totally unacceptable. Until Mozilla added dom.disable-open-during-load, I almost never surfed with Javascript turned on at all, and just skipped most sites that required it. I have other things to do with my time than close a bunch of extra windows all the time. Mozilla doesn't send anything back to the site when it ignores a popup, so they're obviously using some kind of chicanery to determine that; whatever it is, the message is a clear "we don't want you on your site", and believe me, with the size of the web being what it is, I can find another site that will be more hospitable in about the same amount of time it would take me to check the little "popups" checkbox on my prefs toolbar, give or take a couple of seconds. Guess which I'm more likely to do?
This is not an issue of rights; it's an issue of practice. The site (assuming it's a private-sector site, which seems like a reasonable assumption if we're talking about ad revenue) of course has the right to refuse to serve me pages for any reason, even if it's "we don't like the list of languages your browser accepts" or "you are in the same subnet with a former employee, and we didn't like the colour of his trousers". Hey, you want to block me, block me; there's _lots_ of other content on the net.
The thing is, there are two ways this can turn out, depending on how many people find out how to block unrequested windows (which, realistically, depends on whether any major browser ever ships with them blocked by default). If almost nobody blocks popups, then the resources a site expends checking everybody will dwarf the small amount of resources they are ostensibly saving by doing the blocking. That is the current situation. If a major browser (e.g., AOL) ever ships with unrequested popups off by default, then the sites that refuse to switch to other forms of advertising will be locking themselves out of that much traffic and ad revenue. Either way, sites that insist on popups are hurting themselves. And as far as I'm concerned, they're _only_ hurting themselves.
There are other types of advertising I'm also unwilling to view, too. Blatantly fraudulent advertisements (such as the ones that try to pass themselves off as dialog boxes) are Distilled Evil, for example, and if I worked at the FTC I'd try to go after them. It's an offense worthy of jailtime, IMO. I'm not talking about mild marketing optimism, but the outright fraud.
I'm also unwilling to view animations that don't stop. I allow animated GIFs to play through _once_, but no more. Under no circumstances am I willing to surf with Flash enabled.
Sites that require any of these things, I just skip. This means perhaps one in a hundred sites that I was going to view I end up not viewing, but I always find equivalent content on another site (usually in short order) because the web is getting pretty big these days. I think pretty soon there might be more than a million sites, or something. (Ahem.)
I don't see how this is a rights issue, just plain old stupidity.
> I think you mean fixed buffers. Fixed buffers can be either > static or dynamic. malloc is for dynamic buffers. It is used > to allocate memory off the heap during run time.
Well, my C isn't very sharp (haha), but my understanding was that malloc was used to allocate a determined amount of memory (at run time, yes). Granted, char* is even worse. Compare this to Perl, where a buffer overrun is absolutely impossible. C programmers laugh at Perl and call it error-prone because the programmer isn't required to predeclare every variable unless he chooses to use strict, but when was the last time you heard of a Perl programmer dereferencing an invalid pointer? The kind of bug you get if you mistype a variable name is on the order of "the program doesn't work correctly", not a rootable hole in a networking daemon.
Yeah, yeah, performance, but what is security worth to you?
And for all you Perl haters (by which I mean, the Python folks), I'm not saying everything should use Perl. What I am saying is that for stuff where security matters we should use languages with sanity checks on memory usage built into the language; Perl is just one example of such a language.
> True, but why do people have to keep writing > programs with static buffer sizes?
Mostly because they are programming in computer languages that make basic things like storing information in a buffer a pain in the neck for the programmer. As long as we have languages with malloc or the equivalent (C, C++, and all their ilk), we will have buffer overruns and pointer errors and other such nonsense.
> And for what you spent on all those safes, you could easily rent > an insured safety deposit box at your local bank. That's decent for frequent backups (because if it's too inconvenient to get them there you won't take them), but periodically you should send a backup to someplace more distant, by which I mean not in the same city.
> Of course, you know, that means going outside. Aack, we hates the yellow face, don't we my precious? Yes, we hates it. It burns us, scorches our eyeses, doesn't it? Yes, my precious, we don't like it at all, no my precious, nasssty yellow face...
I already _have_ a large repository of spam in a set of folders in my mail repository. The US FTC already has a _huge_ repository of spam. The news.admin.net-abuse people have a positively *enormous* repository of spam from both email and usenet.
Anyway, a large repository of past spam is not really what you want for testing anti-spam solutions, because spammer tactics keep on changing. It used to be that a whitelist solution could trip on unrecognised From: fields, but now they're using the same From: field for everyone. It used to be that you could filter by the IP address of the mailserver used, but these days the mail servers migrate constantly across entire Class B networks. It used to be that you could filter based on subject lines with lots of digits at the end, but these days they're using random sequences of letters, and if you filter based on that they'll switch to Markov chains, which are simple to create and AI-complete to recognize.
For anti-spam testing, what you want is a mail account that never gets anything sent to it _except_ spam, for which you can create infinite alias addresses and release them in strategic places. (You start by designating addresses starting with u as having been released only on usenet, generate a few thousand addresses that start with u, and use them in the From: fields of a bunch of posts to test newsgroups.)
You have to be constantly getting _new_ spam for testing. The old stuff will give you a false sense of how well your stuff is working.
I've heard about screen, but I haven't messed with it much.
The advantage of my approach can be summed up in two words: terminal classes. For example, the terminals that are sshed into pedestrian (my IP-Masq gateway) appear in my task list with the title "Pedestrian" and an icon of a terminal wearing blue shoes, and their colours are set to white on soft light blue. The terminal that I use for the MySQL client appears as "MySQL" in the list, with an icon of a dolphin, and the colours are set to white on dark blue. The one that is tailing a logfile appears as "logtail" with an icon of a terminal with a (wooden) log in front of it, and the colours are yellow on burgundy. The specific details are not important, but the point is I can tell them apart at a glance and easily grab the one I want. It's no harder to switch to MySQL than it is to switch to Gnus.
Re:Wonderful (I was skeptical at first...)
on
Fun With Wine
·
· Score: 2
> It's not that useful (yet) in-and-of-itself
It's not _supposed_ to be useful in-and-of-itself. cygwin is useful, and WINE is useful, but running them inside eachother is a form of testing. Because of the nature of what WINE and cygwin are, there isn't ever going to be a large demand for the need to run them inside one another. (The occasional oddball case where it comes in handy for something, yes, but no large demand.) But being able to do it is an indication that both projects have reached a minimal level of mostly working. (cygwin, in my experience, works a good deal better than WINE; I don't know whether that's because it's a more mature project, or because it's doing an easier job (since what it's doing emulation of is better documented), or because Unix apps are more portable, or some combination, or what.)
When they can run cygwin under Windows under VMWare under Linux under the Windows version of VirtualPC under WINE running on FreeBSD under VirtualPC for the Mac running under MacOS X, then I'll be properly impressed.
Re:Sch! God damn it!
on
Fun With Wine
·
· Score: 3, Informative
> And Mozilla isn't slow.
Mozilla isn't slow, but it has a higher memory footprint than some other browsers (Opera, for example) and a higher _apparent_ memory footprint than IE, from the user's perspective (because the parts of IE that are loaded at bootup time won't be considered as parts of IE by most users). This means that on systems with marginal amounts of RAM, Mozilla is more likely to push you over the edge of your memory into swap, which of course is _noticeably_ slower. This is the phenomenon most often meant when people say Mozilla is slow.
In my case, I've got 512MB of RAM, and after the OS (Linux) and GUI (XFree/Gnome) take their hits the five apps I use most (Emacs, Gnus, Mozilla, Gimp, and gnome-terminal) are welcome to most of the rest. Once a day or so when I fire up something else large (OpenOffice, for example) too, I dip into swap space, but most of the time that's not a problem. But I'm a power user, and I specifically maxed out the RAM on my system so that I could have [counts] fourteen windows open at once (at the moment, 3 Emacsen, the 4 basic Gimp windows (no actual images just now), one Mozilla (9 tabs), and 6 instances of gnome-terminal (in 4 different terminal classes) for various things (one for a MySQL client, two looking at directories where I'm doing two different projects, one tailing a log (related to one of the projects), and two sshed into another system). That's not normal user stuff; most people _don't_ go out and spend extra money on extra RAM, because they _don't_ need to have 14 windows open at once. So for them, if the computer is anything like as old as mine (January 1998 originally, though I haven't had 512MB of RAM that long), Mozilla is indeed going to be "slow".
This is however not a _performance_ issue (from the programmer's standpoint), but a footprint issue, and it will be fading in importance, as new computers are coming with more hefty amounts of RAM these days. (128MB is _way_ more than Mozilla needs, and that's the least a normal system comes with these days.) Yes, apps will continue to grab more of that, but since most users only really run one app at a time... so app developers don't have to _stop_ the growth in the amount of RAM they use, as long as the keep it substantially _slower_ than the growth in the amount of RAM that new computers have. By Netscape 8 timeframe nobody's going to _care_ that it uses 48MB of RAM or more. The people who _do_ run multiple apps at once (such as myself) can pick up a little extra RAM; it's cheap these days. By the time Netscape 9 comes out, it can probably get away with using 64MB or more, since three-year-old off-the-shelf systems (being sold today) will have 128 to work with en total, and new systems will be selling with more like 512 or more. (Of course that number is guesstimated.)
Code optimization from the compiler doesn't really matter; it's keeping it from swapping that will save your day in terms of apparent performance. The difference between well-optimized code and poorly-optimized code, in terms of CPU time, is subliminal; most people need benchmarks to even determine whether there _is_ a difference. But if you run out of physical RAM and start using swap space, the user can measure the delay with something no more precise than an analog watch.
I've switched now, but the thing that kept me on
Windows for over a year when I otherwise would have
switched was email. All the graphical email clients for Linux are totally inadequate. I ended up going with Gnus, which is _still_ missing one or two of the features I was accustomed to using in
Pegasus Mail.
(Granted, Gnus also has numerous features that pmail lacks, but I wasn't accustomed to using those.
I tried using Pegasus Mail under WINE, but the
performance was lousy and many of the widgets
weren't rendered correctly. I tried other email
apps, but they all were missing features that I
couldn't live without. (I get a lot of email.
A lot of email. I have
to have advanced filtering (regexes, yes, but
also advanced in terms of what it can do to the
message; one of the features I miss in Gnus is
that my filters can't cause a message to appear
in the message list highligted in certain colours I miss that feature on a daily basis) and folder management facilities
just in order to function.
I don't understand how people can function
with things like Mozilla mail and Evolution.
For me, they just don't cut the mustard.
I'm getting by with Gnus for the moment,
but there are issues. It's not
multithreaded. It doesn't gracefully handle
an unreliable or missing connection, which
matters to those of us on
dialup. There's the aforementioned lack of
ability for the filters to set a color for
the message's entry in the summary buffer.
(This last I could fix in lisp, if I got off
my butt and got more familiar with the Gnus
internals, but the other two are probably
beyond me.)
So, on the ballance, I'm still looking for an excellent mail client for Linux.
I have everything else that I need (well, at
least everything that I had under Windows;
there are things I'd like that are not available
on either platforms, but we'll save the outright
dreams for another discussion), but this one
category of application, I had a good one under
Windows, and there's nothing to rival it that
will run natively in Linux. I'm making do, but
I still want my Pegasus Mail back.
More like the impossible amount of administrative overhead.
Whitelists are a good concept, but they don't scale well. A whitelist of even as many as twenty sites is too much for one person to manage, if the sites have any significant depth to them (depth in terms of the number of pages and their nestedness, I mean). On the other hand, a whitelist of only twenty sites is basically useless if you want the kids to have any real ability to explore. In a month, they'll have visited what they're interested in and be looking for something new.
This isn't to say whitelists have no value. They are useful in, for example, an educational context, where you want to allow kids to have unsupervised access to, say, an encyclopedia and an atlas and a couple of things like that. But it won't be anything like having internet access. Sure, it would technically be a subset of the internet, but the subset is so small that the experience is not the same at all.
The purpose of whitelists, of course, is to reduce the need for supervision. But you can't scale them up to the size of the whole internet; it simply won't work. The administrative overhead of checking all the sites on the whitelist to make sure the content on all of the pages hasn't changed and become unsuitable is too high; it won't be possible to maintain it. It is well-intentioned and will start out alright, but it won't be any time at all before it degenerates to the point where kids need supervision. Which puts us right back where we have always been.
Anyway, the whole idea of removing the need for supervision is not really such a good idea, on the whole. Kids don't just need supervision to make sure they behave; they also need supervision because they need interaction with an adult on a constant basis. It's important for their development. Parents need to spend time with their kids; is that such a hard concept? Supervising them shouldn't be seen as a burden for society to eliminate by clever things like whitelists, but as a normal part of having a family.
> Interesting, I'd go check that out right now had I not
Verse 1 says, approximately, "In the beginning there was the Word, and the Word was with God, and the Word was God." (There are other legitimate ways to translate the first clause. You can, for example, say "In the beginning the Word was" or "In the beginning was the Word", and be just as accurate. But the first clause is not what bothers the JWs. "Word" can also be "Message", but again, this is not the point of dispute. Either way, it's Jesus, for proof of which see verses 14-15, "The Word became flesh and lived among us, and we have viewed his glory, the glory of the one and only who came from the Father... John testifies concerning him..." Not even the JWs dispute that the Word in this passage is Jesus.)
Anyway... in the Greek, that last clause reads verbatim as "God was the Word", except that because of where the article is put the Word is the subject of the sentence. (Greek does not put the subject first all the time as in English; we have to rearrange the word order to put the subject first, because as your English teacher taught you that's just how it has to be in English.) For it to be translated "a god" as the JWs insist the Greek word order would have to be reversed, among other things. If you try to throw out the rules of basic grammar that cause it to be translated "the Word was God", you mess up how the subject of a sentence is indicated and recognised, and most of what is written in Greek becomes incoherent. IOW, "was God" is the only reasonable way it can be translated, and the greatest emphasis is on the word God because it is first in the clause.
So any group that claims to believe the Bible but disagrees with the deity of Christ -- including JWs, Mormons, and Islam -- have issues with this passage. (Islam mostly gets around it by simply saying that the Bible was mistaken or unclear and the Koran is authoritative. JWs and Mormons try too hard to keep their "we believe the Bible" stance, so the issue is more fatal for them.)
When I read that part of the policy, I decided Microsoft could have my identifying information when they pry it from my cold dead keyboard. Whether they actually _exercise_ the privileges that EULA gives them I don't intend to test, at least not with data I value.
I'm not a big privacy nut. Really, I'm not. I don't use encryption, don't hide my email address (even on usenet), and have my physical address on my website (and, IIRC, a phone number too). But I recall distinctly that something I read in the EULA for Hotmail scared me, and it had to do with how MS was going to redistribute the info they were collecting.
I suppose I could have just signed up with _false_ information, but on the other hand I could also just not use their service.
Err, that should read, "Mozilla _was_ really buggy". It crashed all the time, until circa 0.9.5 or so, then got progressively more stable until 1.0.1. (1.1 and 1.2 have slipped a bit in terms of stability, but that was expected, as they're for feature work.)
Most of them are duplicates, but the nice thing is, Bugzilla makes it easy to track such things. Bugzilla _was_ really buggy. The speed with which it shaped up during the second half of 2001 is at least partly due to Bugzilla; once a critical mass of serious testers get involved with using Bugzilla for its intended purpose, the developers don't have to waste extra time tracking bugs down. If a bug report doesn't have enough details, they just mark it qawanted, comment about what information is needed, and future it until one of the testers coughs up some details -- and someone will, if the bug is at all critical.
> and people that write buggy browsers will somehow write a non-buggy > bug tracking system?
Mozilla is written in C, C++, XUL, and JavaScript, and has to run on innumerable platforms and display under innumerable GUIs.
Bugzilla is written in Perl and HTML and has to run under Linux and display on the web. It's an easier thing.
That said, Bugzilla is extremely useful and convenient, _much_ more functional than other competing issue-tracking systems. There's a reason other large projects (OpenOffice, Gnome, and now maybe the Linux kernel) are adopting it: it's best-of-breed issue-tracking software.
Did anyone else notice that the version over at ODSL (for the Linux kernel) has an added feature that b.m.o. doesn't have, where you can set a pref so that after changing a bug you view that bug again instead of going on to the next bug that matches your most recent search criteria? That's quite cool; I hope b.m.o. gets that too.
Either that, or Chinese and Korean spambots are harvesting my address from usenet summaries. Or both.
A spammer can easily forge extra Received: headers to make it seem as if the message only passed through the originating server, but it's much harder (impossible?) to do the reverse, and make it appear as if the message originated someplace that it only passed through. I get metric tonnes of spam that _originates_ in southeast Asia. Most of it is written in character sets I can't read, which as far as I'm concerned is a good thing, because that makes it easier to tell apart from legitimate messages. I just wish it would all specify the character set in the Content-type: header, so I could filter _all_ the Chinese and Korean stuff into the spam folder. As it stands, about half of the foreign spam I get declares the charset, and the other half is harder to filter, because it either doesn't declare or uses a language-ambiguous charset (e.g., UTF8).
I do also get spam written in English, some of which originates in Asia and some of which doesn't. But the really overwhelming deluge is the foreign stuff.
And while we're on the subject of the FTC going after fraud... I sure wish they'd decide that forged headers are fraud and go after the perpetrators who do that. Spam would be a whole lot easier to filter if the data in the From field and/or Return-Path had to contain the actual originating domain.
> This might be due to the Klez virus or a variant.
It's also standard spammer practice when advertising a website. They don't need or want an email response in that case, so they forge the From and Reply-To headers (and usually Return-Path also) with one of several things:
1. A throwaway account (usually hotmail or Yahoo)
2. An arbitrary invalid address generated at random,
at least the username portion. (The domain may
be any valid domain, not necessarily with any
affiliation to the spammer.)
3. Any random valid address from the lists
4. An address generated from your address in some way.
For example, your username at a different domain,
or a different username at your domain, or your name
with numbers added at your domain, or somesuch.
5. Occasionally I see an address that's @localhost in one
of the headers. Case 3 is the one the other poster was talking about, and it's not hard to verify that they do this. (Proving it in court could be tricky, but if you investigate a number of instances it's pretty easy to be quite sure enough for everyday purposes.)
They often put something in the URL that uniquely IDs your address so they know whether you visit the site in question, and that's that. No need to get an email reply, so they just forge the headers to make themselves harder to pin down. (You can always pin down who owns the site from the DNS record (unless it's IP only and in APNIC with no reverse lookup, aaarrgh), but you can't easily tell _who_ they hired to do the dirty work, especially when the SMTP server is sitting inside APNIC with no reverse lookup and upstream providers who aren't cooperative with antispam investigations.) Any response they want to actually receive from you will come from the website, after you've verified that your address receives mail by going and visiting the URL in question, with the unique token. (Often the unique token is obviously visible when you scritinize the URL, occasionally even as obvious as a question-mark followed by a trivial munging of your address, sometimes slighty more devious (a better munging) but still transparent to close scrutiny. I suspect that sometimes it's more cleverly disguised, however, maybe even embedded in the filename; those all-number filenames make me suspicious...)
Slashdot Mirror
> You're ignoring the reality of the situation. I run a medium-size,
> ad-supported website. Last month, I made about $350 from popunder
> advertising, $70 from 468x60 banners. I can't run the site on $70.
> I barely break even with the $420 total (hosting costs of $250,
> syndicated data costs of $200).
Well, I haven't studied the exact business model of your particular
site, but there seem to be quite a few sites out there doing just
fine without popups; perhaps you could do a case study on one or
two of them and see how they pay the bills. Or you could continue
to defend your broken business model, which as you admit is barely
paying the bills.
As far as claims that the internet will die without popup revenue,
that's just plain stupid. The internet was already a tremendous
resource sporting a wide assortment of valuable information before
the web was invented, to say nothing of javascript. Is it possible
some sites will die without popup revenue? Sure; let them die;
millions of others will take their place.
> And no TV without advertising? Would that be a bad thing?
Our television antenna died in a wind storm in August. I don't
miss it at all. It had gotten so bad, I actually dreaded the
times when other people would be home because they would turn it
on, and it was nothing but a superfluous source of annoying noise.
I have no plans to ever subject myself to television again. Oh,
that was August of 2001, BTW.
Now, if only the VCR would break...
Go thou to xulplanet and get thyself the prefs toolbar. You need this anyway, to turn page colours off and on and easily change your user-agent string.
> If they're checking stuff with JS, it's easy to make JS lie
> about what's happening
Or just turn off scripting.
> and if they're looking to see if image requests come through...
> well, it's easy to request but not display a pop-up.
Yes, but that would consume bandwidth and, more importantly,
the time it takes you to mess with it. (Though, if you really
want to fool around, it should be trivial to request the item
but immediately drop or cancel the request and not retrieve most
of it, if it is of any size at all...) Also, caches will cause
spurious blocks if they go that way.
So yeah, they used Javascript, which puts you back to turning
off javascript like you used to have to do in the bad old days
before browsers had fine-grained capability policies. IMO, it's
easier to just go to another site.
I'd +1 Informative you, but I already posted in this thread. Sheesh,
javascript, they're just full of holes and asking to be abused. I
bet you could use the javascript to change the cookie and let yourself
into the site.
You're right, this is fun!
> (Perhaps the mozilla crew will make a nice interface for per-site
> javascript blocking.)
Actually, if I'm not mistaken, a nice interface is all that's
lacking. If you want to mess with capability policies, you can
do that now. However, it's not worth the trouble; it's easier
to just find another site. When AltaVista's advertising got out
of control (more than four animated banners per page), I switched
to Google, which I've been using since. I _could_ have used a
proxy to block the ads, but it would have been a waste of time;
switching to Google accomplished the same thing without taking
up any of my time maintaining a block list.
> Non intrusive (like non animated gif or java) banners are a-ok
/. don't bother me too, although the
Agreed. I have no problem with advertising per se. Ordinary banners
I don't complain about; occasionally, I even follow one. (So far, on
occasions that I've followed one, the ad has always been narrowly
targeted for the specific content of the page I was viewing; e.g., an
ad for shell accounts ("Panix" IIRC) on a website that provided
information about using Unix. Ads like that I'm not unhappy about
at all. Most of the ones on
squarish ones that get embedded in the story are mildly annoying
because of the way they screw up the layout. But not annoying
enough that I'd actually _do_ anything about it, like block them or anything.) If you want me to see your ads, just present them as
regular ordinary ads. I have no problem with that.
Popups, however, are totally unacceptable. Until Mozilla added
dom.disable-open-during-load, I almost never surfed with Javascript
turned on at all, and just skipped most sites that required it.
I have other things to do with my time than close a bunch of extra
windows all the time. Mozilla doesn't send anything back to the
site when it ignores a popup, so they're obviously using some kind
of chicanery to determine that; whatever it is, the message is a
clear "we don't want you on your site", and believe me, with the
size of the web being what it is, I can find another site that will
be more hospitable in about the same amount of time it would take
me to check the little "popups" checkbox on my prefs toolbar, give
or take a couple of seconds. Guess which I'm more likely to do?
This is not an issue of rights; it's an issue of practice. The
site (assuming it's a private-sector site, which seems like a
reasonable assumption if we're talking about ad revenue) of course
has the right to refuse to serve me pages for any reason, even if
it's "we don't like the list of languages your browser accepts" or
"you are in the same subnet with a former employee, and we didn't
like the colour of his trousers". Hey, you want to block me, block
me; there's _lots_ of other content on the net.
The thing is, there are two ways this can turn out, depending on
how many people find out how to block unrequested windows (which,
realistically, depends on whether any major browser ever ships with
them blocked by default). If almost nobody blocks popups, then the
resources a site expends checking everybody will dwarf the small
amount of resources they are ostensibly saving by doing the blocking.
That is the current situation. If a major browser (e.g., AOL) ever
ships with unrequested popups off by default, then the sites that
refuse to switch to other forms of advertising will be locking
themselves out of that much traffic and ad revenue. Either way,
sites that insist on popups are hurting themselves. And as far
as I'm concerned, they're _only_ hurting themselves.
There are other types of advertising I'm also unwilling to view,
too. Blatantly fraudulent advertisements (such as the ones that
try to pass themselves off as dialog boxes) are Distilled Evil, for
example, and if I worked at the FTC I'd try to go after them. It's
an offense worthy of jailtime, IMO. I'm not talking about mild
marketing optimism, but the outright fraud.
I'm also unwilling to view animations that don't stop. I allow
animated GIFs to play through _once_, but no more. Under no
circumstances am I willing to surf with Flash enabled.
Sites that require any of these things, I just skip. This means
perhaps one in a hundred sites that I was going to view I end up
not viewing, but I always find equivalent content on another site
(usually in short order) because the web is getting pretty big
these days. I think pretty soon there might be more than a million
sites, or something. (Ahem.)
I don't see how this is a rights issue, just plain old stupidity.
> I think you mean fixed buffers. Fixed buffers can be either
> static or dynamic. malloc is for dynamic buffers. It is used
> to allocate memory off the heap during run time.
Well, my C isn't very sharp (haha), but my understanding was that
malloc was used to allocate a determined amount of memory (at run
time, yes). Granted, char* is even worse. Compare this to Perl,
where a buffer overrun is absolutely impossible. C programmers
laugh at Perl and call it error-prone because the programmer isn't
required to predeclare every variable unless he chooses to use
strict, but when was the last time you heard of a Perl programmer
dereferencing an invalid pointer? The kind of bug you get if you
mistype a variable name is on the order of "the program doesn't
work correctly", not a rootable hole in a networking daemon.
Yeah, yeah, performance, but what is security worth to you?
And for all you Perl haters (by which I mean, the Python folks),
I'm not saying everything should use Perl. What I am saying is
that for stuff where security matters we should use languages with
sanity checks on memory usage built into the language; Perl is
just one example of such a language.
> True, but why do people have to keep writing
> programs with static buffer sizes?
Mostly because they are programming in computer
languages that make basic things like storing
information in a buffer a pain in the neck for the
programmer. As long as we have languages with
malloc or the equivalent (C, C++, and all their
ilk), we will have buffer overruns and pointer
errors and other such nonsense.
> And for what you spent on all those safes, you could easily rent
> an insured safety deposit box at your local bank.
That's decent for frequent backups (because if it's too inconvenient to
get them there you won't take them), but periodically you should send
a backup to someplace more distant, by which I mean not in the same
city.
> Of course, you know, that means going outside.
Aack, we hates the yellow face, don't we my precious? Yes, we hates
it. It burns us, scorches our eyeses, doesn't it? Yes, my precious,
we don't like it at all, no my precious, nasssty yellow face...
I already _have_ a large repository of spam in a set of folders
in my mail repository. The US FTC already has a _huge_ repository
of spam. The news.admin.net-abuse people have a positively
*enormous* repository of spam from both email and usenet.
Anyway, a large repository of past spam is not really what you want
for testing anti-spam solutions, because spammer tactics keep on
changing. It used to be that a whitelist solution could trip on
unrecognised From: fields, but now they're using the same From:
field for everyone. It used to be that you could filter by the
IP address of the mailserver used, but these days the mail servers
migrate constantly across entire Class B networks. It used to be
that you could filter based on subject lines with lots of digits
at the end, but these days they're using random sequences of
letters, and if you filter based on that they'll switch to Markov
chains, which are simple to create and AI-complete to recognize.
For anti-spam testing, what you want is a mail account that never
gets anything sent to it _except_ spam, for which you can create
infinite alias addresses and release them in strategic places.
(You start by designating addresses starting with u as having been
released only on usenet, generate a few thousand addresses that
start with u, and use them in the From: fields of a bunch of posts
to test newsgroups.)
You have to be constantly getting _new_ spam for testing. The old
stuff will give you a false sense of how well your stuff is working.
I've heard about screen, but I haven't messed with it much.
The advantage of my approach can be summed up in two words: terminal
classes. For example, the terminals that are sshed into pedestrian
(my IP-Masq gateway) appear in my task list with the title "Pedestrian"
and an icon of a terminal wearing blue shoes, and their colours are
set to white on soft light blue. The terminal that I use for the
MySQL client appears as "MySQL" in the list, with an icon of a
dolphin, and the colours are set to white on dark blue. The one that
is tailing a logfile appears as "logtail" with an icon of a terminal
with a (wooden) log in front of it, and the colours are yellow on
burgundy. The specific details are not important, but the point is
I can tell them apart at a glance and easily grab the one I want.
It's no harder to switch to MySQL than it is to switch to Gnus.
> It's not that useful (yet) in-and-of-itself
It's not _supposed_ to be useful in-and-of-itself. cygwin is useful,
and WINE is useful, but running them inside eachother is a form of
testing. Because of the nature of what WINE and cygwin are, there
isn't ever going to be a large demand for the need to run them inside
one another. (The occasional oddball case where it comes in handy
for something, yes, but no large demand.) But being able to do it
is an indication that both projects have reached a minimal level of
mostly working. (cygwin, in my experience, works a good deal better
than WINE; I don't know whether that's because it's a more mature
project, or because it's doing an easier job (since what it's doing
emulation of is better documented), or because Unix apps are more
portable, or some combination, or what.)
When they can run cygwin under Windows under VMWare under Linux
under the Windows version of VirtualPC under WINE running on
FreeBSD under VirtualPC for the Mac running under MacOS X, then
I'll be properly impressed.
> And Mozilla isn't slow.
Mozilla isn't slow, but it has a higher memory footprint than some
other browsers (Opera, for example) and a higher _apparent_ memory
footprint than IE, from the user's perspective (because the parts
of IE that are loaded at bootup time won't be considered as parts
of IE by most users). This means that on systems with marginal
amounts of RAM, Mozilla is more likely to push you over the edge of
your memory into swap, which of course is _noticeably_ slower. This
is the phenomenon most often meant when people say Mozilla is slow.
In my case, I've got 512MB of RAM, and after the OS (Linux) and GUI
(XFree/Gnome) take their hits the five apps I use most (Emacs, Gnus,
Mozilla, Gimp, and gnome-terminal) are welcome to most of the rest.
Once a day or so when I fire up something else large (OpenOffice,
for example) too, I dip into swap space, but most of the time that's
not a problem. But I'm a power user, and I specifically maxed out
the RAM on my system so that I could have [counts] fourteen windows
open at once (at the moment, 3 Emacsen, the 4 basic Gimp windows
(no actual images just now), one Mozilla (9 tabs), and 6 instances
of gnome-terminal (in 4 different terminal classes) for various
things (one for a MySQL client, two looking at directories where
I'm doing two different projects, one tailing a log (related to one
of the projects), and two sshed into another system). That's not
normal user stuff; most people _don't_ go out and spend extra money
on extra RAM, because they _don't_ need to have 14 windows open at
once. So for them, if the computer is anything like as old as mine
(January 1998 originally, though I haven't had 512MB of RAM that
long), Mozilla is indeed going to be "slow".
This is however not a _performance_ issue (from the programmer's
standpoint), but a footprint issue, and it will be fading in
importance, as new computers are coming with more hefty amounts of
RAM these days. (128MB is _way_ more than Mozilla needs, and
that's the least a normal system comes with these days.) Yes,
apps will continue to grab more of that, but since most users
only really run one app at a time... so app developers don't
have to _stop_ the growth in the amount of RAM they use, as long
as the keep it substantially _slower_ than the growth in the amount
of RAM that new computers have. By Netscape 8 timeframe nobody's
going to _care_ that it uses 48MB of RAM or more. The people who
_do_ run multiple apps at once (such as myself) can pick up a
little extra RAM; it's cheap these days. By the time Netscape 9
comes out, it can probably get away with using 64MB or more, since
three-year-old off-the-shelf systems (being sold today) will have
128 to work with en total, and new systems will be selling with
more like 512 or more. (Of course that number is guesstimated.)
Code optimization from the compiler doesn't really matter; it's
keeping it from swapping that will save your day in terms of
apparent performance. The difference between well-optimized code
and poorly-optimized code, in terms of CPU time, is subliminal;
most people need benchmarks to even determine whether there _is_
a difference. But if you run out of physical RAM and start using
swap space, the user can measure the delay with something no more
precise than an analog watch.
I've switched now, but the thing that kept me on Windows for over a year when I otherwise would have switched was email. All the graphical email clients for Linux are totally inadequate. I ended up going with Gnus, which is _still_ missing one or two of the features I was accustomed to using in Pegasus Mail. (Granted, Gnus also has numerous features that pmail lacks, but I wasn't accustomed to using those.
I tried using Pegasus Mail under WINE, but the performance was lousy and many of the widgets weren't rendered correctly. I tried other email apps, but they all were missing features that I couldn't live without. (I get a lot of email. A lot of email. I have to have advanced filtering (regexes, yes, but also advanced in terms of what it can do to the message; one of the features I miss in Gnus is that my filters can't cause a message to appear in the message list highligted in certain colours I miss that feature on a daily basis) and folder management facilities just in order to function.
I don't understand how people can function with things like Mozilla mail and Evolution. For me, they just don't cut the mustard.
I'm getting by with Gnus for the moment, but there are issues. It's not multithreaded. It doesn't gracefully handle an unreliable or missing connection, which matters to those of us on dialup. There's the aforementioned lack of ability for the filters to set a color for the message's entry in the summary buffer. (This last I could fix in lisp, if I got off my butt and got more familiar with the Gnus internals, but the other two are probably beyond me.)
So, on the ballance, I'm still looking for an excellent mail client for Linux. I have everything else that I need (well, at least everything that I had under Windows; there are things I'd like that are not available on either platforms, but we'll save the outright dreams for another discussion), but this one category of application, I had a good one under Windows, and there's nothing to rival it that will run natively in Linux. I'm making do, but I still want my Pegasus Mail back.
I believe you misunderstood what he was saying. You might want to look up the word uqiquitous before disagreeing about what is ubiquitous.
> It could be because of lack of real demand.
More like the impossible amount of administrative overhead.
Whitelists are a good concept, but they don't scale well. A whitelist
of even as many as twenty sites is too much for one person to manage,
if the sites have any significant depth to them (depth in terms of the
number of pages and their nestedness, I mean). On the other hand, a
whitelist of only twenty sites is basically useless if you want the
kids to have any real ability to explore. In a month, they'll have
visited what they're interested in and be looking for something new.
This isn't to say whitelists have no value. They are useful in, for
example, an educational context, where you want to allow kids to have
unsupervised access to, say, an encyclopedia and an atlas and a
couple of things like that. But it won't be anything like having
internet access. Sure, it would technically be a subset of the
internet, but the subset is so small that the experience is not the
same at all.
The purpose of whitelists, of course, is to reduce the need for
supervision. But you can't scale them up to the size of the whole
internet; it simply won't work. The administrative overhead of
checking all the sites on the whitelist to make sure the content
on all of the pages hasn't changed and become unsuitable is too
high; it won't be possible to maintain it. It is well-intentioned
and will start out alright, but it won't be any time at all before
it degenerates to the point where kids need supervision. Which
puts us right back where we have always been.
Anyway, the whole idea of removing the need for supervision is
not really such a good idea, on the whole. Kids don't just need
supervision to make sure they behave; they also need supervision
because they need interaction with an adult on a constant basis.
It's important for their development. Parents need to spend time
with their kids; is that such a hard concept? Supervising them
shouldn't be seen as a burden for society to eliminate by clever
things like whitelists, but as a normal part of having a family.
> Interesting, I'd go check that out right now had I not
Verse 1 says, approximately, "In the beginning there was the Word,
and the Word was with God, and the Word was God." (There are other
legitimate ways to translate the first clause. You can, for example,
say "In the beginning the Word was" or "In the beginning was the
Word", and be just as accurate. But the first clause is not what
bothers the JWs. "Word" can also be "Message", but again, this is
not the point of dispute. Either way, it's Jesus, for proof of
which see verses 14-15, "The Word became flesh and lived among us,
and we have viewed his glory, the glory of the one and only who
came from the Father... John testifies concerning him..." Not
even the JWs dispute that the Word in this passage is Jesus.)
Anyway... in the Greek, that last clause reads verbatim as "God
was the Word", except that because of where the article is put the
Word is the subject of the sentence. (Greek does not put the
subject first all the time as in English; we have to rearrange
the word order to put the subject first, because as your English
teacher taught you that's just how it has to be in English.) For
it to be translated "a god" as the JWs insist the Greek word order
would have to be reversed, among other things. If you try to
throw out the rules of basic grammar that cause it to be translated
"the Word was God", you mess up how the subject of a sentence is
indicated and recognised, and most of what is written in Greek
becomes incoherent. IOW, "was God" is the only reasonable way
it can be translated, and the greatest emphasis is on the word
God because it is first in the clause.
So any group that claims to believe the Bible but disagrees with
the deity of Christ -- including JWs, Mormons, and Islam -- have
issues with this passage. (Islam mostly gets around it by simply
saying that the Bible was mistaken or unclear and the Koran is
authoritative. JWs and Mormons try too hard to keep their "we
believe the Bible" stance, so the issue is more fatal for them.)
> Ummm, you did choose to opt-out of that, yes?
When I read that part of the policy, I decided Microsoft could have
my identifying information when they pry it from my cold dead
keyboard. Whether they actually _exercise_ the privileges that EULA
gives them I don't intend to test, at least not with data I value.
I'm not a big privacy nut. Really, I'm not. I don't use encryption,
don't hide my email address (even on usenet), and have my physical
address on my website (and, IIRC, a phone number too). But I recall
distinctly that something I read in the EULA for Hotmail scared me,
and it had to do with how MS was going to redistribute the info
they were collecting.
I suppose I could have just signed up with _false_ information, but
on the other hand I could also just not use their service.
> Bugzilla _was_ really buggy
Err, that should read, "Mozilla _was_ really buggy". It crashed
all the time, until circa 0.9.5 or so, then got progressively more
stable until 1.0.1. (1.1 and 1.2 have slipped a bit in terms of
stability, but that was expected, as they're for feature work.)
Most of them are duplicates, but the nice thing is, Bugzilla makes
it easy to track such things. Bugzilla _was_ really buggy. The
speed with which it shaped up during the second half of 2001 is
at least partly due to Bugzilla; once a critical mass of serious
testers get involved with using Bugzilla for its intended purpose,
the developers don't have to waste extra time tracking bugs down.
If a bug report doesn't have enough details, they just mark it
qawanted, comment about what information is needed, and future it
until one of the testers coughs up some details -- and someone will,
if the bug is at all critical.
> and people that write buggy browsers will somehow write a non-buggy
> bug tracking system?
Mozilla is written in C, C++, XUL, and JavaScript, and has to run
on innumerable platforms and display under innumerable GUIs.
Bugzilla is written in Perl and HTML and has to run under Linux
and display on the web. It's an easier thing.
That said, Bugzilla is extremely useful and convenient, _much_ more
functional than other competing issue-tracking systems. There's a
reason other large projects (OpenOffice, Gnome, and now maybe the
Linux kernel) are adopting it: it's best-of-breed issue-tracking
software.
Did anyone else notice that the version over at ODSL (for the Linux
kernel) has an added feature that b.m.o. doesn't have, where you
can set a pref so that after changing a bug you view that bug again
instead of going on to the next bug that matches your most recent
search criteria? That's quite cool; I hope b.m.o. gets that too.
Either that, or Chinese and Korean spambots are harvesting my address
from usenet summaries. Or both.
A spammer can easily forge extra Received: headers to make it seem
as if the message only passed through the originating server, but
it's much harder (impossible?) to do the reverse, and make it appear
as if the message originated someplace that it only passed through.
I get metric tonnes of spam that _originates_ in southeast Asia.
Most of it is written in character sets I can't read, which as far
as I'm concerned is a good thing, because that makes it easier to
tell apart from legitimate messages. I just wish it would all
specify the character set in the Content-type: header, so I could
filter _all_ the Chinese and Korean stuff into the spam folder.
As it stands, about half of the foreign spam I get declares the
charset, and the other half is harder to filter, because it either
doesn't declare or uses a language-ambiguous charset (e.g., UTF8).
I do also get spam written in English, some of which originates in
Asia and some of which doesn't. But the really overwhelming deluge
is the foreign stuff.
And while we're on the subject of the FTC going after fraud... I
sure wish they'd decide that forged headers are fraud and go after
the perpetrators who do that. Spam would be a whole lot easier to
filter if the data in the From field and/or Return-Path had to
contain the actual originating domain.
> This might be due to the Klez virus or a variant.
It's also standard spammer practice when advertising a website.
They don't need or want an email response in that case, so they
forge the From and Reply-To headers (and usually Return-Path
also) with one of several things:
1. A throwaway account (usually hotmail or Yahoo)
2. An arbitrary invalid address generated at random,
at least the username portion. (The domain may
be any valid domain, not necessarily with any
affiliation to the spammer.)
3. Any random valid address from the lists
4. An address generated from your address in some way.
For example, your username at a different domain,
or a different username at your domain, or your name
with numbers added at your domain, or somesuch.
5. Occasionally I see an address that's @localhost in one
of the headers.
Case 3 is the one the other poster was talking about, and it's not
hard to verify that they do this. (Proving it in court could be
tricky, but if you investigate a number of instances it's pretty
easy to be quite sure enough for everyday purposes.)
They often put something in the URL that uniquely IDs your address
so they know whether you visit the site in question, and that's
that. No need to get an email reply, so they just forge the headers
to make themselves harder to pin down. (You can always pin down who
owns the site from the DNS record (unless it's IP only and in APNIC
with no reverse lookup, aaarrgh), but you can't easily tell _who_
they hired to do the dirty work, especially when the SMTP server is
sitting inside APNIC with no reverse lookup and upstream providers
who aren't cooperative with antispam investigations.) Any response
they want to actually receive from you will come from the website, after you've verified that your address receives mail by going and
visiting the URL in question, with the unique token. (Often the
unique token is obviously visible when you scritinize the URL,
occasionally even as obvious as a question-mark followed by a
trivial munging of your address, sometimes slighty more devious
(a better munging) but still transparent to close scrutiny. I
suspect that sometimes it's more cleverly disguised, however, maybe
even embedded in the filename; those all-number filenames make me
suspicious...)