> many server applications are very CPU intensive.
*Some* are (terminal servers and application servers being obvious examples; database servers can also be in this category), but *most* server applications are bottlenecked by disk performance, RAM, or the network.
Mail servers, for instance, are all about drive space and bandwidth. Most web servers are all about RAM and bandwidth (although, if the website depends heavily on a lot of database interaction, then the database server becomes the bottleneck). File servers are mostly network latency, also bandwidth and disk size and performance. Print servers are all about bandwidth and RAM. News servers are all about drive space and bandwidth. CPU performance is almost a complete non-issue for these common kinds of servers.
> When was the last time you played a silly game like Mario Kart DD on a 9' (yes, feet, > not inches) diagonal HDTV projector
Great, that's all I need, a nine-foot display that can handle only a fraction of the resolution expected of a decent 21" monitor, so you end up with pixels the size of your head. Yeah, that just looks so *great*.
> My friends may consider superior to be locally shared gameplay experiences > (not over the internet)
That's kinda what the whole LAN thing is all about. You may have heard of this thing called "ethernet" that's getting to be more common all the time, to the point where even printers are coming with support for it out of the box now?
> Please compare the price of the console to the equivalent hardware you would buy for a PC > at that time
Some of us kind of have to have PCs around anyway, for other reasons, so the additional gaming hardware basically boils down to 1) the price difference between a 2D video card and a 3D-accelerated one (because if it weren't for games I'd be happy with a 2D card) and 2) the controllers (assuming you don't prefer keyboard or mouse). At one time the 3D acceleration could add quite a bit to the cost of a video card, but these days even the brands that are primarily famous for their 2D quality and multi-display features (primarily, Matrox) also throw in passable 3D acceleration at no extra charge. These are not the cards the gamers tend to go after, but they get the job done, so for those of us who would buy a good video card anyway for its features that relate to getting work done, the extra hardware cost for gaming is basically just the controllers. IOW, the software cost of the games themselves is pretty much the whole cost.
> Do you know how many people still play dreamcast and ps1 games?
People still *play* Intellivision games, but there's not a lot of profit in writing new ones.
> Here's a hint. It MOSTLY all about the gameplay.
This is true. Cutting-edge graphics only get a game so far; to really make it big, a game has to be fun to play.
> What's the most popular in terms of bestselling game ever?
Probably checkers, or maybe solitaire, but this is neither here nor there.
> Plus, you'll then be able to practice anywhere there's a piano, rather than being tied > to your computer.
Oh, yeah, that'd be great, because pianos are so much more common than computers. I mean, sure there are a few computers here and there, but there are pianos in practically every building -- homes, offices, schools, libraries,... even airport terminals often have pianos, so that travelers can peck out a few notes on the way while they wait for their flights...
> and for the DOS user in you, you can use the PLAY command in QBASIC or QuickBASIC
For DOS users there is Pianoman, which is fairly advanced in terms of what it can do, up to and including timesharing the monophonic PC speaker between parts to simulate harmony. Pianoman was *the* way to go for music on the PC, until sound cards came along.
Cringe? Why? I think it's great that the microcomputer software company Microsoft Corporation is going to build native support for the portable PDF document format into their Office suite of office software, so that users can take their Word word processing documents that are in Word.doc document format, and also their enriched electronic email messages in RTF text document format, and export them directly to portable PDF document format documents.
> Often when articles are presented in other formats -- html and text -- you loose the > formatting, and vitally, the page numbers which makes referencing that much more difficult.
The MLA has a different citation format for electronic resources, one that is not reliant on page numbers. I find it difficult to believe you are working on an academic dissertation and are not aware of this (unless you're in one of those thrice-becursed departments that are still using APA style, in which case, my heart goes out to you).
> I often print articles out on the Uni machines before handing them in, but because of > different MS Word versions, software and hardware setup, your perfectly formatted essay (on > your home machine) can look bizarre on the Uni computer. Saving it as a PDF means that I can > be sure that when I come to print it at Uni, all my formatting stays the way I intended it.
This really is the primary purpose of PDF: a device-independent intermediate format for printing. It's also great for submitting documents to a commercial printing house when you have no idea what their setup is, software-wis, and they may not have the software *you* are using, either. In other words, PDF is the successor of PostScript. It is *NOT* a general-purpose information format, and it *SHOULD NOT* be used for distributing information online (except for things like IRS tax forms, which are intended to be submitted back in paper form and need to be formatted exactly as intended; and, arguably, in that case you're not so much distributing information as providing a mechanism for collecting it; I do wish the IRS would publish their *instructions* (not the forms themselves) in a more flexible format). PDF *SHOULD* be used for transferring a document that is to be printed from the computer on which it is composed to a different computer that will handle the printing, in situations where sharing the printer over the network to the source system is impractical.
For online distribution of information, XHTML is a pretty good format.
> There is a pint of beer sitting on my desk waiting for the first person who can name a > reasonably successful product or technology - past or present - which Microsoft pioneered.
I don't want any beer (yuck!), but I _think_ Microsoft may have been first, or at least the first *major* software company, to build fully customizable toolbars into their applications, a feature that is now pretty much a must for any major GUI application. Microsoft had them in the *early* nineties, if not the tail end of the eighties.
However, in general, Microsoft does do a tremendous job of assimilating technologies that were pioneered elsewhere. Stated another way, the "not invented here" complex that is so rampant at so many software companies (especially ones that make their own OS, e.g., Sun), is practically absent at Microsoft. Somebody else makes something we *should* have built into the OS in the first place? Buy it, or clone it, then bundle it. Some of the first examples of this that I remember noticing include DOSEDIT => DOSKEY, Stacker => DoubleSpace, and DOSSHELL (which copied various and sundry third-party file management and task swapping applications but AFAIK was developed in house).
Ultimately, this practice is arguably very good for users. (Okay, DoubleSpace wasn't so good, but then, there were some real problems with Stacker as well. Fortunately hardware drive sizes have now reached the point where this technology is largely superfluous.)
Does this just mean built-in support for exporting to PDF (a la OpenOffice), or are we actually talking about the ability to open a PDF, make changes, and save? The former would be nice, but the same effect can be achieved with various freely available utilities that allow "printing" to PDF from any application, so it wouldn't really be a very big deal. However, if we're talking about the ability to actually open PDFs and edit them, that's entirely another matter, and could be a really compelling feature for some people.
> Show me a market where companies are letting go of their best people and ignoring the > needs of their customers and I'll come running to start a business there.
Local telephone companies do that. And yes, if you start a competing one in my area and offer to sell me (land-line) phone service, I would be happy to pay you five bucks a month more than I'm currently paying Verizon North, just to get out from under them. And if you can manage to make the line suitable for DSL, that's worth more again.
Re:Better than post-it notes
on
Too Many Passwords
·
· Score: 2, Insightful
> To authenticate, the website encrypts a word with [your public] key and shows it > on a page; you decrypt it and enter the original word.
Right, so every computer you ever need to use to access a website (the one at home, the one at work, the one at the library, the one at your brother's place,...) needs the cryptography software (yeah, just *try* talking the IT deparment into *that* one) and *potentially* might obtain a copy of your private key.
This *might* work for people who carry around a PDA, because they could do the encryption/decryption on the PDA. Then as long as you don't lose the PDA, your private key can remain secure.
I think the real problem is the burning need people feel to protect *everything* with the same level of security. I mean, really, does your account with every web forum or online retailer you ever visit *really* need a unique, secure password? Couldn't 99% of them use the same password? Seriously, save your memory for *important* stuff, like your bank password, your ssh account on the server at work, and so forth.
Granted, some of us have jobs that by their nature mean a larger number of secure passwords needed, but that's mostly IT professionals -- system administrators and the like. Ordinary end users don't need so many. Ask yourself, "What are the consequences if a criminal gets this password?" If the answer is something like, "I might have to create a new neopets account, if I still want to play these cheesy games", then by all means, use the same lame password you use for everything else that doesn't matter. If the answer is more like, "I could lose thousands of dollars", then spend the time you need to generate and memorize a unique secure password.
> The one area that has always annoyed me with postgresql and mysql was the lack of a > good backup system.
I've not had any trouble. Here's my system for taking a backup of a MySQL database:
1. Get a read lock on the database. (This allows other processes to continue to _read_
the database, but if they try to _change_ anything they'll be delayed...) 2. cp -r/var/lib/mysql/backup/mysql 3. Release the read lock. (Steps 1-3 are preformed by a nightly cron job). 4. Arrange for the contents of/backup/mysql to be backed up in the normal way,
e.g., to tape, across the network, or however.
How long step 2 takes depends, of course, on the size of your database and the performance of your hardware (especially, the drives in question). Use a local drive for/backup to avoid unnecessarily long delays during the read lock; you can then copy it from there over the network in step 4, while the database is not locked. Also, schedule steps 1-3 at a time when database usage, especially writing, is at a minimum. Step 4 can take place whenever.
If you have multiple databases, you can either lock and copy them all at once (easier, better consistency across databases (if that matters, which with a good design it might not)) or individually (shorter lock durations), depending on the needs of your scenario.
According to SQL in a Nutshell, the usual test for this is Codd's Rules. At the time the book was written, MySQL was the only one of the four covered implementations (the others being PostgreSQL, Oracle, and MS SQL Server) that didn't qualify, since it didn't support views or atomic transactions. The copyright date on this says 2001.
Whether MySQL has since gained views and atomic transactions, I don't know. They're both features I haven't yet personally run into a need for, so I haven't checked. That said, I do want to experiment with PostgreSQL at some point; I've heard nice things about it and would like to work with it and get some experience with it. (Oracle, too. That would look nice on my resume.)
And I'm glad to see MySQL getting stored procedures. That's a feature that a lot of ISVs use in their database-using products, and a key reason sometimes cited why their product relies on a particular RDBMS, e.g., Polaris Library Systems has stated that stored procedures are a key reason why their software only works with MS SQL Server. (The other reason they cite is price. Yes, really; I assume they're counting Oracle as the competition when they say that one. And the _real_ reason is because they're pretty much a Microsoft-only shop, same reason they require IIS, too, citing ISAPI, as if Apache doesn't have an excellent extension mechanism. Nevertheless, stored procedures are a valid excuse, and taking away such valid excuses is a good thing.)
> Furthermore, you appear to believe that just because there is no strict word order in a > given language, there is also no preferred word order. You are, naturally, completely wrong. > Yoda-speak translates to Croatian very easily, and I imagine it would translate to nearly > any language in the world.
It does not translate to common Greek. Or, rather, it doesn't seem unusual when translated. Subject first? Verb first? Direct object first? Indirect object first? It makes no difference; you say first whichever one you want to emphasize most, or just pick one. It doesn't even matter whether the subject or the predicate nominative is first in a sentence with an implied linking verb; even though the subject and the nominative both use the same case, there are other markers to determine which one is which, so the word order goes either way.
Word order doesn't matter for adjectives either; they go before or after the word they are modifying, whichever is more convenient. Either way is the attributive position if the adjective has the article (or the predicate position if the noun has it and the adjective does not; if neither has the article, it can go either way; if there's no noun, the adjective is being used as a noun, which is very common). All of this is true irrespective of whether the adjective is an individual word, a phrase (e.g., a prepositional phrase) or a clause.
There are places where word order matters, of course. Prepositions always precede their objects, for instance, and relative clauses are always introduced by the relative pronoun.
> The English grammatical structure was primarily taken from early Germanic languages > (probably from early Scandinavian)
Probably from a mixture of several Northern-European languages, *including* Scandinavian ones, but likely others as well. However, significant modifications have occurred over the years.
> whereas our core vocabulary is mainly derived from Latin
The bulk of our vocabulary overall comes from Greek, Latin, and French (probably in that order; if you count French words that are ultimately of Latin origin as Latin, then Latin etymologies certainly outnumber Greek ones, and they *might* anyway, depending on how you count), but a higher percentage of the *core* vocabulary (i.e., the couple hundred or so most common words, such as the articles, coordinating conjunctions, common prepositions, pronouns, and so forth) come from the Germanic languages.
> Although English has become quite a bit removed from its Germanic origins, our grammatical > structure still greatly resembles German in many aspects.
It resembles it, but the differences are nonetheless significant. Adjective placement is handled differently. Word order has so increased in importance as to pretty much obviate inflectional case, resulting in the discarding of a number of inflectional features. Additionally, the influence of people educated in Latin on the way English grammar has been taught over the years has succeeded in transplanting some aspects of Latin grammar into English, e.g., the way certain sentence patterns involving verbals are handled.
Nonetheless, it's certainly true that English grammar derives largely from Germanic languages, while a lot of the vocabulary has been imported from elsewhere.
> Latin and Greek are not related any closer than Latin and Hittite > or Latin and Sanskrit
I'm not sure where Hittite fits in, but Latin and Greek are a little more closely related, and a good deal more similar, than Latin and Sanskrit. Yes, Sanskrit ultimately comes from the same indo-european roots, and no, Latin doesn't come from Greek, but nevertheless, the peoples who populated Greece and what is now Italy did have some common roots that were more recent than their connection to the Hindustani peoples.
> Latin is a member of the Latin/Faliskic group, while Greek has > no close relatives.
"Close" is relative. Granted, Latin and Greek are nowhere near as closely related as, say, French and Italian. But Sanskrit is even more distant.
And, intuitively, you can actually tell this from the languages.
Just for instance, Latin and Greek both get their writing systems, ultimately, from middle-eastern peoples (traditionally, the Phoenicians are the usual guess as to the origin, but in any case it is clear that the alphabet was developed in the middle-east). The devanagari syllabary, and the various earlier scripts used to write the hindustani languages, appear to have been developed on the Indian subcontinent. The writing systems of course developed after the languages themselves were already differentiated, but the differences in the writing systems are indicative of important underlying linguistic differences. (The very idea of writing Latin or Greek with a syllabary seems a bit odd, because the languages aren't structured that way.)
Getting back to the sort of thing this article is talking about, then, Latin and Greek also, once you get past the obvious superficial differences, bear some striking grammatical resemblances, ties that are stronger than merely both being of distant indo-european origin. The grammatical structures are similar -- much more similar than, say, from either one to English. They're both, for instance, difficult to categorize in terms of SVO / SOV / OSV / OVS / VOS / VSO, and for largely the same reasons. (In layman's terms: you can't translate Yoda's speech into either of them, and get the same "weirdness" effect, because word order just isn't used that way in these languages; Yoda would blend right in with everyone else; if you turned his word order around the other way, to match English usage, he'd *still* blend right in with everyone else.)
Perhaps more interesting, both languages were *changing* in similar ways during the same time period. They both have morphological relics from earlier, now-unknown versions of the language that had additional phonemes and additional grammatical features (additional cases and tenses, for instance, e.g., Greek at one time had a pluperfect, but by the third century it had faded largely out of usage), and they both were in the process (during the time of the Roman empire) of losing some of their more complex grammatical features, such as some of the less common moods (e.g., the optitive), and eventually they both gave rise to modern languages with significantly less inflection and simpler grammars (respectively, the Romance languages, or modern Greek).
I would not dismiss the connections between Latin and Greek as "no more closely related than Latin and Sanskrit". They have too much in common.
> > I want Perl 6 to be the community's rewrite of Perl and of the community.
> And that's the chief reason why it's a directionless (or perhaps I should say > omnidirectional)
Omnidirectional is closer.
> disaster that's not even close to production-ready after all these years. Programming > language design by committee does not work.
It takes a long time, granted. But it does work, *eventually*, and we're now basically there. The design has now been *essentially* complete for about half a year, and actual implementation work has at long last been moving -- moving *rapidly*. Since the two most important Apocalypse documents (6 and 12) were (*finally*) published, Perl6 has suddenly gone (in terms of the existence of a usable compiler) from basically 0% done to something like 20% done, and most of that work has been done in the last four months. There are now already (as of a couple of months ago, actually) a very small handful of people (extreme early adopters -- crazy people, IMO, but nevertheless) using Perl6 code *in production*. At the rate things are moving now, there is a non-trivial probability that a Perl6 compiler will beat Vista out the door to release. It is even conceivable that two feature-complete Perl6 compilers will be released before Vista (one written in Haskell, and the other in Perl).
Yeah, it was a long time coming, and Ruby and Python both have siezed on that opportunity (and PHP tried to, but programmers took one look at it and saw what looked like a markup language and collectively shrugged). So Perl6 will have competition. That's a good thing, IMO; having multiple languages to choose from gives us more options and more possibilities. And Perl6 does indeed borrow some concepts from Ruby -- and some from Smalltalk, and many from Lisp, and some from Scheme, some from Haskell, one or two from Prolog, a little from Python,... this is why users of other languages are so intimidated by Perl: it's like the Borg of programming languages, actively seeking out other languages and assimilating their technological and cultural distinctiveness. By 5.005, Perl had already taken from C and C++ that was worth taking (at the language level; optimizing compilers are another matter), so since then it's been looking elsewhere.
> If the encryption software in my web browser is a weapon, this satellite is a weapon.
The encryption technology was classified as a *munition*, not a weapon. (It's still silly to classify encryption as a munition, but that's irrelevant for purposes of this discussion.)
Over time, one of three things happens to every large software project. The most common, of course, is that it becomes obsolete and irrelevant and is replaced by other projects. The least common of the three, traditionally, is that the code is continually refactored, a bit at a time, as a regular feature of the development cycle. Pegasus mail is a good example of this approach: every major release, David Harris refactors some major subsystem or another. Perl was also maintained this way, but *still* eventually reached the point of needing the third possibility: a complete rewrite more-or-less from scratch. (Some things can be re-used when this happens, e.g., documentation, especially API documentation, in the case of an OS; for Perl even the documentation needed to be redone for 6.0.)
The Win9x codebase already reached the point, around the turn of the century, where refactoring wasn't going to help it, and Microsoft chose, rather than rewriting it, to obsolete it in favor of the NT codebase -- probably the right choice. But then the NT codebase has also reached the same point, and rather than obsolete it they chose to rewrite it. Also probably the right choice.
This explains the delays, incidentally.
The thing to take away from this is that, public beta notwithstanding, the first release of Vista could be a bit dicey until it's been in the wild for a while, some of the unintended differences discovered (there are *always* unintended differences when something is re-implemented from scratch), the first couple of service packs issued, and ISVs given the chance to update their software. IT departments might want to delay Vista rollout a few months after its release, to give these things a chance to play out. I know after the long wait people will be eager to get their hands on the new version, but you might want to run it on a testing or sandbox system at first.
> > I think people would be more familiar with the "web browser" term than > > the less accurate "internet browser" term. > > Actually, most people refer to IE as "the Internet".
Actually, most people aren't really clear on the difference between their operating system, the company who created it, their web browser, their internet service provider, their modem, their hard drive, and the company that made their computer. They refer to IE, when they do distinguish it from those other things, as "that blue e thing". Here is a typical conversation...
User: I'm having trouble with my computer. Me: What seems to be the problem? User: Yahoo doesn't work right. Me: What seems to be the problem with Yahoo? User: It won't go. Me: Hmmm... Are you connected to the internet? User: How can I connect to the internet if I can't get Yahoo to work? Me: Are we talking about Yahoo, the web site, or Yahoo, the instant messaging
application, or something else? User: I don't know. Me: What program or application are you using to get to Yahoo? User: Microsoft. User: No, I think that's wrong. Maybe it's Compaq. Me: Okay, what do you click on to try to get to Yahoo? User: I don't know. It just comes up. Except now it doesn't.
I'd go back to the original definition: a celestial body, visible with the naked eye from Earth, which (phenomenologically) 'wanders' or 'moves' relative to the backdrop of stars. This would include comets, the moon, and the Sun, but it would exclude Kuiper belt objects, because they can't be seen without the aid of telescopes. It might exclude Uranus and Neptune as well, for the same reason.
Excellent piece of music that. Shickele is an unsung genius...
> I understand the *what* and the *how*, I'm just not surely I > really understand the *why*.
Presumably, so that people who prefer the suite can get the advantage of any recent Gecko rendering engine improvements. Duh.
Why would someone prefer the suite? Well, at first I preferred Navigator over Firefox because the Firefox extension management mechanism frankly sucks. (The existence of the extension mechanism is important, and the idea of leaving many features to extensions is not really the problem, but among other things there's no easy way to say "I want this extension, and this one, and this one, and this one, and that one" and have them all download and install as a batch. Then there's the trial-and-error uninstall-half / test / reinstall-half method you have to go through if one of your extensions is causing you trouble; the UI for this is abysmal, and reinstalling requires re-downloading, which is totally unacceptable for people on dialup.)
I did eventually switch from Navigator to Firefox, after the first major round of improvements to the extension mechanism (notably, extensions now persist when you install a new version of the browser; without that, I was sticking with Navigator just because it had some of the most important extensions built in). However, the browser is the only component that I use. I can easily see why someone who also uses the Mail/News component, for instance, might prefer the suite. Fundamentally, Navigator is still a quite usable browser, containing all of the most important feature innovations that Firefox has. It's not the latest and greatest thing that the Mozilla Foundation is excited about, but it's not exactly some crufty old twentieth-century browser with no features, either. Really it's pretty good, and still has its fans. It just hasn't garnered the mainstream attention that Firefox has.
> Basically, the only thing that Windows can do that Linux can't is get > viruses and crash.
Oh, Linux can crash. It can crash pretty impressively. Especially if your IDE controller goes bad. That can be all kinds of fun.
Oh, you meant crash for no particular reason on perfectly good hardware? In that case, only the GUI crashes (i.e., the X Window System, though it takes all your graphical apps with it). I haven't seen a Linux *kernel* go south, except in cases of bad hardware, since the vmm was changed to handle out-of-swap-space conditions by killing off the memory-hog app. I don't remember exactly what version that was changed in, probably between 2.2 and 2.4, or it could have been between 2.0 and 2.2, I don't recall.
Of course, for most desktop users, a crashed GUI is vanishingly close to just as bad as a crashed kernel. I do hope, now that X.Org seems to have gotten X11 development moving faster again, that stability becomes a priority. No matter what an app does, the X server shouldn't crash, EVER. In this regard, the stability of a typical Linux desktop is about the same as a (protected, firewalled) Windows XP system. (I still prefer the Linux/X11 system, because it's rather more configurable, but that's a separate issue from stability.)
I'd also like to see the ability to disconnect from an X app (or session even) but leave it running and reconnect later, possibly from a different location -- like what Gnu screen does for the tty, but on the desktop. Done right, this should mean that even if the X server does crash, it doesn't take the apps with it and can be restarted and you go on as if nothing happened. That would be worth a lot more than transparent windows. (Not that I don't want transparent windows; I do. But stability is more important.)
All else being equal, newer algorithms aren't inherently safer than older ones and won't necessarily take longer to become obsolete. Schneier goes so far as to say that new crypto algoritms should not be trusted until they've stood the test of time for a while.
Of course, there are older algoriths, and then there are older algorithms with known flaws (of varying degrees of severity), so the above is just a general observation.
The issue of key size is different; the same algorithm with a larger key will generally be more durable over time, so moving to the largest key size that's practical with current hardware would be a Good Thing; if a vulnerability in the algorithm is subsequently discovered, the larger key size doesn't really *solve* that problem, but it can help to reduce the impact.
Slashdot Mirror
> many server applications are very CPU intensive.
*Some* are (terminal servers and application servers being obvious examples; database servers can also be in this category), but *most* server applications are bottlenecked by disk performance, RAM, or the network.
Mail servers, for instance, are all about drive space and bandwidth. Most web servers are all about RAM and bandwidth (although, if the website depends heavily on a lot of database interaction, then the database server becomes the bottleneck). File servers are mostly network latency, also bandwidth and disk size and performance. Print servers are all about bandwidth and RAM. News servers are all about drive space and bandwidth. CPU performance is almost a complete non-issue for these common kinds of servers.
> When was the last time you played a silly game like Mario Kart DD on a 9' (yes, feet,
> not inches) diagonal HDTV projector
Great, that's all I need, a nine-foot display that can handle only a fraction of the resolution expected of a decent 21" monitor, so you end up with pixels the size of your head. Yeah, that just looks so *great*.
> My friends may consider superior to be locally shared gameplay experiences
> (not over the internet)
That's kinda what the whole LAN thing is all about. You may have heard of this thing called "ethernet" that's getting to be more common all the time, to the point where even printers are coming with support for it out of the box now?
> Please compare the price of the console to the equivalent hardware you would buy for a PC
> at that time
Some of us kind of have to have PCs around anyway, for other reasons, so the additional gaming hardware basically boils down to 1) the price difference between a 2D video card and a 3D-accelerated one (because if it weren't for games I'd be happy with a 2D card) and 2) the controllers (assuming you don't prefer keyboard or mouse). At one time the 3D acceleration could add quite a bit to the cost of a video card, but these days even the brands that are primarily famous for their 2D quality and multi-display features (primarily, Matrox) also throw in passable 3D acceleration at no extra charge. These are not the cards the gamers tend to go after, but they get the job done, so for those of us who would buy a good video card anyway for its features that relate to getting work done, the extra hardware cost for gaming is basically just the controllers. IOW, the software cost of the games themselves is pretty much the whole cost.
> Do you know how many people still play dreamcast and ps1 games?
People still *play* Intellivision games, but there's not a lot of profit in writing new ones.
> Here's a hint. It MOSTLY all about the gameplay.
This is true. Cutting-edge graphics only get a game so far; to really make it big, a game has to be fun to play.
> What's the most popular in terms of bestselling game ever?
Probably checkers, or maybe solitaire, but this is neither here nor there.
> Plus, you'll then be able to practice anywhere there's a piano, rather than being tied
... even airport terminals often have pianos, so that travelers can peck out a few notes on the way while they wait for their flights...
> to your computer.
Oh, yeah, that'd be great, because pianos are so much more common than computers. I mean, sure there are a few computers here and there, but there are pianos in practically every building -- homes, offices, schools, libraries,
> and for the DOS user in you, you can use the PLAY command in QBASIC or QuickBASIC
For DOS users there is Pianoman, which is fairly advanced in terms of what it can do, up to and including timesharing the monophonic PC speaker between parts to simulate harmony. Pianoman was *the* way to go for music on the PC, until sound cards came along.
Cringe? Why? I think it's great that the microcomputer software company Microsoft Corporation is going to build native support for the portable PDF document format into their Office suite of office software, so that users can take their Word word processing documents that are in Word .doc document format, and also their enriched electronic email messages in RTF text document format, and export them directly to portable PDF document format documents.
> Often when articles are presented in other formats -- html and text -- you loose the
> formatting, and vitally, the page numbers which makes referencing that much more difficult.
The MLA has a different citation format for electronic resources, one that is not reliant on page numbers. I find it difficult to believe you are working on an academic dissertation and are not aware of this (unless you're in one of those thrice-becursed departments that are still using APA style, in which case, my heart goes out to you).
> I often print articles out on the Uni machines before handing them in, but because of
> different MS Word versions, software and hardware setup, your perfectly formatted essay (on
> your home machine) can look bizarre on the Uni computer. Saving it as a PDF means that I can
> be sure that when I come to print it at Uni, all my formatting stays the way I intended it.
This really is the primary purpose of PDF: a device-independent intermediate format for printing. It's also great for submitting documents to a commercial printing house when you have no idea what their setup is, software-wis, and they may not have the software *you* are using, either. In other words, PDF is the successor of PostScript. It is *NOT* a general-purpose information format, and it *SHOULD NOT* be used for distributing information online (except for things like IRS tax forms, which are intended to be submitted back in paper form and need to be formatted exactly as intended; and, arguably, in that case you're not so much distributing information as providing a mechanism for collecting it; I do wish the IRS would publish their *instructions* (not the forms themselves) in a more flexible format). PDF *SHOULD* be used for transferring a document that is to be printed from the computer on which it is composed to a different computer that will handle the printing, in situations where sharing the printer over the network to the source system is impractical.
For online distribution of information, XHTML is a pretty good format.
> There is a pint of beer sitting on my desk waiting for the first person who can name a
> reasonably successful product or technology - past or present - which Microsoft pioneered.
I don't want any beer (yuck!), but I _think_ Microsoft may have been first, or at least the first *major* software company, to build fully customizable toolbars into their applications, a feature that is now pretty much a must for any major GUI application. Microsoft had them in the *early* nineties, if not the tail end of the eighties.
However, in general, Microsoft does do a tremendous job of assimilating technologies that were pioneered elsewhere. Stated another way, the "not invented here" complex that is so rampant at so many software companies (especially ones that make their own OS, e.g., Sun), is practically absent at Microsoft. Somebody else makes something we *should* have built into the OS in the first place? Buy it, or clone it, then bundle it. Some of the first examples of this that I remember noticing include DOSEDIT => DOSKEY, Stacker => DoubleSpace, and DOSSHELL (which copied various and sundry third-party file management and task swapping applications but AFAIK was developed in house).
Ultimately, this practice is arguably very good for users. (Okay, DoubleSpace wasn't so good, but then, there were some real problems with Stacker as well. Fortunately hardware drive sizes have now reached the point where this technology is largely superfluous.)
Does this just mean built-in support for exporting to PDF (a la OpenOffice), or are we actually talking about the ability to open a PDF, make changes, and save? The former would be nice, but the same effect can be achieved with various freely available utilities that allow "printing" to PDF from any application, so it wouldn't really be a very big deal. However, if we're talking about the ability to actually open PDFs and edit them, that's entirely another matter, and could be a really compelling feature for some people.
perl
> Show me a market where companies are letting go of their best people and ignoring the
> needs of their customers and I'll come running to start a business there.
Local telephone companies do that. And yes, if you start a competing one in my area and offer to sell me (land-line) phone service, I would be happy to pay you five bucks a month more than I'm currently paying Verizon North, just to get out from under them. And if you can manage to make the line suitable for DSL, that's worth more again.
> So, like, Spaceballs could compromise my boxen?
I'd worry more about GalaxyQuest.
> To authenticate, the website encrypts a word with [your public] key and shows it
...) needs the cryptography software (yeah, just *try* talking the IT deparment into *that* one) and *potentially* might obtain a copy of your private key.
> on a page; you decrypt it and enter the original word.
Right, so every computer you ever need to use to access a website (the one at home, the one at work, the one at the library, the one at your brother's place,
This *might* work for people who carry around a PDA, because they could do the encryption/decryption on the PDA. Then as long as you don't lose the PDA, your private key can remain secure.
I think the real problem is the burning need people feel to protect *everything* with the same level of security. I mean, really, does your account with every web forum or online retailer you ever visit *really* need a unique, secure password? Couldn't 99% of them use the same password? Seriously, save your memory for *important* stuff, like your bank password, your ssh account on the server at work, and so forth.
Granted, some of us have jobs that by their nature mean a larger number of secure passwords needed, but that's mostly IT professionals -- system administrators and the like. Ordinary end users don't need so many. Ask yourself, "What are the consequences if a criminal gets this password?" If the answer is something like, "I might have to create a new neopets account, if I still want to play these cheesy games", then by all means, use the same lame password you use for everything else that doesn't matter. If the answer is more like, "I could lose thousands of dollars", then spend the time you need to generate and memorize a unique secure password.
> The one area that has always annoyed me with postgresql and mysql was the lack of a
/var/lib/mysql /backup/mysql /backup/mysql to be backed up in the normal way,
/backup to avoid unnecessarily long delays during the read lock; you can then copy it from there over the network in step 4, while the database is not locked. Also, schedule steps 1-3 at a time when database usage, especially writing, is at a minimum. Step 4 can take place whenever.
> good backup system.
I've not had any trouble. Here's my system for taking a backup of a MySQL database:
1. Get a read lock on the database. (This allows other processes to continue to _read_
the database, but if they try to _change_ anything they'll be delayed...)
2. cp -r
3. Release the read lock. (Steps 1-3 are preformed by a nightly cron job).
4. Arrange for the contents of
e.g., to tape, across the network, or however.
How long step 2 takes depends, of course, on the size of your database and the performance of your hardware (especially, the drives in question). Use a local drive for
If you have multiple databases, you can either lock and copy them all at once (easier, better consistency across databases (if that matters, which with a good design it might not)) or individually (shorter lock durations), depending on the needs of your scenario.
According to SQL in a Nutshell, the usual test for this is Codd's Rules. At the time the book was written, MySQL was the only one of the four covered implementations (the others being PostgreSQL, Oracle, and MS SQL Server) that didn't qualify, since it didn't support views or atomic transactions. The copyright date on this says 2001.
Whether MySQL has since gained views and atomic transactions, I don't know. They're both features I haven't yet personally run into a need for, so I haven't checked. That said, I do want to experiment with PostgreSQL at some point; I've heard nice things about it and would like to work with it and get some experience with it. (Oracle, too. That would look nice on my resume.)
And I'm glad to see MySQL getting stored procedures. That's a feature that a lot of ISVs use in their database-using products, and a key reason sometimes cited why their product relies on a particular RDBMS, e.g., Polaris Library Systems has stated that stored procedures are a key reason why their software only works with MS SQL Server. (The other reason they cite is price. Yes, really; I assume they're counting Oracle as the competition when they say that one. And the _real_ reason is because they're pretty much a Microsoft-only shop, same reason they require IIS, too, citing ISAPI, as if Apache doesn't have an excellent extension mechanism. Nevertheless, stored procedures are a valid excuse, and taking away such valid excuses is a good thing.)
> Furthermore, you appear to believe that just because there is no strict word order in a
> given language, there is also no preferred word order. You are, naturally, completely wrong.
> Yoda-speak translates to Croatian very easily, and I imagine it would translate to nearly
> any language in the world.
It does not translate to common Greek. Or, rather, it doesn't seem unusual when translated. Subject first? Verb first? Direct object first? Indirect object first? It makes no difference; you say first whichever one you want to emphasize most, or just pick one. It doesn't even matter whether the subject or the predicate nominative is first in a sentence with an implied linking verb; even though the subject and the nominative both use the same case, there are other markers to determine which one is which, so the word order goes either way.
Word order doesn't matter for adjectives either; they go before or after the word they are modifying, whichever is more convenient. Either way is the attributive position if the adjective has the article (or the predicate position if the noun has it and the adjective does not; if neither has the article, it can go either way; if there's no noun, the adjective is being used as a noun, which is very common). All of this is true irrespective of whether the adjective is an individual word, a phrase (e.g., a prepositional phrase) or a clause.
There are places where word order matters, of course. Prepositions always precede their objects, for instance, and relative clauses are always introduced by the relative pronoun.
> The English grammatical structure was primarily taken from early Germanic languages
> (probably from early Scandinavian)
Probably from a mixture of several Northern-European languages, *including* Scandinavian ones, but likely others as well. However, significant modifications have occurred over the years.
> whereas our core vocabulary is mainly derived from Latin
The bulk of our vocabulary overall comes from Greek, Latin, and French (probably in that order; if you count French words that are ultimately of Latin origin as Latin, then Latin etymologies certainly outnumber Greek ones, and they *might* anyway, depending on how you count), but a higher percentage of the *core* vocabulary (i.e., the couple hundred or so most common words, such as the articles, coordinating conjunctions, common prepositions, pronouns, and so forth) come from the Germanic languages.
> Although English has become quite a bit removed from its Germanic origins, our grammatical
> structure still greatly resembles German in many aspects.
It resembles it, but the differences are nonetheless significant. Adjective placement is handled differently. Word order has so increased in importance as to pretty much obviate inflectional case, resulting in the discarding of a number of inflectional features. Additionally, the influence of people educated in Latin on the way English grammar has been taught over the years has succeeded in transplanting some aspects of Latin grammar into English, e.g., the way certain sentence patterns involving verbals are handled.
Nonetheless, it's certainly true that English grammar derives largely from Germanic languages, while a lot of the vocabulary has been imported from elsewhere.
> Latin and Greek are not related any closer than Latin and Hittite
> or Latin and Sanskrit
I'm not sure where Hittite fits in, but Latin and Greek are a little more closely related, and a good deal more similar, than Latin and Sanskrit. Yes, Sanskrit ultimately comes from the same indo-european roots, and no, Latin doesn't come from Greek, but nevertheless, the peoples who populated Greece and what is now Italy did have some common roots that were more recent than their connection to the Hindustani peoples.
> Latin is a member of the Latin/Faliskic group, while Greek has
> no close relatives.
"Close" is relative. Granted, Latin and Greek are nowhere near as closely related as, say, French and Italian. But Sanskrit is even more distant.
And, intuitively, you can actually tell this from the languages.
Just for instance, Latin and Greek both get their writing systems, ultimately, from middle-eastern peoples (traditionally, the Phoenicians are the usual guess as to the origin, but in any case it is clear that the alphabet was developed in the middle-east). The devanagari syllabary, and the various earlier scripts used to write the hindustani languages, appear to have been developed on the Indian subcontinent. The writing systems of course developed after the languages themselves were already differentiated, but the differences in the writing systems are indicative of important underlying linguistic differences. (The very idea of writing Latin or Greek with a syllabary seems a bit odd, because the languages aren't structured that way.)
Getting back to the sort of thing this article is talking about, then, Latin and Greek also, once you get past the obvious superficial differences, bear some striking grammatical resemblances, ties that are stronger than merely both being of distant indo-european origin. The grammatical structures are similar -- much more similar than, say, from either one to English. They're both, for instance, difficult to categorize in terms of SVO / SOV / OSV / OVS / VOS / VSO, and for largely the same reasons. (In layman's terms: you can't translate Yoda's speech into either of them, and get the same "weirdness" effect, because word order just isn't used that way in these languages; Yoda would blend right in with everyone else; if you turned his word order around the other way, to match English usage, he'd *still* blend right in with everyone else.)
Perhaps more interesting, both languages were *changing* in similar ways during the same time period. They both have morphological relics from earlier, now-unknown versions of the language that had additional phonemes and additional grammatical features (additional cases and tenses, for instance, e.g., Greek at one time had a pluperfect, but by the third century it had faded largely out of usage), and they both were in the process (during the time of the Roman empire) of losing some of their more complex grammatical features, such as some of the less common moods (e.g., the optitive), and eventually they both gave rise to modern languages with significantly less inflection and simpler grammars (respectively, the Romance languages, or modern Greek).
I would not dismiss the connections between Latin and Greek as "no more closely related than Latin and Sanskrit". They have too much in common.
> > I want Perl 6 to be the community's rewrite of Perl and of the community.
... this is why users of other languages are so intimidated by Perl: it's like the Borg of programming languages, actively seeking out other languages and assimilating their technological and cultural distinctiveness. By 5.005, Perl had already taken from C and C++ that was worth taking (at the language level; optimizing compilers are another matter), so since then it's been looking elsewhere.
> And that's the chief reason why it's a directionless (or perhaps I should say
> omnidirectional)
Omnidirectional is closer.
> disaster that's not even close to production-ready after all these years. Programming
> language design by committee does not work.
It takes a long time, granted. But it does work, *eventually*, and we're now basically there. The design has now been *essentially* complete for about half a year, and actual implementation work has at long last been moving -- moving *rapidly*. Since the two most important Apocalypse documents (6 and 12) were (*finally*) published, Perl6 has suddenly gone (in terms of the existence of a usable compiler) from basically 0% done to something like 20% done, and most of that work has been done in the last four months. There are now already (as of a couple of months ago, actually) a very small handful of people (extreme early adopters -- crazy people, IMO, but nevertheless) using Perl6 code *in production*. At the rate things are moving now, there is a non-trivial probability that a Perl6 compiler will beat Vista out the door to release. It is even conceivable that two feature-complete Perl6 compilers will be released before Vista (one written in Haskell, and the other in Perl).
Yeah, it was a long time coming, and Ruby and Python both have siezed on that opportunity (and PHP tried to, but programmers took one look at it and saw what looked like a markup language and collectively shrugged). So Perl6 will have competition. That's a good thing, IMO; having multiple languages to choose from gives us more options and more possibilities. And Perl6 does indeed borrow some concepts from Ruby -- and some from Smalltalk, and many from Lisp, and some from Scheme, some from Haskell, one or two from Prolog, a little from Python,
> If the encryption software in my web browser is a weapon, this satellite is a weapon.
The encryption technology was classified as a *munition*, not a weapon. (It's still silly to classify encryption as a munition, but that's irrelevant for purposes of this discussion.)
Over time, one of three things happens to every large software project. The most common, of course, is that it becomes obsolete and irrelevant and is replaced by other projects. The least common of the three, traditionally, is that the code is continually refactored, a bit at a time, as a regular feature of the development cycle. Pegasus mail is a good example of this approach: every major release, David Harris refactors some major subsystem or another. Perl was also maintained this way, but *still* eventually reached the point of needing the third possibility: a complete rewrite more-or-less from scratch. (Some things can be re-used when this happens, e.g., documentation, especially API documentation, in the case of an OS; for Perl even the documentation needed to be redone for 6.0.)
The Win9x codebase already reached the point, around the turn of the century, where refactoring wasn't going to help it, and Microsoft chose, rather than rewriting it, to obsolete it in favor of the NT codebase -- probably the right choice. But then the NT codebase has also reached the same point, and rather than obsolete it they chose to rewrite it. Also probably the right choice.
This explains the delays, incidentally.
The thing to take away from this is that, public beta notwithstanding, the first release of Vista could be a bit dicey until it's been in the wild for a while, some of the unintended differences discovered (there are *always* unintended differences when something is re-implemented from scratch), the first couple of service packs issued, and ISVs given the chance to update their software. IT departments might want to delay Vista rollout a few months after its release, to give these things a chance to play out. I know after the long wait people will be eager to get their hands on the new version, but you might want to run it on a testing or sandbox system at first.
> > I think people would be more familiar with the "web browser" term than
> > the less accurate "internet browser" term.
>
> Actually, most people refer to IE as "the Internet".
Actually, most people aren't really clear on the difference between their operating system, the company who created it, their web browser, their internet service provider, their modem, their hard drive, and the company that made their computer. They refer to IE, when they do distinguish it from those other things, as "that blue e thing". Here is a typical conversation...
User: I'm having trouble with my computer.
Me: What seems to be the problem?
User: Yahoo doesn't work right.
Me: What seems to be the problem with Yahoo?
User: It won't go.
Me: Hmmm... Are you connected to the internet?
User: How can I connect to the internet if I can't get Yahoo to work?
Me: Are we talking about Yahoo, the web site, or Yahoo, the instant messaging
application, or something else?
User: I don't know.
Me: What program or application are you using to get to Yahoo?
User: Microsoft.
User: No, I think that's wrong. Maybe it's Compaq.
Me: Okay, what do you click on to try to get to Yahoo?
User: I don't know. It just comes up. Except now it doesn't.
Et cetera, ad infinitum, ad bedlam.
I'd go back to the original definition: a celestial body, visible with the naked eye from Earth, which (phenomenologically) 'wanders' or 'moves' relative to the backdrop of stars. This would include comets, the moon, and the Sun, but it would exclude Kuiper belt objects, because they can't be seen without the aid of telescopes. It might exclude Uranus and Neptune as well, for the same reason.
HTH.HAND.
> A chacun a son gout, I suppose.
Excellent piece of music that. Shickele is an unsung genius...
> I understand the *what* and the *how*, I'm just not surely I
> really understand the *why*.
Presumably, so that people who prefer the suite can get the advantage of any recent Gecko rendering engine improvements. Duh.
Why would someone prefer the suite? Well, at first I preferred Navigator over Firefox because the Firefox extension management mechanism frankly sucks. (The existence of the extension mechanism is important, and the idea of leaving many features to extensions is not really the problem, but among other things there's no easy way to say "I want this extension, and this one, and this one, and this one, and that one" and have them all download and install as a batch. Then there's the trial-and-error uninstall-half / test / reinstall-half method you have to go through if one of your extensions is causing you trouble; the UI for this is abysmal, and reinstalling requires re-downloading, which is totally unacceptable for people on dialup.)
I did eventually switch from Navigator to Firefox, after the first major round of improvements to the extension mechanism (notably, extensions now persist when you install a new version of the browser; without that, I was sticking with Navigator just because it had some of the most important extensions built in). However, the browser is the only component that I use. I can easily see why someone who also uses the Mail/News component, for instance, might prefer the suite. Fundamentally, Navigator is still a quite usable browser, containing all of the most important feature innovations that Firefox has. It's not the latest and greatest thing that the Mozilla Foundation is excited about, but it's not exactly some crufty old twentieth-century browser with no features, either. Really it's pretty good, and still has its fans. It just hasn't garnered the mainstream attention that Firefox has.
> Basically, the only thing that Windows can do that Linux can't is get
> viruses and crash.
Oh, Linux can crash. It can crash pretty impressively. Especially if your IDE controller goes bad. That can be all kinds of fun.
Oh, you meant crash for no particular reason on perfectly good hardware? In that case, only the GUI crashes (i.e., the X Window System, though it takes all your graphical apps with it). I haven't seen a Linux *kernel* go south, except in cases of bad hardware, since the vmm was changed to handle out-of-swap-space conditions by killing off the memory-hog app. I don't remember exactly what version that was changed in, probably between 2.2 and 2.4, or it could have been between 2.0 and 2.2, I don't recall.
Of course, for most desktop users, a crashed GUI is vanishingly close to just as bad as a crashed kernel. I do hope, now that X.Org seems to have gotten X11 development moving faster again, that stability becomes a priority. No matter what an app does, the X server shouldn't crash, EVER. In this regard, the stability of a typical Linux desktop is about the same as a (protected, firewalled) Windows XP system. (I still prefer the Linux/X11 system, because it's rather more configurable, but that's a separate issue from stability.)
I'd also like to see the ability to disconnect from an X app (or session even) but leave it running and reconnect later, possibly from a different location -- like what Gnu screen does for the tty, but on the desktop. Done right, this should mean that even if the X server does crash, it doesn't take the apps with it and can be restarted and you go on as if nothing happened. That would be worth a lot more than transparent windows. (Not that I don't want transparent windows; I do. But stability is more important.)
All else being equal, newer algorithms aren't inherently safer than older ones and won't necessarily take longer to become obsolete. Schneier goes so far as to say that new crypto algoritms should not be trusted until they've stood the test of time for a while.
Of course, there are older algoriths, and then there are older algorithms with known flaws (of varying degrees of severity), so the above is just a general observation.
The issue of key size is different; the same algorithm with a larger key will generally be more durable over time, so moving to the largest key size that's practical with current hardware would be a Good Thing; if a vulnerability in the algorithm is subsequently discovered, the larger key size doesn't really *solve* that problem, but it can help to reduce the impact.