> Excuse me, but that's only the positive half of the equation.
No, ecconomics doesn't work that way. It's not zero-sum. It doesn't have a positive half and a negative half that balance against eachother like that.
> All those dollars that India is supposed to be spending to improve our > balance of payments came from sending the dollars out of the US in the > first place.
You seem to be of the impression that a nation gets wealthy when it has a lot of currency in it. If that were so, Mexico would be the wealthiest country in North America. Wealth is created when money is *exchanged* as part of a *purchase* arrangement. The mere existence of currency doesn't do squat.
> Even if every dollar returns to the US (unlikely because of market > inefficiency) the net balance is zero.
The net balance of how much currency we have would be zero, but that's irrelevant. (As far as some currency not coming back... if there were a shortage, the treasury would print more. Most of it comes back though.)
> As a result, all that is happening is that the economy gets pumped up > from a depressed state back to something approaching the situation before > all those resources were shipped overseas.
Let's say EvilCorp (which is based somewhere on the US west coast) has been spending fifty billion dollars per year on the salaries of workers who produce the Foo service, but now they're going to outsource the Foo service to workers in ubbledubgong, which costs only twenty billion dollars because of the lower wage expectations and cost of living there. Now, four things have happened:
1. US workers are unemployed to the tune of fifty billion.
2. Workers in Ubbledubgong are employed to the tune of twenty billion.
3. EvilCorp has thirty billion dollars to dispose of in some other
fashion.
4. There are twenty billion dollars of US currency in Ubbledubgong.
(This ignores the stock market; if EvilCorp is public, there may be some additional results related to that, but we'll skip them for now.)
The amount of wealth created by EvilCorp has not changed, since the Foo service is still being provided. (This assumes the Ubbledubgongese are able to provide the service as well as the US workers. In some cases (e.g., phone tech support) there are problems with that, but that's a separate issue from outsourcing per se.) The people who are buying the Foo service from EvilCorp are still getting what they're paying for, so there's no change there. Well, actually, there is -- since that twenty billion is being produced by Ubbledubgong, not the US, the GNP of the US goes down twenty billion, and the GNP of Ubbledubgong goes up by the same amount.
The unemployed workers in the US will have to find some new jobs, which is unfortunate. But this will get balanced out; sit tight for a minute.
EvilCorp is going to do *something* with that thirty billion. Unless they're doing something that involves permanently removing it from the ecconomy (such as using million-dollar bills as wallpaper for executive bathroom), it's still going to get spent. Say, for example, that they spend five billion paying off debts. The banks will then lend that money to someone else who will spend it, creating wealth and adding five billion to the GNP. Wait, there's still another twenty-five billion. Let's say the executives line their personal pockets with twenty billion and spend the other five billion on seminars and meetings and publicity and whatnot to "sell" the outsourcing decision to the employees, the public, and so forth. The five billion that they spend on all that stuff goes right into the ecconomy. $GNP += another five billion.
The other twenty billion goes into the ecconomy too, though perhaps indirectly. If the executives spend it on new houses and cars and stuff, it goes in directly; if the
> The argument you've made basically boils down to "we've seen this before > and it didn't hurt us". However, your assumption that we have seen this > before does not seem accurate. In the past we've seen exportation of > unskilled labor, mostly factory jobs.
Huh? Have you studied the tarrif issues that divided the north from the south politically ever since before the revolution and, combined with the states' rights issue and the slavery thingy gave birth to the civil war? Those were finished goods and services we were importing (mostly from Europe), one of the most advanced segments of the eccomony at the time, and the business owners, the wealthy, wanted them taxed heavily to "protect American business", by which they meant their personal profit margins. Sound familiar? But those weren't the "cheap" jobs we were protecting; at the time, the low-end jobs were all in agriculture, and we were *exporting* food and cotton. The tariffs were meant to protect people in a higher ecconomic bracket. When we got rid of the tariffs and had free trade, it was good for the ecconomy.
Now, there is an upward trend in terms of what we're exporting. Things that used to be advanced goods and services that we exported are now basic enough that we once again import them, along with raw materiels, because the things we export are even more advanced. (Think in terms of stereo equipment and stuff here; that was technology in the 60s, and we exported it. Now it's basic cheap junk, and we import it.) Okay, so some of the stuff we're importing now is scaring some people because it's more advanced than what we used to import -- it's still less advanced than what we export (except food; we've never stopped exporting food). In the 1700s we exported mostly raw materiels. In the 1800s we exported manufactured goods, but they were pretty basic. In the 1900s we exported more advanced manufactured goods and started to export product designs. Now we're starting to export more and more design stuff and marketing and whatnot. Software in the 1980s was a very advanced product; now it's in the process of being outsourced and commoditized (thanks in part to the open-source movement, and thanks in part to India) because what we're producing here is more advanced -- we don't just make software anymore; we produce complete solutions, with full integration and on-site support and the pricetag to go with all that. In the 1980s, computer *hardware* was pretty advanced stuff, and we exported it. Now we create the chip fabrication process but outsource a lot of the actual hardware production overseas.
Now, prepare to get really worried, because I'm about to take a stab at predicting a hundred years into the future, what we will have outsourced... Writing, including journalistic writing. Not just chip fabrication but the actual design process too. Not just programming but software design and specification and quality assurance. *All* manufacturing-related jobs, most telecommunications jobs, and virtually all technical support, except for on-site support contracts. Most systems administration (because all the servers will be overseas anyway, including the thinclient servers; over here we'll have screens and keyboards and mice). Almost all data entry, except for information that really has to be done locally. Most retail sales, except for the few remaining types of stores that really *need* to be brick-and-mortar (such as groceries). The majority of all sales positions. All accounting positions and most HR positions. All middle-management positions. The list could go on, but you get the idea.
In the 1900s we went from a blue collar eccomony with white collar segments to a primarily white collar ecconomy. Now we're moving onward -- a lot of white collar jobs are low-end, boring, and repetitive by our new standards. Isn't the American Dream (TM) for everyone to be some kind of executive or celebrity or hold some other exotically high-end job? Why are you afraid?
Yeah, yeah, the evil corporations soak it all up, blah, blah, blah, but you obviously don't understand how the ecconomy works if you think that money will disappear into executives' pockets and cease to exist. What, you think they line their mattresses with it? They spend or invest it, and it stays in the ecconomy.
The real benefit to the US ecconomy, however, happens when India suddenly has a lot of US money to turn around and spend; ultimately that has to make its way back here. They'll use it to buy US goods and services, or they'll buy from another nation that in turn buys from the US, or whatever. It all comes back. So you have the US buying cheap labour from India, and India buying more advanced finished goods and services from the US. This creates a favorable trade situation and pumps up the US ecconomy (which would be a good thing about now, incidentally).
Your same "The US doesn't benefit" argument was used against NAFTA, against free trade with Europe in the 1700s and 1800s, against trade with Asia later, and every other time anyone has proposed international trade. But it always comes from a lack of understanding of basic undergraduate ecconomics.
> > This is only true of badly-designed, poorly-implemented software. > > Good software is *easy* to install. > > I will repeat this to you now. This statement is sheer ignorance. > You obviously haven't an idea as what goes into an installation.
Repeating it doesn't make it any less wrong. If installing the software is hard, then the software is badly-written.
> I have woked on thousands of installation scripts. I've responded to > tens of thousands of inquiries. I can tell you, that software intallation > is complex, and only the simplest of applications should be "easy" to > install.
This is bunk. Large, highly-complex software can be easy to install if it's designed correctly. I've used large, highly-complex software that's easy to install, because it was well designed.
> Theoretical? OLE is theoretical? OLE is a mess. There are better ways of accomplishing the same things.
> Office doesn't get used? What's that got to do with anything?
> Adobe static links? Please don't appeal to Adobe as an example of good software design. It makes my whole body cringe.
> Are you ignorant or just plain stupid? I cannot take this comment seriously. Argumentum ad hominem doesn't strengthen your case.
> Common DLLs are used on every OS out there, Well, something equivalent is on most of them. I'm not sure how that's germaine to the question of whether they're a Good Thing, though.
> Why? Rampant dynamic linking is what people want. It saves memory, > execution time, and file clutter. It saves memory at the expense of maintainability, and it *greatly* increases file clutter.
> > and most "common" DLLs end up being used by exactly one app > Of course most common DLLs do. Since every DLL is needed by another > program. However, if all the programs that use common DLLs would put > its own version on the system instead, you'd probably have hundreds more. So? You'd also have fewer problems.
> > when there *are* multiple apps using it, there is danger of conflicts > > (especially under Win9x). > And what are these so-called conflicts?
DLL version conflicts. One app installs an incompatible upgrade to a DLL and the other app breaks. This used to happen a *lot* on Win95. Microsoft started a campaign circa 1996 to educate developers about the problem and about the benefits of installing into the application directory (except for standard system DLLs), and the situation has improved considerably.
> The only conflicts i've seen is when people don't dynamically link. There > ends up being a name problem, as Windows can only load one DLL given any > one name. This is a confused statement. With static linking Windows doesn't need to load a DLL at all, so there's no problem.
> > > Since the DLLs must be placed in the system directory > > This is almost always a bad idea. It's probably the number one complaint > > of powerusers against low-quality Windows software. The problems it can > > cause are many and varied. > Actually, i believe it is a Windows logo requirement. It was because of > the low quality of software that didn't do it. By having all DLLs in one > place, there can be no name conflicts, and the correct DLL is always > loaded. Plus versioning, and OS versioning, are no longer a problem.
No, this is wrong. When the app's installer throws DLLs into the system directories, it creates version conflicts with any app that uses an earlier version of the same DLL. It is theoretically possible to avoid this by changing the filename of the DLL every version, but the library developers never seem to do that. They usually only change the filename every *major* version, and keep it the same over several *minor* versions; minor versions are *supposed* t
> One of the major reasons I switched from Mozilla to Fire*/Thunderbird was > that Mozilla stupidly kept querying your mailbox for new messages -- even > after you'd closed the Mail app.
Maybe one of the reasons I'm still using the Seamonkey XPFE-based suite is that I don't use the Mail/News component. For that I have Gnus, a mail client with actual features and functionality and stuff. I use Mozilla mostly for the browser (though I also use the Calendar a little and the DOM Inspector).
I don't use Composer either -- I have Emacs for that, with my own custom cperl-mode hook functions that rebind certain keys to my own custom functions that make web development easier. (Ctrl-t, for example, prompts for a tag body and inserts the start tag and the end tag, leaving the cursor between them. (If the tag body starts with "table", it also inserts the thead and tbody start and end tags with a tr pair inside each, all properly indented.) Ctrl-j e prompts for a tag body and wraps the current selection in that tag. And so on. Ctrl-j u updates the stylesheet links to my current ones, updates the "page updated" information in the footer, and stuff like that.)
> I noticed the About dialog showed a TM sign too, so I have a feeling they > now actually got a registration through.
If they had it registered, they could put an R in a circle next to it. The TM just serves as notice that they intend it as a trademark; registration is not required to mark it with TM.
> If you rename something to prevent confusion with other products don't > you think you should avoid something that is already a [bunch of stuff]
I would have thought so, but somebody important at Mozilla.org has always been of the opinion that a "good name" has to be chosen because it's already the name of something else. Mozilla was named from Godzilla, and frankly that's the most original product name that's ever been associated with the project -- and it was inherited from the very early days at Netscape.
Navigator and Messenger and Composer and DOM Inspector and Calendar are named for what they do or what they are, how clever. (Also, except DOM Inspector and Calendar these names were carried over from Communicator.) Seamonkey is a small creature, among other things. Rhino is named from the animal on the front of an O'Reilly book; SpiderMonkey is also named after an animal.
Phoenix, besides being a very famous mythological creature has also been used as a brand name more times than *almost* any word in the English language, though they managed to find one of the few[1] that have been used more often when they renamed it to Firebird. Thunderbird and Camino are also cars (and though Camino may not be much else, Thunderbird is also a number of other things besides just the car, though not as many things as Firebird or Phoenix). Sunbird (the new name for the as-yet-nonexistant standalone calendar app in the new suite that uses the Phoenix/Firebird/Firefox widget set instead of XPFE) also is a car, among other things. Chameleon, the old name for Camino, is a lizard, as is Gecko. Necko comes from Necco, a food brand (though it was chosen to go with Gecko). I'm not sure where the Venkman name comes from, exactly, but I'm certain I'd heard it before, prior to its adoption for the Mozilla.org script debugger. I can't place it though. Firefox, besides all the things you listed, is an animal; the other things are probably mostly all named after the animal and/or eachother.
This is all not accidental. Someone at mozilla.org is doing this on *purpose*, deliberately choosing the names of existing things. I don't understand why, but the pattern is clear.
[1] Several hundred perhaps -- in a language with as many words as English,
that's not very many.
Dark matter (and its various extensions, including dark energy) was always a fudge theory, designed to reconcile data and theories that didn't fit one another very well. There were always a lot of intelligent scientists who never believed in it.
If you can get them to pay you hourly, instead of salary, there are several benefits. Perhaps the most important is that overtime has to be paid, and they have no claim on any time they don't pay you for. Salary muddies that. The concern stated in the question is covered by this, too: if you're hourly, they can only reasonably claim stuff you do while you're on the clock. Also, hourly employees are better protected by the Department of Labor, at least in the US. For example, any time over 40 hours in a week MUST be paid at 1.5 times your regular rate (at least), and they won't even attempt to violate this because if the DOL gets called in on a complaint about overtime violations it's painful for the employer. Also you can turn down excessive overtime, even if your boss whines "I really need this this weekend", and if he fires you for this it's legally actionable. (There are other ways your boss can make your life unpleasant besides firing you, of course...)
Perhaps more importantly, most employers have different expectations of hourly employees than salaried employees; if you decide you'd like to take an extra week off beyond what paid time you have coming for example, many employers are willing to let you have some unpaid time off with no argument, unless your timing is really bad (e.g., if you want off all of December, they'll obviously not care for that).
So, I personally would consider $15/hour to be better than $600/week.
There is a downside, though: if things are slow, they can cut your hours way back if you're hourly and your only recourse is to get a second job. Then again, even if you're on salary, you can still be downsized.
> I still think 'Firefox' stinks. Doesn't roll off the tongue like Mozilla, > Firebird, or Phoenix, but I'm sure choosing a name that isn't already > taken isn't easy.
"Mozilla" is hard for a lot of people to remember and pronounce. Firebird and Phoenix are both so horribly generic that the don't make good brands. Frankly, Firefox isn't unique either (though I don't recall exactly where I've heard it; it might not be computer-related).
> Besides, I think they were stuck between a rock and a hard place with > their lack of research over their last name.
No, the Firebird Database people were being silly there. The word "Firebird" is *way*, *WAY* too generic to ever be considered a trademarkeable, unique name. It's been used by *hundreds* of different computer-related products over the last three decades and *millions* of non-computer-related products over the last three centuries. It's like naming your database ZipSQL and then getting offended when somebody releases a Zip web browser. That's stoopid with two "o"s. OTOH, for the same reason, it didn't make a good name.
> but I'm sure choosing a name that isn't already taken isn't easy.
It's the easiest thing in the world, if you can give up on the idea of using an already existing name of something. The word "firebird" is so common that any random person off the street should be able to name several different products called that. The Mozilla people probably chose it based on the name of the car, but we wouldn't even know that if their other names ("thunderbird", "camino") weren't chosen the same way, because there are myriad other things they might have named it after and called it "Firebird".
You want a unique name? MAKE ONE UP. It's not that tough. Want a bird name to go with "thunderbird" and "sunbird"? Call it "FlameThrush" or "Web Falcon" or "Internet Hawk" or "Net Sparrow". Want to imply a great beast to go with the "Mozilla" theme? Then call it "Mohemoth" or something along those lines. (Playing off the name of a type of dinosaur is possible but would probably come off as trite. Besides, the obvious "Morannosaur" is too much like "moron".) Want to imply smallness to attract the "lean and mean" crowd that wants it to run on 8MB of RAM? Call it "Web Chickadee" or "LepraunNet" or "Dime Browser". Speed? "Mozoom" or "Mozilla Quickling". Wildness? "Screaming Flaming Rabbit".
Of all these, I like "FlameThrush" best. It's certain not to be taken, rolls off the tongue, and lends itself well toward future expansion to include the other components. (Want to rename "Thunderbird"? "RumbleWren" is similarly unlikely to be taken, but you could also go with "BoomSwift" or "LightningRook" or "PealMartin", or there are many other possibilities, and that's just keeping within the basic "thunder bird" idea.)
> The fact of the matter is that every unix-like operating system in existance > (save a small handful (Linux, the contemporary BSDs, etc...)) are offshoots > at one point or another from the real AT&T Unix
I realise you qualified this with "and exist solely under license", and so BSD is excluded because of the UC Berkeley court case, but it seems germaine to note that BSD *is* genetic Unix; early versions of it were derived from the Bell Labs code. (The Bell Labs codebase is what later became System V.) Linux is not, and there are a handful of other *nix kernels that are not (including Minix for example).
Of course, the reason the court case went the way it did is because so much of BSD had been improved or just plain rewritten at university, and that was a long time ago, and BSD is much changed since then, so there's probably very little actual code still in there from Bell Labs. But that is its heritage.
> Therefore, if the universe were infinite in volume, SCO's smoke would fill > half of that infinite space.
Actually, the amount of space in the universe has a cardinality of aleph-sub-one, so an aleph-naught amount of smoke would nowhere near begin to fill it. You could put a molecule of smoke in every square inch or so, but there'd still be all that empty space in between.
> There are so many things involved in installation that makes your question > one of sheer ignorance.
This is only true of badly-designed, poorly-implemented software. Good software is *easy* to install.
> Common DLLs must be marked on the system as to how many program claim to > use it. This is so it is deleted only after the very last program stops > using it.
Common DLLs are an example of misguided design. For all of its theoretical benefits, rampant dynamic linking causes way more trouble than it's worth, and most "common" DLLs end up being used by exactly one app in almost all cases; when there *are* multiple apps using it, there is danger of conflicts (especially under Win9x). It would be far better for all concerned if these were stored in the same place as the application's primary executable(s); in many cases it would be even better if the functions that are actually *used* from the libraries were just linked in statically.
> Since the DLLs must be placed in the system directory
This is almost always a bad idea. It's probably the number one complaint of powerusers against low-quality Windows software. The problems it can cause are many and varied.
> Uninstall. Creating an uninstall can be painful.
Yeah, it's painful if your software litters oodles of files all over the drive. If you've got to clean junk out of multiple different directories, some of which do not belong just to the application in question, of *course* the uninstall process will be painful. But this is bad design. There should only be files in three types of places:
1. The application itself and any needed libraries, controls, whatever,
in the application directory. This includes any "data" that ships
with the application and doesn't change (e.g., images used for toolbar
icons).
2. User-specific configuration information stored on a per-user basis.
3. Other (non-configuration) files that the user has created.
The uninstaller should always remove part 1 completely, ask whether to remove part 2 (config files) or not, and leave part 3 (documents) alone. On Windows, these things would typically be in Program Files, Application Data, and My Documents, respectively. On Unix parts 2 and 3 are in the user's home directory, and part 1 is in/usr (though it gets split between/usr/bin and/usr/share typically and maybe/usr/lib too, and sometimes the prefix may be/usr/local or something else instead of/usr).
> INI writes. If an INI file is used, the official way to write to it is > with as system call.
There are other, better ways to store configuration information than system INI writes. The registry is useful for things like setting up associations, but storing all of the app's config information there is a major mistake, as it makes it virtually impossible for a user to maintain separate versions of your app in different directories. (If you don't think users will want to do this with your app, you're either more naive than you let on or your app is too simple to need updates to a new version.)
Regular old application-specific configuration files are actually a very nice, clean solution that works well and has no disadvantages.
> Getting around without a watch only works when the rest of the timepiece > slaves willingly chain themselves and give us the time when asked to do so!
Wearing a watch would be pointless for me, because what time would I set it to? I'd have to have one with multiple timezones, so I could set one tz to work time, one to home time, one to the *real* time, and so on and so forth. Then I'd have to try to remember which was which. No thanks. I'll just use the clocks on the wall in each location, since those always tell the "right" time for where I happen to be just then. I haven't worn a watch in fifteen years, but I never have to ask anyone the time; I just look at a clock.
> Another practical use, is source code printed on fan-fold, tractor-fed > paper. I've been adjusting to tryint to manage large chunks of code only > in a small window, but when you have to check something further down the > current section, it gets really annoying.
You need an editor with easy window splitting and/or text folding and the ability to flip instantly between multiple cursors. I used to swear by continuous-feed desk-checking, but since I learned Emacs I've not had the urge to print out source code even once.
CLI isn't *old* enough to die. It's barely fifty years old, and in its current modern form (with e.g. smart completion that knows to complete a directory name after one type of command or any filename after another et cetera) is less than ten years old.
You want technology that is *totally* obsolete and just *refuses* to die, that is still used by everyone all the time, you have to look at something older than CLI. Paper comes to mind. Radio is a bit newer but doesn't show any signs of dying either, despite being declared dead the minute television started to get popular.
Target a virtual machine. The z-machine is obvious if you don't need graphics and is probably the second-most-portable format after plain ASCII text. (The only other serious contender is HTML, but HTML is less consistent, and the z-machine is much more powerful and was designed for games.)
You mention graphics, though, so if that's important, look into a different virtual machine. glulx supports some graphics for example. Of course there's Java, but it's more heavyweight and so less portable. Parrot is probably not ready for primetime yet, though it's one to watch in the years to come. I am sure there are other choice I'm forgetting at the moment.
The advantage of targeting a VM is that you don't have to do the portability work; it's been done. You write once for the VM, and it runs on every platform that has an implementation of that VM. The z-machine is best, because there are multiple implementations of it on pretty much every platform, from Acorn to Gameboy. (It was designed to be implemented on 8-bit micros in the 80s, so it fits easily on handheld systems today.) The big problem with the z-machine, of course, is no graphics.
> Actually I think my suggestion would require minimal effort. All you have > to do is go to the code that adds links to the hash table, and make it > add several links.
I doubt it. That might give you the functionality you want (well, the backend support for it; a little XUL here and script there for the rest), but then you've probably broken six other unrelated things and will end up with a pile of bugs in your lap and have to back out your changes until you can integrate them into all of the other stuff that the former implementation was integraed into.
> The only defect [...] you could fix [...] by adding an extra character > to the end of all the prefixes
That would be a fairly brittle implementation. If you want your browser to be robust, you need to avoid doing stuff like that and implement things that you implement properly (i.e., the mechanism that remembers visited links would need flags and stuff and almost starts to feel like a database -- or else you could accept the perf hit and toss the hashing in favor of a sorted list).
> Don't bother trying to rate limit downloads; you'll get exactly the same > number of people downloading everything, except that instead of doing it > quickly they'll leave wget running all week and tying up your server's > resources.
Rather than slowing the transfer, I'd send a 503 response to clients that have pulled too much in the last hour/day/week/whatever. If you have to send the same client too many 503s in too short a time, switch to 403. If you're concerned about really persistent people continuing to pull down your content even if it takes all month, just double the delay that you make them wait after each file. (Dialup users on a dynamic IP can get around this by redialing, but dialup users are unlikely to be your big problem, in terms of transfer limits.) At some point it becomes less painful to find a mirror than to wait another three weeks. Combine this with seeding a torrent and pasting information about it all over the front page, and you should make a big dent in your problem.
> Have a page [...] that all your links point to, and have that page > return <meta http-equiv="Refresh" content="1;URL=files/$filename"> > This totally breaks wget, although it's not too hard to script around.
I could get around that in thirty seconds with WWW::Mechanize.
> If you enable referer checking, this will stop most wget type programs.
This won't phase WWW::Mechanize one iota. When it follows a link, it sends the referer just like any other browser, unless you tell it otherwise.
You really are going to have to throttle based on client IP. They can't fake that if they want to get the information back, so you can positively identify, "this is the same host that has already requested n pages in the last thirty seconds".
If you throttle overall, without throttling based on IP, the people using wget or whatever will be virtually the only people who can get to the content; a real browser will take so long nobody will wait for it, but the people using wget aren't waiting for it; they're doing other stuff (going to work, sleeping, eating, reading books, programming,...) while it happens in the background. They probably won't even notice the throttling. No, if you want "regular" users to get your content but want to limit the people who are slurping the whole site automatically, you've got to limit how much any particular host can retrieve per minute/hour/whatever.
I also concur with whoever said, "seed a Torrent of the whole thing". If aside from the bandwidth hit you don't mind letting people mirror the whole thing, this gives them a way to do it without costing you so much bandwidth.
> Set up javascript links, which wget can't follow.
It's possible for clueful scripters to get around this using WWW::Mechanize, as I had to do in my script that retrieves database usage stats for the commercial databases we subscribe to at work. Ebsco's usage stats thingydoo uses script links that call functions in an external, linked.js file. The functions then change certain form elements and submit the form. So I just told my WWW::Mechanize browser object to change the form elements in question and submit; problem solved.
Now, if each and every link were slightly different in how it works, then only the most dedicated scripter could write the script to slurp your site (without just implementing ECMA script and a DOM on top of WWW::Mechanize). However, setting that up would be a lot of trouble, as the site maintainer would have to spend O(n) time where n is the number of links. No fun.
A better solution would be to limit how many files a given host can request per minute and send a 503 response for any that go over.
> Best solution I can think of is to also hash each of the different lengths > of prefix at the same time you hash the full URL.
Right, but my point was that this would require changing the whole mechanism by which the browser keeps track of visited links. That's pretty a central little bit of funtionality that's been around forever, so it's vey likely that any changes to it will impact various other parts of the browser. i.e., this is the sort of change that causes a lot of regressions and has to be tested quite thoroughly before it can be put into a release. That is to say, it would be a lot of work. It's not the same sort of relatively easy change as merely putting the FQDN in a different color from the rest of the URI (though even that would probably need backend support).
> Would anyone have a legal leg to stand on if they went up against the might > of the army of MS lawyers?
You might *theoretically* have a case, but they'd tie you up in court so long your great grandchildren would have osteoarthritis before you got anywhere. It ain't worth it. Just use Mozilla.
> In my personal Utopia -- indeed, when or if I run my own company with more > than just me as an employee -- I'll be happy to have a standard operating > environment. However, said SOE would have at least two browsers, being the > OS default if one exists, for whichever OS I happen to choose to run on, > and a well used alternative
On an OS that was designed for security from early on, you could allow the user to install whatever they want in their home directory (subject to quotas). Under Windows, however, that is not such a good idea. If I were to recommend something for an IT department of a company with a number of employees, the first thing I'd recommend is thin clients. Users who use the *nix system could install software in their home directories; if it needs to be installed anywhere else, IT has to approve and install it. Anyone using the Windows system would only be able to use software that the IT department had installed on the server. (It's not wise to allow Windows users to install just anything; there's a big fat local root hole that's quite old now and Microsoft admits cannot be fixed without breaking the Win32 API.) Now, I wouldn't limit them to one browser necessarily, but if they wanted to use a particular browser (or whatever) they would have to get IT to install it, so IT would be aware of it. (Keeping a complete catalog would be a good idea.)
> It's part of our IT department's standard operating environment to have MSIE > as the only browser on Windows platforms. It's also part of their policy > to prevent additional programs -- specifically including web browsers of > any kind -- from being installed
Start working on your resume -- you'll eventually need it, because it's obvious that the IT department is utterly incompetent, which means the management is incompetent enough that they don't know whether their staff are able to do their job... the company is not good, long-term, for your career. Keep the job until you find another one, but be looking.
Note that limiting the software users can install is not in itself a bad thing (I absolutely will not permit Outlook inside the firewall, for example, and not just anyone can install software), but settling on the least secure browser available as the one and only choice is a *very* bad sign. If management keeps these guys more than a year, you want to be elsewhere.
> Their reasoning? Security.
This is their *stated* reason. They probably have some other "real" reason, though it may not make much sense either. Nevertheless, here be dragons.
> for every single windows user to see and read, repeatedly, until they > get the hint.
You're dreaming. That can never happen. But it would be nice if the IT guys at least got the hint.
Slashdot Mirror
> Excuse me, but that's only the positive half of the equation.
No, ecconomics doesn't work that way. It's not zero-sum. It doesn't have
a positive half and a negative half that balance against eachother like that.
> All those dollars that India is supposed to be spending to improve our
> balance of payments came from sending the dollars out of the US in the
> first place.
You seem to be of the impression that a nation gets wealthy when it has a lot
of currency in it. If that were so, Mexico would be the wealthiest country
in North America. Wealth is created when money is *exchanged* as part of a
*purchase* arrangement. The mere existence of currency doesn't do squat.
> Even if every dollar returns to the US (unlikely because of market
> inefficiency) the net balance is zero.
The net balance of how much currency we have would be zero, but that's
irrelevant. (As far as some currency not coming back... if there were a
shortage, the treasury would print more. Most of it comes back though.)
> As a result, all that is happening is that the economy gets pumped up
> from a depressed state back to something approaching the situation before
> all those resources were shipped overseas.
Let's say EvilCorp (which is based somewhere on the US west coast) has been
spending fifty billion dollars per year on the salaries of workers who
produce the Foo service, but now they're going to outsource the Foo service
to workers in ubbledubgong, which costs only twenty billion dollars because
of the lower wage expectations and cost of living there. Now, four things
have happened:
1. US workers are unemployed to the tune of fifty billion.
2. Workers in Ubbledubgong are employed to the tune of twenty billion.
3. EvilCorp has thirty billion dollars to dispose of in some other
fashion.
4. There are twenty billion dollars of US currency in Ubbledubgong.
(This ignores the stock market; if EvilCorp is public, there may be some
additional results related to that, but we'll skip them for now.)
The amount of wealth created by EvilCorp has not changed, since the Foo
service is still being provided. (This assumes the Ubbledubgongese are
able to provide the service as well as the US workers. In some cases
(e.g., phone tech support) there are problems with that, but that's a
separate issue from outsourcing per se.) The people who are buying the
Foo service from EvilCorp are still getting what they're paying for, so
there's no change there. Well, actually, there is -- since that twenty
billion is being produced by Ubbledubgong, not the US, the GNP of the
US goes down twenty billion, and the GNP of Ubbledubgong goes up by the
same amount.
The unemployed workers in the US will have to find some new jobs, which
is unfortunate. But this will get balanced out; sit tight for a minute.
EvilCorp is going to do *something* with that thirty billion. Unless they're
doing something that involves permanently removing it from the ecconomy (such
as using million-dollar bills as wallpaper for executive bathroom), it's still
going to get spent. Say, for example, that they spend five billion paying off
debts. The banks will then lend that money to someone else who will spend it,
creating wealth and adding five billion to the GNP. Wait, there's still
another twenty-five billion. Let's say the executives line their personal
pockets with twenty billion and spend the other five billion on seminars and
meetings and publicity and whatnot to "sell" the outsourcing decision to
the employees, the public, and so forth. The five billion that they spend
on all that stuff goes right into the ecconomy. $GNP += another five billion.
The other twenty billion goes into the ecconomy too, though perhaps
indirectly. If the executives spend it on new houses and cars and stuff,
it goes in directly; if the
> The argument you've made basically boils down to "we've seen this before
> and it didn't hurt us". However, your assumption that we have seen this
> before does not seem accurate. In the past we've seen exportation of
> unskilled labor, mostly factory jobs.
Huh? Have you studied the tarrif issues that divided the north from the south
politically ever since before the revolution and, combined with the states'
rights issue and the slavery thingy gave birth to the civil war? Those were
finished goods and services we were importing (mostly from Europe), one of
the most advanced segments of the eccomony at the time, and the business
owners, the wealthy, wanted them taxed heavily to "protect American business",
by which they meant their personal profit margins. Sound familiar? But those
weren't the "cheap" jobs we were protecting; at the time, the low-end jobs
were all in agriculture, and we were *exporting* food and cotton. The
tariffs were meant to protect people in a higher ecconomic bracket. When
we got rid of the tariffs and had free trade, it was good for the ecconomy.
Now, there is an upward trend in terms of what we're exporting. Things
that used to be advanced goods and services that we exported are now
basic enough that we once again import them, along with raw materiels,
because the things we export are even more advanced. (Think in terms of
stereo equipment and stuff here; that was technology in the 60s, and we
exported it. Now it's basic cheap junk, and we import it.) Okay, so some
of the stuff we're importing now is scaring some people because it's more
advanced than what we used to import -- it's still less advanced than what
we export (except food; we've never stopped exporting food). In the 1700s
we exported mostly raw materiels. In the 1800s we exported manufactured
goods, but they were pretty basic. In the 1900s we exported more advanced
manufactured goods and started to export product designs. Now we're starting
to export more and more design stuff and marketing and whatnot. Software
in the 1980s was a very advanced product; now it's in the process of being
outsourced and commoditized (thanks in part to the open-source movement,
and thanks in part to India) because what we're producing here is more
advanced -- we don't just make software anymore; we produce complete
solutions, with full integration and on-site support and the pricetag to
go with all that. In the 1980s, computer *hardware* was pretty advanced
stuff, and we exported it. Now we create the chip fabrication process
but outsource a lot of the actual hardware production overseas.
Now, prepare to get really worried, because I'm about to take a stab at
predicting a hundred years into the future, what we will have outsourced...
Writing, including journalistic writing. Not just chip fabrication but
the actual design process too. Not just programming but software design
and specification and quality assurance. *All* manufacturing-related jobs,
most telecommunications jobs, and virtually all technical support, except
for on-site support contracts. Most systems administration (because all
the servers will be overseas anyway, including the thinclient servers;
over here we'll have screens and keyboards and mice). Almost all data
entry, except for information that really has to be done locally. Most
retail sales, except for the few remaining types of stores that really
*need* to be brick-and-mortar (such as groceries). The majority of all
sales positions. All accounting positions and most HR positions. All
middle-management positions. The list could go on, but you get the idea.
In the 1900s we went from a blue collar eccomony with white collar segments
to a primarily white collar ecconomy. Now we're moving onward -- a lot of
white collar jobs are low-end, boring, and repetitive by our new standards.
Isn't the American Dream (TM) for everyone to be some kind of executive or
celebrity or hold some other exotically high-end job? Why are you afraid?
> "The US" is not benefiting from cheap labor
Yeah, yeah, the evil corporations soak it all up, blah, blah, blah, but you
obviously don't understand how the ecconomy works if you think that money will
disappear into executives' pockets and cease to exist. What, you think they
line their mattresses with it? They spend or invest it, and it stays in the
ecconomy.
The real benefit to the US ecconomy, however, happens when India suddenly has
a lot of US money to turn around and spend; ultimately that has to make its
way back here. They'll use it to buy US goods and services, or they'll buy
from another nation that in turn buys from the US, or whatever. It all comes
back. So you have the US buying cheap labour from India, and India buying
more advanced finished goods and services from the US. This creates a
favorable trade situation and pumps up the US ecconomy (which would be a
good thing about now, incidentally).
Your same "The US doesn't benefit" argument was used against NAFTA, against
free trade with Europe in the 1700s and 1800s, against trade with Asia later,
and every other time anyone has proposed international trade. But it always
comes from a lack of understanding of basic undergraduate ecconomics.
> > This is only true of badly-designed, poorly-implemented software.
> > Good software is *easy* to install.
>
> I will repeat this to you now. This statement is sheer ignorance.
> You obviously haven't an idea as what goes into an installation.
Repeating it doesn't make it any less wrong. If installing the software
is hard, then the software is badly-written.
> I have woked on thousands of installation scripts. I've responded to
> tens of thousands of inquiries. I can tell you, that software intallation
> is complex, and only the simplest of applications should be "easy" to
> install.
This is bunk. Large, highly-complex software can be easy to install
if it's designed correctly. I've used large, highly-complex software
that's easy to install, because it was well designed.
> Theoretical? OLE is theoretical?
OLE is a mess. There are better ways of accomplishing the same things.
> Office doesn't get used?
What's that got to do with anything?
> Adobe static links?
Please don't appeal to Adobe as an example of good software design.
It makes my whole body cringe.
> Are you ignorant or just plain stupid? I cannot take this comment seriously.
Argumentum ad hominem doesn't strengthen your case.
> Common DLLs are used on every OS out there,
Well, something equivalent is on most of them. I'm not sure how that's
germaine to the question of whether they're a Good Thing, though.
> Why? Rampant dynamic linking is what people want. It saves memory,
> execution time, and file clutter.
It saves memory at the expense of maintainability, and it *greatly*
increases file clutter.
> > and most "common" DLLs end up being used by exactly one app
> Of course most common DLLs do. Since every DLL is needed by another
> program. However, if all the programs that use common DLLs would put
> its own version on the system instead, you'd probably have hundreds more.
So? You'd also have fewer problems.
> > when there *are* multiple apps using it, there is danger of conflicts
> > (especially under Win9x).
> And what are these so-called conflicts?
DLL version conflicts. One app installs an incompatible upgrade to a DLL
and the other app breaks. This used to happen a *lot* on Win95. Microsoft
started a campaign circa 1996 to educate developers about the problem and
about the benefits of installing into the application directory (except
for standard system DLLs), and the situation has improved considerably.
> The only conflicts i've seen is when people don't dynamically link. There
> ends up being a name problem, as Windows can only load one DLL given any
> one name.
This is a confused statement. With static linking Windows doesn't need to
load a DLL at all, so there's no problem.
> > > Since the DLLs must be placed in the system directory
> > This is almost always a bad idea. It's probably the number one complaint
> > of powerusers against low-quality Windows software. The problems it can
> > cause are many and varied.
> Actually, i believe it is a Windows logo requirement. It was because of
> the low quality of software that didn't do it. By having all DLLs in one
> place, there can be no name conflicts, and the correct DLL is always
> loaded. Plus versioning, and OS versioning, are no longer a problem.
No, this is wrong. When the app's installer throws DLLs into the system
directories, it creates version conflicts with any app that uses an
earlier version of the same DLL. It is theoretically possible to avoid
this by changing the filename of the DLL every version, but the library
developers never seem to do that. They usually only change the filename
every *major* version, and keep it the same over several *minor* versions;
minor versions are *supposed* t
> One of the major reasons I switched from Mozilla to Fire*/Thunderbird was
> that Mozilla stupidly kept querying your mailbox for new messages -- even
> after you'd closed the Mail app.
Maybe one of the reasons I'm still using the Seamonkey XPFE-based suite is
that I don't use the Mail/News component. For that I have Gnus, a mail client
with actual features and functionality and stuff. I use Mozilla mostly for
the browser (though I also use the Calendar a little and the DOM Inspector).
I don't use Composer either -- I have Emacs for that, with my own custom
cperl-mode hook functions that rebind certain keys to my own custom functions
that make web development easier. (Ctrl-t, for example, prompts for a tag
body and inserts the start tag and the end tag, leaving the cursor between
them. (If the tag body starts with "table", it also inserts the thead and
tbody start and end tags with a tr pair inside each, all properly indented.)
Ctrl-j e prompts for a tag body and wraps the current selection in that tag.
And so on. Ctrl-j u updates the stylesheet links to my current ones, updates
the "page updated" information in the footer, and stuff like that.)
> I noticed the About dialog showed a TM sign too, so I have a feeling they
> now actually got a registration through.
If they had it registered, they could put an R in a circle next to it. The
TM just serves as notice that they intend it as a trademark; registration is
not required to mark it with TM.
> If you rename something to prevent confusion with other products don't
> you think you should avoid something that is already a [bunch of stuff]
I would have thought so, but somebody important at Mozilla.org has always been
of the opinion that a "good name" has to be chosen because it's already the
name of something else. Mozilla was named from Godzilla, and frankly that's
the most original product name that's ever been associated with the project --
and it was inherited from the very early days at Netscape.
Navigator and Messenger and Composer and DOM Inspector and Calendar are named
for what they do or what they are, how clever. (Also, except DOM Inspector
and Calendar these names were carried over from Communicator.) Seamonkey is
a small creature, among other things. Rhino is named from the animal on the
front of an O'Reilly book; SpiderMonkey is also named after an animal.
Phoenix, besides being a very famous mythological creature has also been used
as a brand name more times than *almost* any word in the English language,
though they managed to find one of the few[1] that have been used more often
when they renamed it to Firebird. Thunderbird and Camino are also cars (and
though Camino may not be much else, Thunderbird is also a number of other
things besides just the car, though not as many things as Firebird or
Phoenix). Sunbird (the new name for the as-yet-nonexistant standalone
calendar app in the new suite that uses the Phoenix/Firebird/Firefox widget
set instead of XPFE) also is a car, among other things. Chameleon, the old
name for Camino, is a lizard, as is Gecko. Necko comes from Necco, a food
brand (though it was chosen to go with Gecko). I'm not sure where the
Venkman name comes from, exactly, but I'm certain I'd heard it before, prior
to its adoption for the Mozilla.org script debugger. I can't place it though.
Firefox, besides all the things you listed, is an animal; the other things
are probably mostly all named after the animal and/or eachother.
This is all not accidental. Someone at mozilla.org is doing this on
*purpose*, deliberately choosing the names of existing things. I don't
understand why, but the pattern is clear.
[1] Several hundred perhaps -- in a language with as many words as English,
that's not very many.
Dark matter (and its various extensions, including dark energy) was always a
fudge theory, designed to reconcile data and theories that didn't fit one
another very well. There were always a lot of intelligent scientists who
never believed in it.
If you can get them to pay you hourly, instead of salary, there are several
benefits. Perhaps the most important is that overtime has to be paid, and
they have no claim on any time they don't pay you for. Salary muddies that.
The concern stated in the question is covered by this, too: if you're hourly,
they can only reasonably claim stuff you do while you're on the clock. Also,
hourly employees are better protected by the Department of Labor, at least in
the US. For example, any time over 40 hours in a week MUST be paid at 1.5
times your regular rate (at least), and they won't even attempt to violate
this because if the DOL gets called in on a complaint about overtime violations
it's painful for the employer. Also you can turn down excessive overtime,
even if your boss whines "I really need this this weekend", and if he fires
you for this it's legally actionable. (There are other ways your boss can
make your life unpleasant besides firing you, of course...)
Perhaps more importantly, most employers have different expectations of
hourly employees than salaried employees; if you decide you'd like to take
an extra week off beyond what paid time you have coming for example, many
employers are willing to let you have some unpaid time off with no argument,
unless your timing is really bad (e.g., if you want off all of December,
they'll obviously not care for that).
So, I personally would consider $15/hour to be better than $600/week.
There is a downside, though: if things are slow, they can cut your hours
way back if you're hourly and your only recourse is to get a second job.
Then again, even if you're on salary, you can still be downsized.
> I still think 'Firefox' stinks. Doesn't roll off the tongue like Mozilla,
> Firebird, or Phoenix, but I'm sure choosing a name that isn't already
> taken isn't easy.
"Mozilla" is hard for a lot of people to remember and pronounce. Firebird
and Phoenix are both so horribly generic that the don't make good brands.
Frankly, Firefox isn't unique either (though I don't recall exactly where
I've heard it; it might not be computer-related).
> Besides, I think they were stuck between a rock and a hard place with
> their lack of research over their last name.
No, the Firebird Database people were being silly there. The word "Firebird"
is *way*, *WAY* too generic to ever be considered a trademarkeable, unique
name. It's been used by *hundreds* of different computer-related products
over the last three decades and *millions* of non-computer-related products
over the last three centuries. It's like naming your database ZipSQL and
then getting offended when somebody releases a Zip web browser. That's
stoopid with two "o"s. OTOH, for the same reason, it didn't make a good name.
> but I'm sure choosing a name that isn't already taken isn't easy.
It's the easiest thing in the world, if you can give up on the idea of
using an already existing name of something. The word "firebird" is so
common that any random person off the street should be able to name several
different products called that. The Mozilla people probably chose it based
on the name of the car, but we wouldn't even know that if their other names
("thunderbird", "camino") weren't chosen the same way, because there are
myriad other things they might have named it after and called it "Firebird".
You want a unique name? MAKE ONE UP. It's not that tough. Want a bird
name to go with "thunderbird" and "sunbird"? Call it "FlameThrush" or "Web
Falcon" or "Internet Hawk" or "Net Sparrow". Want to imply a great beast
to go with the "Mozilla" theme? Then call it "Mohemoth" or something along
those lines. (Playing off the name of a type of dinosaur is possible but
would probably come off as trite. Besides, the obvious "Morannosaur" is
too much like "moron".) Want to imply smallness to attract the "lean and
mean" crowd that wants it to run on 8MB of RAM? Call it "Web Chickadee"
or "LepraunNet" or "Dime Browser". Speed? "Mozoom" or "Mozilla Quickling".
Wildness? "Screaming Flaming Rabbit".
Of all these, I like "FlameThrush" best. It's certain not to be taken,
rolls off the tongue, and lends itself well toward future expansion to
include the other components. (Want to rename "Thunderbird"? "RumbleWren"
is similarly unlikely to be taken, but you could also go with "BoomSwift"
or "LightningRook" or "PealMartin", or there are many other possibilities,
and that's just keeping within the basic "thunder bird" idea.)
> The fact of the matter is that every unix-like operating system in existance
> (save a small handful (Linux, the contemporary BSDs, etc...)) are offshoots
> at one point or another from the real AT&T Unix
I realise you qualified this with "and exist solely under license", and so
BSD is excluded because of the UC Berkeley court case, but it seems germaine
to note that BSD *is* genetic Unix; early versions of it were derived from the
Bell Labs code. (The Bell Labs codebase is what later became System V.) Linux
is not, and there are a handful of other *nix kernels that are not (including
Minix for example).
Of course, the reason the court case went the way it did is because so much
of BSD had been improved or just plain rewritten at university, and that was
a long time ago, and BSD is much changed since then, so there's probably very
little actual code still in there from Bell Labs. But that is its heritage.
> Therefore, if the universe were infinite in volume, SCO's smoke would fill
> half of that infinite space.
Actually, the amount of space in the universe has a cardinality of
aleph-sub-one, so an aleph-naught amount of smoke would nowhere near
begin to fill it. You could put a molecule of smoke in every square
inch or so, but there'd still be all that empty space in between.
> There are so many things involved in installation that makes your question
/usr (though it gets split /usr/bin and /usr/share typically and maybe /usr/lib too, and /usr/local or something else instead of /usr).
> one of sheer ignorance.
This is only true of badly-designed, poorly-implemented software. Good
software is *easy* to install.
> Common DLLs must be marked on the system as to how many program claim to
> use it. This is so it is deleted only after the very last program stops
> using it.
Common DLLs are an example of misguided design. For all of its theoretical
benefits, rampant dynamic linking causes way more trouble than it's worth,
and most "common" DLLs end up being used by exactly one app in almost all
cases; when there *are* multiple apps using it, there is danger of conflicts
(especially under Win9x). It would be far better for all concerned if these
were stored in the same place as the application's primary executable(s); in
many cases it would be even better if the functions that are actually *used*
from the libraries were just linked in statically.
> Since the DLLs must be placed in the system directory
This is almost always a bad idea. It's probably the number one complaint
of powerusers against low-quality Windows software. The problems it can
cause are many and varied.
> Uninstall. Creating an uninstall can be painful.
Yeah, it's painful if your software litters oodles of files all over the
drive. If you've got to clean junk out of multiple different directories,
some of which do not belong just to the application in question, of *course*
the uninstall process will be painful. But this is bad design. There
should only be files in three types of places:
1. The application itself and any needed libraries, controls, whatever,
in the application directory. This includes any "data" that ships
with the application and doesn't change (e.g., images used for toolbar
icons).
2. User-specific configuration information stored on a per-user basis.
3. Other (non-configuration) files that the user has created.
The uninstaller should always remove part 1 completely, ask whether to
remove part 2 (config files) or not, and leave part 3 (documents) alone.
On Windows, these things would typically be in Program Files, Application
Data, and My Documents, respectively. On Unix parts 2 and 3 are in the
user's home directory, and part 1 is in
between
sometimes the prefix may be
> INI writes. If an INI file is used, the official way to write to it is
> with as system call.
There are other, better ways to store configuration information than system
INI writes. The registry is useful for things like setting up associations,
but storing all of the app's config information there is a major mistake,
as it makes it virtually impossible for a user to maintain separate versions
of your app in different directories. (If you don't think users will want
to do this with your app, you're either more naive than you let on or your
app is too simple to need updates to a new version.)
Regular old application-specific configuration files are actually a very
nice, clean solution that works well and has no disadvantages.
> Getting around without a watch only works when the rest of the timepiece
> slaves willingly chain themselves and give us the time when asked to do so!
Wearing a watch would be pointless for me, because what time would I set it
to? I'd have to have one with multiple timezones, so I could set one tz to
work time, one to home time, one to the *real* time, and so on and so forth.
Then I'd have to try to remember which was which. No thanks. I'll just use
the clocks on the wall in each location, since those always tell the "right"
time for where I happen to be just then. I haven't worn a watch in fifteen
years, but I never have to ask anyone the time; I just look at a clock.
> Another practical use, is source code printed on fan-fold, tractor-fed
> paper. I've been adjusting to tryint to manage large chunks of code only
> in a small window, but when you have to check something further down the
> current section, it gets really annoying.
You need an editor with easy window splitting and/or text folding and the
ability to flip instantly between multiple cursors. I used to swear by
continuous-feed desk-checking, but since I learned Emacs I've not had the
urge to print out source code even once.
> CLI
CLI isn't *old* enough to die. It's barely fifty years old, and in its current
modern form (with e.g. smart completion that knows to complete a directory
name after one type of command or any filename after another et cetera) is
less than ten years old.
You want technology that is *totally* obsolete and just *refuses* to die,
that is still used by everyone all the time, you have to look at something
older than CLI. Paper comes to mind. Radio is a bit newer but doesn't show
any signs of dying either, despite being declared dead the minute television
started to get popular.
Target a virtual machine. The z-machine is obvious if you don't need graphics
and is probably the second-most-portable format after plain ASCII text. (The
only other serious contender is HTML, but HTML is less consistent, and the
z-machine is much more powerful and was designed for games.)
You mention graphics, though, so if that's important, look into a different
virtual machine. glulx supports some graphics for example. Of course there's
Java, but it's more heavyweight and so less portable. Parrot is probably not
ready for primetime yet, though it's one to watch in the years to come. I am
sure there are other choice I'm forgetting at the moment.
The advantage of targeting a VM is that you don't have to do the portability
work; it's been done. You write once for the VM, and it runs on every platform
that has an implementation of that VM. The z-machine is best, because there
are multiple implementations of it on pretty much every platform, from Acorn
to Gameboy. (It was designed to be implemented on 8-bit micros in the 80s,
so it fits easily on handheld systems today.) The big problem with the
z-machine, of course, is no graphics.
> Actually I think my suggestion would require minimal effort. All you have
> to do is go to the code that adds links to the hash table, and make it
> add several links.
I doubt it. That might give you the functionality you want (well, the backend
support for it; a little XUL here and script there for the rest), but then
you've probably broken six other unrelated things and will end up with a pile
of bugs in your lap and have to back out your changes until you can integrate
them into all of the other stuff that the former implementation was integraed
into.
> The only defect [...] you could fix [...] by adding an extra character
> to the end of all the prefixes
That would be a fairly brittle implementation. If you want your browser to
be robust, you need to avoid doing stuff like that and implement things that
you implement properly (i.e., the mechanism that remembers visited links
would need flags and stuff and almost starts to feel like a database --
or else you could accept the perf hit and toss the hashing in favor of
a sorted list).
> Don't bother trying to rate limit downloads; you'll get exactly the same
> number of people downloading everything, except that instead of doing it
> quickly they'll leave wget running all week and tying up your server's
> resources.
Rather than slowing the transfer, I'd send a 503 response to clients that
have pulled too much in the last hour/day/week/whatever. If you have to
send the same client too many 503s in too short a time, switch to 403.
If you're concerned about really persistent people continuing to pull
down your content even if it takes all month, just double the delay that
you make them wait after each file. (Dialup users on a dynamic IP can
get around this by redialing, but dialup users are unlikely to be your
big problem, in terms of transfer limits.) At some point it becomes less
painful to find a mirror than to wait another three weeks. Combine this
with seeding a torrent and pasting information about it all over the front
page, and you should make a big dent in your problem.
> Have a page [...] that all your links point to, and have that page
> return <meta http-equiv="Refresh" content="1;URL=files/$filename">
> This totally breaks wget, although it's not too hard to script around.
I could get around that in thirty seconds with WWW::Mechanize.
> If you enable referer checking, this will stop most wget type programs.
...) while it happens in the background.
This won't phase WWW::Mechanize one iota. When it follows a link, it sends
the referer just like any other browser, unless you tell it otherwise.
You really are going to have to throttle based on client IP. They can't fake
that if they want to get the information back, so you can positively identify,
"this is the same host that has already requested n pages in the last thirty
seconds".
If you throttle overall, without throttling based on IP, the people using wget
or whatever will be virtually the only people who can get to the content; a
real browser will take so long nobody will wait for it, but the people using
wget aren't waiting for it; they're doing other stuff (going to work, sleeping,
eating, reading books, programming,
They probably won't even notice the throttling. No, if you want "regular"
users to get your content but want to limit the people who are slurping the
whole site automatically, you've got to limit how much any particular host
can retrieve per minute/hour/whatever.
I also concur with whoever said, "seed a Torrent of the whole thing". If
aside from the bandwidth hit you don't mind letting people mirror the whole
thing, this gives them a way to do it without costing you so much bandwidth.
> Set up javascript links, which wget can't follow.
.js file. The
It's possible for clueful scripters to get around this using WWW::Mechanize,
as I had to do in my script that retrieves database usage stats for the
commercial databases we subscribe to at work. Ebsco's usage stats thingydoo
uses script links that call functions in an external, linked
functions then change certain form elements and submit the form. So I just
told my WWW::Mechanize browser object to change the form elements in question
and submit; problem solved.
Now, if each and every link were slightly different in how it works, then
only the most dedicated scripter could write the script to slurp your site
(without just implementing ECMA script and a DOM on top of WWW::Mechanize).
However, setting that up would be a lot of trouble, as the site maintainer
would have to spend O(n) time where n is the number of links. No fun.
A better solution would be to limit how many files a given host can request
per minute and send a 503 response for any that go over.
> Best solution I can think of is to also hash each of the different lengths
> of prefix at the same time you hash the full URL.
Right, but my point was that this would require changing the whole mechanism by
which the browser keeps track of visited links. That's pretty a central little
bit of funtionality that's been around forever, so it's vey likely that any
changes to it will impact various other parts of the browser. i.e., this is
the sort of change that causes a lot of regressions and has to be tested quite
thoroughly before it can be put into a release. That is to say, it would be a
lot of work. It's not the same sort of relatively easy change as merely putting
the FQDN in a different color from the rest of the URI (though even that would
probably need backend support).
> Would anyone have a legal leg to stand on if they went up against the might
> of the army of MS lawyers?
You might *theoretically* have a case, but they'd tie you up in court so long
your great grandchildren would have osteoarthritis before you got anywhere.
It ain't worth it. Just use Mozilla.
> In my personal Utopia -- indeed, when or if I run my own company with more
> than just me as an employee -- I'll be happy to have a standard operating
> environment. However, said SOE would have at least two browsers, being the
> OS default if one exists, for whichever OS I happen to choose to run on,
> and a well used alternative
On an OS that was designed for security from early on, you could allow the
user to install whatever they want in their home directory (subject to quotas).
Under Windows, however, that is not such a good idea. If I were to recommend
something for an IT department of a company with a number of employees, the
first thing I'd recommend is thin clients. Users who use the *nix system
could install software in their home directories; if it needs to be installed
anywhere else, IT has to approve and install it. Anyone using the Windows
system would only be able to use software that the IT department had installed
on the server. (It's not wise to allow Windows users to install just anything;
there's a big fat local root hole that's quite old now and Microsoft admits
cannot be fixed without breaking the Win32 API.) Now, I wouldn't limit them
to one browser necessarily, but if they wanted to use a particular browser
(or whatever) they would have to get IT to install it, so IT would be aware
of it. (Keeping a complete catalog would be a good idea.)
> It's part of our IT department's standard operating environment to have MSIE
> as the only browser on Windows platforms. It's also part of their policy
> to prevent additional programs -- specifically including web browsers of
> any kind -- from being installed
Start working on your resume -- you'll eventually need it, because it's
obvious that the IT department is utterly incompetent, which means the
management is incompetent enough that they don't know whether their staff
are able to do their job... the company is not good, long-term, for your
career. Keep the job until you find another one, but be looking.
Note that limiting the software users can install is not in itself a bad
thing (I absolutely will not permit Outlook inside the firewall, for example,
and not just anyone can install software), but settling on the least secure
browser available as the one and only choice is a *very* bad sign. If
management keeps these guys more than a year, you want to be elsewhere.
> Their reasoning? Security.
This is their *stated* reason. They probably have some other "real" reason,
though it may not make much sense either. Nevertheless, here be dragons.
> for every single windows user to see and read, repeatedly, until they
> get the hint.
You're dreaming. That can never happen. But it would be nice if the IT
guys at least got the hint.