> I'm really wondering why it is so much slower in linux than in windows.
I find that on the same hardware, performance is vanishingly close to the same on Windows as on Linux (unless the Linux system is booting from a LiveCD (e.g. Knoppix), in which case that's slower, due to the inherent overhead of a LiveCD system). This is with a Matrox graphics card, which works well with every OS ever devised; YMMV if you are using a card that has substantially better drivers for some OSes than for others. Also, I have adequate RAM (i.e., enough that my swap space sits unused), so if you're short on that commodity, that could mess things up for you.
I do find, however, that responsiveness is a little worse on FreeBSD (this is on 6.0). It's not bad, certainly not bad enough to tempt me to move away from BSD just for that, but enough to be noticeable. Also this is not just a Firefox issue, since it also seems to apply to other apps, even such mundane things as bash in a Gnome Terminal window. I suspect it's something to do with either process scheduling or I/O, but I'm not really a performance jockey, so I could be way off.
It might have been. It wasn't Windows 95; that's for sure. That was *supposed* to come out in 1994, then in early 1995, then... They just barely got it done fast enough to *claim* a 1995 release date, although it was so late in the year that by the time they shipped enough copies of it out that you could actually find it on a store shelf in most areas, it was no longer 1995.
However, as far as I am aware, there was *zero* hype for that product until 1994; prior to that, the hype was on NT. So they only hyped the product for a couple of years before it was actually available. They've been hyping Longhorn, and the features that would (and now no longer will) be in it, for rather more than two years already, and analysts are still flagrantly speculating about whether the product will actually be released before the end of *next* year.
WinFS is the real vaporware, though. It's starting to approach Duke Nukem Forever's legendary status in that regard. Wasn't it going to be in "the next release" when Windows 2000 came out?
> When the release was sheduled at the second > half of 2006, nobody actually ever expected > it to come out before 2010.
I was estimating late 2007 or early 2008...
> 2006 is earlier than expected!
Still, this is true. As far as I'm concerned, Christmas season 2006 is still earlier than expected, because it's the soonest Microsoft now thinks they can release, and it's still a year away yet; anybody who thinks that in an entire year the release date won't slip any more clearly does not have my penchant for pessimism.
> Other than that, there have been absolutely > no stand out or interesting additions that > I can see.
Some of the leaked screenshots depicted what I *think*, if I interpreted them correctly, were panel applets. If so, that's a quite useful feature. (It's a feature Gnome and KDE have had for a veritable aeon, but nevertheless, it's quite useful. And it's something OS X does not, AFAIK, have.) (I am assuming that Microsoft has enough sense to do this in a sufficiently general way that third-party applets would be able to display in the panel; the applets that I saw, such as an analog clock, are not in themselves terribly useful, but it is the ability to embed applets in the panel that is useful.)
Granted, the Monad shell and the WinFS were the really big Longhorn features, and those aren't making the cut for Vista. I guess they'll be in Blackcomb, which should come out by late 2012 or so...
If you're like I used to be, you waste half to two-thirds of a second hundreds of times every day on minimizing and restoring windows. Less than a second each time sounds like nothing, but it can easily add up to half an hour or so every single shift.
Got icons on the desktop? Replace them with panel launchers. Use drawers if you have to; it's still faster to get to a launcher in a drawer than an icon on the desktop, and you aren't left with all your other windows minimized afterward. Keep the launchers you use with any frequency directly on the panel. I like to run one panel along the left side of the screen dedicated mostly to launchers (I do also keep a memory/swap/cpu meter there), and then keep the task list in another panel on the bottom edge of the screen, where I also keep a clock applet; many people would keep a new-mail-notification applet there.
Many window managers will also let you configure global keyboard shortcuts for launching certain applications and other common activities, such as maximizing or lowering the current window. I happen to use sawfish, but I'm sure many other window managers also provide this functionality.
Second thing, take your phone off the hook. Okay, maybe not. It *would* save a lot of time, though.
> What I do have a problem with is how it doesn't bother to remove raw images that are no longer > needed. Essentially, it is a really bad memory leak that they haven't fixed for ages.
This is *partly* due to the way memory allocation and freeing work at the system call level. In a nutshell, memory that you free does not actually become free for other programs to use until your process exits. (As bad as this sounds, it's preferable to the situation wherein the system doesn't know what process owns the memory, so if an app has a leak the only way to reclaim it is to restart the whole system.) I am not sure which platforms have this (wait until the app exits) behavior, but I think it might be fairly common, although on some systems the not-really-free memory may be given to the *same* process again, next time it requests more memory, and in that case it shouldn't grow infinitely, as it would be only *other* processes that can't use it. Still, it's annoying that once you've loaded up too much at once and grown the process' memory usage to a large figure, the only way to reclaim that for other apps is to exit the process -- closing the document that caused all the usage won't do it. I *think* this is the behavior I see on Ubuntu, e.g., once I've had a really complex SVG image open in Inkscape (or a big document in OpenOffice with a lot of frames and especially images in it), and I then open a smaller, simpler image (or document) and close the big one, the memory doesn't get freed until I close Inkscape. However, if I've had a big document open, which I've closed, and then I open another big document, the memory usage doesn't go up any worse (unless the second document is bigger or more complex than the first one, of course), so it appears the same process is handed that same memory again that it freed earlier, even though another process can't have it.
I *suspect* the same is true on Win NT/2K/XP, although it's harder to tell there, due to the lack of facilities such as panel applets and good process management tools. There's the mem command, but I haven't spent a lot of time on tracking memory usage that way. On the other hand, part of the reason I haven't spent time figuring it out is because memory that's not in usage any more on Windows systems usually ends up just growing the swapfile automatically, which is really not such a big deal if you've got plenty of hard drive space. I *mostly* like the way Linux handles virtual memory better than Windows (in particular, it (since circa 2.4, or maybe it was in 2.2) seems to do a quite good job of knowing what to swap out or not to keep thrashing to a minimum), but I do like the auto-allocation that Windows does.
Really obsessive Tolkien fans generally consider LOTR to be higher in the canon than the Silmarillion. Among other things, there are different drafts and variants of the Silmarillion, and generally for any given point the version that fits best with especially LOTR and secondarily There and Back Again (if one particular reading does fit better) is considered the preferred reading. Failing that, the "published Silmarillion" (the reading selected by Christopher Tolkien) is usually preferred over the others, unless there is a question of internal consistency. In other words, there's no draft of the Silmarillion that can really be considered fully authoritative; whereas, the LOTR as published is considered to be practically verbatim from the Red Book of Westmarch and therefore as authentically reliable as any text can be, regarding the events of its time.
There are also various other documents -- lost tales, personal letters, and whatnot -- which are considered even less authoritative in the canon than the Silmarillion.
Yeah, it was obvious. To make this joke more plausible, next time start with ''=~( and include a lot of parentheses, so that it looks like your keybanging might potentially actually *do* something.
akebono was a server at Stanford where graduate students in the computer science department could get projects hosted. And yes, the Yahoo! index originated there. It was rather smaller at the time; for instance, "Colleges and Universities" was originally a toplevel category, and did not have any subcategories at first, although it wasn't long before it was subdivided.
This was fairly early in the history of the web, before Netscape, when Gopher was still in more widespread use than the web, although ISTR that the Yahoo! index remained hosted on akebono for quite some little while until its creators finished their graduate work and took it off campus.
> if I send a baseball in one direction spinning topwise, while at the same isntant sending a > baseball in another direction spinning bottomwise, their spins will be opposite and continue > to do so, without any interaction between the baseballs.
Yes, but baseballs are not subatomic particles. Among other things, looking at which direction they're spinning hardly changes their spin at all. The traditional line of thinking is that the laws of physics are different at the macroscopic level versus the subatomic level, but I suspect the real issue is that they *apply* differently because of the certain scale-related difference. Baseballs have a much larger mass, for instance, so gravity is a real issue for them; whereas, gravity hardly has any impact on an individual electron at all. On the other hand, a baseball has an almost exactly balanced charge, so electromagnetic force has very little impact on it; whereas, for an electron, that's a fairly big deal. These forces, though, are the two we understand best; nuclear force and weak force presumably also apply rather differently to an electron versus a baseball, but I'm not sure we understand all the details.
The whole deal with information "flowing" is anchored in the Heisenberg principle. The models I have read all suppose that if we don't know the direction of a particle's spin, it's spin direction is not merely unknown to us but actually indeterminate, i.e., could go either way. I don't fully understand all the arguments for this, but it is related in some way to the wave/particle duality of light, wherein before you measure the positions of the individual photons two beams of light interact as if they were waves, creating interference patterns, but upon being measured the photons do turn out to have very specific positions.
Of course. Doesn't anyone remember what the web was like before search engines became popular, when the main way to find pages was by following links there from other pages? If you could get someone to link to your page who in turn was listed prominently on the Humor, Jokes, and Fun page on akebono, then you were all set, but otherwise, it would take *months* for anyone to find out about your page, if they ever did.
Don't even bother replying to this unless you know the significance of akebono.
Then Merriam-Webster is wrong in this instance. The word 'mathematics' is definitely singular, as are most nouns ending in 'ics'. Other singular words ending in the letter 's' include 'avionics', 'sarcophagus', 'physics', and 'logos' (in the sense meaning "message" or "word"; the last form also occurs, more often, as the plural of 'logo').
There are several ways you can tell these words are singular. Most obviously, you can tell grammatically, because they are always used with singular verbs. Secondarily, the corresponding forms without the 's' are unattested (as nouns; "mathematic" may occur as an adjective, but that's different). Additionally, if you have a background in linguistics (which is also singular), you can tell that these words are singular based on the component roots and affixes from which they are constructed. For instance, the "cs" on the end of most nouns that end in "ics" is a suffix indicating that the word refers to a discipline, practice, or field of study; therefore, the s is not a plural suffix. (Similarly, the s in "sarcophagus" and "logos" is part of the singular suffices "us" and "os", from Latin and Greek, respectively; the plural forms would be "sarcophagi" and "logoi". Although those plural forms AFAIK are not in widespread use in English, there are other words that do bring their plural forms over into English, e.g., "alumni" and "hoi polloi".)
> Get a big boombox, and CRANK IT UP! Tada, whole house audio. Your neighbors will love you > because you're installing systems for them, too, and for free!
If that's the effect you're after, make sure you play nothing but polka music.
Either that or just skip the boombox and get a train whistle and an air compressor.
In general, you will want to do this in such a way that most of the changes (at least initially) are for the purpose of making sure things are consistent. Some examples...
First, take a vote on how to handle multi-word variable names (with_underscores, camelCase, or whatever), and officially adopt whichever one gets the most votes as the official way that you name variables at your organization. It doesn't matter which one you pick, as long as you standardize on one specific convention for this. Also be sure to specify whether Hungarian Notation is to be used or not. (All else being equal I prefer not, but if most of your code uses it, it'll be easier to standardise on that.)
Second, you want to standardize on where the comments go that describe the inputs and outputs of each subroutine. Before the function header? Right after it? You can stick with however most of your code currently handles this (assuming most of your code _has_ such comments), but designate one way and make it official. If you currently have a mishmash, take a vote or something, but standardize it. Word the document that describes this standard in a way that does not allow for said comments to be omitted.
Third, if you don't already have a version control system of some kind, set one up, and make sure that it prompts for a changelog comment on every checkin, automatically filling in a list of the touched files. Now, make sure that the supplied comment is automatically appended to the changelog. (Don't take this for granted; not all version control systems that prompt for a changelog comment will necessarily add it to the changelog. Make sure yours does.) Make it policy that the comment has to make note of the reason for the changes. (The reason can be brief, like "added sanity check for improved robustness", but require a reason, and it should be more specific than "bug fix". If you have bug-tracking software, a reason like "bug 17043" is good enough.)
These are the sorts of things you want to start with. Obviously you also want some general wording about how clarity is to be preferred over other considerations, optimization only to be done when profiling has targetted a specific block of code and then always commented, and so on and so forth.
> Most of the modern text games I've seen follow this > ethos; they make it hard, if not always impossible, > to lose - or at least, to lose without knowing it...
The latter (losing without knowing it, sometimes called "unwinnable state") is what really has been almost entirely stamped out. (Not completely, though; one of last year's popular comp games, All Things Devours, is jam-packed full of unwinnable state, as well as time-based puzzles, another thing fans of the genre have fairly consistently argued against.) Garden-variety losing (provided it's not too arbitrary or random) is much less of a big deal, because almost all modern implementations support undo.
> I took a bathroom break and came back to find that my SANDWICH was eaten by a grue.
Ah, you made the classic mistake of assuming that because the room was lit when you were there (with your lamp, of course), it would remain lit when you left. That's not always true. You have to be careful. Next time, be sure to leave your sandwich in a room with natural light, if you're going to leave it and take your light source with you. Either that, or put the sandwich inside a container (such as a lunch bag) and close the container, so that there's not an edible item laying around visible in the room.
> The study, commissioned by the software giant from Security > Innovation, a provider of application security services, > claimed that Linux administrators took 68 per cent longer > to implement new business requirements than their Windows > counterparts.
Yeah, 68% longer to implement new requirements, eh? Assuming we believe that, it raises a question: are they also 68% less likely to then have to *reimplement* the same requirements six more times before the work *correctly*? And, once they do get things working, is it also 68% more likely that the implementation will *continue* working, without interruption, for as long as it's needed?
> This grue you speak of sounds terrifying - > can you provide a screenshot?
Yeah, here's one...
Your lamp is getting dimmer.
> examine the lamp
Exactly the sort of thing you imagine Aladin might have carried, the lamp appears to be made of polished brass, with ornate decorations etched around the rim.
The lamp is glowing dimly and appears to be low on oil.
> inventory
You are carrying a lamp.
The lamp is getting very dim now.
> east
DARKNESS
It's pitch dark, and you can't see a thing.
Your lamp has now gone out completely.
> west
You have been eaten by a grue.
*** YOU HAVE DIED ***
Would you like to RESTART, RESTORE a saved game, or QUIT?
> Security through obscurity is not real security, but and you should never rely on it - never > alone, of course, and also not in conjunction with other security mechanisms -, but that doesn't > mean it can't be useful.
Obscurity, by itself, does not constitute security. However, obscurity, in one form or another, used correctly, is a *vital* component of every (worthwhile) security system of which I am aware.
In the case of hashing, it's not the hash algorithm that needs to be obscure. For some uses of hashing, it's the source text that needs to be kept obscure, which is the whole point of hashing it in the first place. (This is the case e.g. with password hashing.) Other uses of hashing have different characteristics.
Yeah, or maybe it died out somewhat more recently than that, but there are no fossils from the last while, because by then the critter was starting to get rare. One can readily imagine that such a thing might be the source of some legends.
OTOH, maybe it was never a separate species in the first place, just an unusually large specimen. It's hard to know now.
> Yeah sure, but if we can't adapt to it.. like, say, if the > temperature triples
The temperature isn't going to triple. The relative humidity might. What would happen to the temperature is that it would be consistent worldwide, probably in the vicinity of 80F in the case of a full greenhouse. You could walk around in a swimsuit at the south pole, and you wouldn't need sunscreen. Yes, there would also be downsides. Significant ones. What I'm saying is that the global warming people act like the greenhouse effect is some new thing that has never happened before and would mean the end of all life on earth, but in fact there has in the past been a very significant greenhouse effect on earth, and yet life is still here; a return to that situation may not be the ideal scenario for our lifestyle, but it would *not* be the end of the world.
Now, keeping that in mind, go back and have another look at how the models of and understanding of how the greenhouse effect and global warming have changed over the last thirty years. When you stop thinking of global warming as the end of the world, the outlook doesn't seem so dire, and then you can think more rationally about the question of how much we really know about it anyhow.
Slashdot Mirror
> I'm really wondering why it is so much slower in linux than in windows.
I find that on the same hardware, performance is vanishingly close to the same on Windows as on Linux (unless the Linux system is booting from a LiveCD (e.g. Knoppix), in which case that's slower, due to the inherent overhead of a LiveCD system). This is with a Matrox graphics card, which works well with every OS ever devised; YMMV if you are using a card that has substantially better drivers for some OSes than for others. Also, I have adequate RAM (i.e., enough that my swap space sits unused), so if you're short on that commodity, that could mess things up for you.
I do find, however, that responsiveness is a little worse on FreeBSD (this is on 6.0). It's not bad, certainly not bad enough to tempt me to move away from BSD just for that, but enough to be noticeable. Also this is not just a Firefox issue, since it also seems to apply to other apps, even such mundane things as bash in a Gnome Terminal window. I suspect it's something to do with either process scheduling or I/O, but I'm not really a performance jockey, so I could be way off.
> the screaming sound that I make when I realize my machine has been compromized? "iiiieeeeEEEEEEEEE!"
No, real Geeks scream, "Kaaaaaaahn!"
> It might have been Windows 98.
It might have been. It wasn't Windows 95; that's for sure. That was *supposed* to come out in 1994, then in early 1995, then... They just barely got it done fast enough to *claim* a 1995 release date, although it was so late in the year that by the time they shipped enough copies of it out that you could actually find it on a store shelf in most areas, it was no longer 1995.
However, as far as I am aware, there was *zero* hype for that product until 1994; prior to that, the hype was on NT. So they only hyped the product for a couple of years before it was actually available. They've been hyping Longhorn, and the features that would (and now no longer will) be in it, for rather more than two years already, and analysts are still flagrantly speculating about whether the product will actually be released before the end of *next* year.
WinFS is the real vaporware, though. It's starting to approach Duke Nukem Forever's legendary status in that regard. Wasn't it going to be in "the next release" when Windows 2000 came out?
> When the release was sheduled at the second
> half of 2006, nobody actually ever expected
> it to come out before 2010.
I was estimating late 2007 or early 2008...
> 2006 is earlier than expected!
Still, this is true. As far as I'm concerned, Christmas season 2006 is still earlier than expected, because it's the soonest Microsoft now thinks they can release, and it's still a year away yet; anybody who thinks that in an entire year the release date won't slip any more clearly does not have my penchant for pessimism.
> Other than that, there have been absolutely
> no stand out or interesting additions that
> I can see.
Some of the leaked screenshots depicted what I *think*, if I interpreted them correctly, were panel applets. If so, that's a quite useful feature. (It's a feature Gnome and KDE have had for a veritable aeon, but nevertheless, it's quite useful. And it's something OS X does not, AFAIK, have.) (I am assuming that Microsoft has enough sense to do this in a sufficiently general way that third-party applets would be able to display in the panel; the applets that I saw, such as an analog clock, are not in themselves terribly useful, but it is the ability to embed applets in the panel that is useful.)
Granted, the Monad shell and the WinFS were the really big Longhorn features, and those aren't making the cut for Vista. I guess they'll be in Blackcomb, which should come out by late 2012 or so...
If you're like I used to be, you waste half to two-thirds of a second hundreds of times every day on minimizing and restoring windows. Less than a second each time sounds like nothing, but it can easily add up to half an hour or so every single shift.
Got icons on the desktop? Replace them with panel launchers. Use drawers if you have to; it's still faster to get to a launcher in a drawer than an icon on the desktop, and you aren't left with all your other windows minimized afterward. Keep the launchers you use with any frequency directly on the panel. I like to run one panel along the left side of the screen dedicated mostly to launchers (I do also keep a memory/swap/cpu meter there), and then keep the task list in another panel on the bottom edge of the screen, where I also keep a clock applet; many people would keep a new-mail-notification applet there.
Many window managers will also let you configure global keyboard shortcuts for launching certain applications and other common activities, such as maximizing or lowering the current window. I happen to use sawfish, but I'm sure many other window managers also provide this functionality.
Second thing, take your phone off the hook. Okay, maybe not. It *would* save a lot of time, though.
> What I do have a problem with is how it doesn't bother to remove raw images that are no longer
> needed. Essentially, it is a really bad memory leak that they haven't fixed for ages.
This is *partly* due to the way memory allocation and freeing work at the system call level. In a nutshell, memory that you free does not actually become free for other programs to use until your process exits. (As bad as this sounds, it's preferable to the situation wherein the system doesn't know what process owns the memory, so if an app has a leak the only way to reclaim it is to restart the whole system.) I am not sure which platforms have this (wait until the app exits) behavior, but I think it might be fairly common, although on some systems the not-really-free memory may be given to the *same* process again, next time it requests more memory, and in that case it shouldn't grow infinitely, as it would be only *other* processes that can't use it. Still, it's annoying that once you've loaded up too much at once and grown the process' memory usage to a large figure, the only way to reclaim that for other apps is to exit the process -- closing the document that caused all the usage won't do it. I *think* this is the behavior I see on Ubuntu, e.g., once I've had a really complex SVG image open in Inkscape (or a big document in OpenOffice with a lot of frames and especially images in it), and I then open a smaller, simpler image (or document) and close the big one, the memory doesn't get freed until I close Inkscape. However, if I've had a big document open, which I've closed, and then I open another big document, the memory usage doesn't go up any worse (unless the second document is bigger or more complex than the first one, of course), so it appears the same process is handed that same memory again that it freed earlier, even though another process can't have it.
I *suspect* the same is true on Win NT/2K/XP, although it's harder to tell there, due to the lack of facilities such as panel applets and good process management tools. There's the mem command, but I haven't spent a lot of time on tracking memory usage that way. On the other hand, part of the reason I haven't spent time figuring it out is because memory that's not in usage any more on Windows systems usually ends up just growing the swapfile automatically, which is really not such a big deal if you've got plenty of hard drive space. I *mostly* like the way Linux handles virtual memory better than Windows (in particular, it (since circa 2.4, or maybe it was in 2.2) seems to do a quite good job of knowing what to swap out or not to keep thrashing to a minimum), but I do like the auto-allocation that Windows does.
> I consider the Silmarillion that.
Really obsessive Tolkien fans generally consider LOTR to be higher in the canon than the Silmarillion. Among other things, there are different drafts and variants of the Silmarillion, and generally for any given point the version that fits best with especially LOTR and secondarily There and Back Again (if one particular reading does fit better) is considered the preferred reading. Failing that, the "published Silmarillion" (the reading selected by Christopher Tolkien) is usually preferred over the others, unless there is a question of internal consistency. In other words, there's no draft of the Silmarillion that can really be considered fully authoritative; whereas, the LOTR as published is considered to be practically verbatim from the Red Book of Westmarch and therefore as authentically reliable as any text can be, regarding the events of its time.
There are also various other documents -- lost tales, personal letters, and whatnot -- which are considered even less authoritative in the canon than the Silmarillion.
> Ok, I admit it. I just banged on the keyboard
Yeah, it was obvious. To make this joke more plausible, next time start with ''=~( and include a lot of parentheses, so that it looks like your keybanging might potentially actually *do* something.
akebono was a server at Stanford where graduate students in the computer science department could get projects hosted. And yes, the Yahoo! index originated there. It was rather smaller at the time; for instance, "Colleges and Universities" was originally a toplevel category, and did not have any subcategories at first, although it wasn't long before it was subdivided.
This was fairly early in the history of the web, before Netscape, when Gopher was still in more widespread use than the web, although ISTR that the Yahoo! index remained hosted on akebono for quite some little while until its creators finished their graduate work and took it off campus.
> if I send a baseball in one direction spinning topwise, while at the same isntant sending a
> baseball in another direction spinning bottomwise, their spins will be opposite and continue
> to do so, without any interaction between the baseballs.
Yes, but baseballs are not subatomic particles. Among other things, looking at which direction they're spinning hardly changes their spin at all. The traditional line of thinking is that the laws of physics are different at the macroscopic level versus the subatomic level, but I suspect the real issue is that they *apply* differently because of the certain scale-related difference. Baseballs have a much larger mass, for instance, so gravity is a real issue for them; whereas, gravity hardly has any impact on an individual electron at all. On the other hand, a baseball has an almost exactly balanced charge, so electromagnetic force has very little impact on it; whereas, for an electron, that's a fairly big deal. These forces, though, are the two we understand best; nuclear force and weak force presumably also apply rather differently to an electron versus a baseball, but I'm not sure we understand all the details.
The whole deal with information "flowing" is anchored in the Heisenberg principle. The models I have read all suppose that if we don't know the direction of a particle's spin, it's spin direction is not merely unknown to us but actually indeterminate, i.e., could go either way. I don't fully understand all the arguments for this, but it is related in some way to the wave/particle duality of light, wherein before you measure the positions of the individual photons two beams of light interact as if they were waves, creating interference patterns, but upon being measured the photons do turn out to have very specific positions.
I say we take off and nuke the entire site from orbit. It's the
only way to be sure.
Of course. Doesn't anyone remember what the web was like before search engines became popular, when the main way to find pages was by following links there from other pages? If you could get someone to link to your page who in turn was listed prominently on the Humor, Jokes, and Fun page on akebono, then you were all set, but otherwise, it would take *months* for anyone to find out about your page, if they ever did.
Don't even bother replying to this unless you know the significance of akebono.
Then Merriam-Webster is wrong in this instance. The word 'mathematics' is definitely singular, as are most nouns ending in 'ics'. Other singular words ending in the letter 's' include 'avionics', 'sarcophagus', 'physics', and 'logos' (in the sense meaning "message" or "word"; the last form also occurs, more often, as the plural of 'logo').
There are several ways you can tell these words are singular. Most obviously, you can tell grammatically, because they are always used with singular verbs. Secondarily, the corresponding forms without the 's' are unattested (as nouns; "mathematic" may occur as an adjective, but that's different). Additionally, if you have a background in linguistics (which is also singular), you can tell that these words are singular based on the component roots and affixes from which they are constructed. For instance, the "cs" on the end of most nouns that end in "ics" is a suffix indicating that the word refers to a discipline, practice, or field of study; therefore, the s is not a plural suffix. (Similarly, the s in "sarcophagus" and "logos" is part of the singular suffices "us" and "os", from Latin and Greek, respectively; the plural forms would be "sarcophagi" and "logoi". Although those plural forms AFAIK are not in widespread use in English, there are other words that do bring their plural forms over into English, e.g., "alumni" and "hoi polloi".)
> as we say here in the UK - mathematics is PLURAL
Mathematics is no more plural than physics, forensics, or economics.
Okay, everyone be sure to install the latest security updates to your Google software, to protect yourself from this exploit!
Oh, wait...
> Get a big boombox, and CRANK IT UP! Tada, whole house audio. Your neighbors will love you
> because you're installing systems for them, too, and for free!
If that's the effect you're after, make sure you play nothing but polka music.
Either that or just skip the boombox and get a train whistle and an air compressor.
In general, you will want to do this in such a way that most of the changes (at least initially) are for the purpose of making sure things are consistent. Some examples...
First, take a vote on how to handle multi-word variable names (with_underscores, camelCase, or whatever), and officially adopt whichever one gets the most votes as the official way that you name variables at your organization. It doesn't matter which one you pick, as long as you standardize on one specific convention for this. Also be sure to specify whether Hungarian Notation is to be used or not. (All else being equal I prefer not, but if most of your code uses it, it'll be easier to standardise on that.)
Second, you want to standardize on where the comments go that describe the inputs and outputs of each subroutine. Before the function header? Right after it? You can stick with however most of your code currently handles this (assuming most of your code _has_ such comments), but designate one way and make it official. If you currently have a mishmash, take a vote or something, but standardize it. Word the document that describes this standard in a way that does not allow for said comments to be omitted.
Third, if you don't already have a version control system of some kind, set one up, and make sure that it prompts for a changelog comment on every checkin, automatically filling in a list of the touched files. Now, make sure that the supplied comment is automatically appended to the changelog. (Don't take this for granted; not all version control systems that prompt for a changelog comment will necessarily add it to the changelog. Make sure yours does.) Make it policy that the comment has to make note of the reason for the changes. (The reason can be brief, like "added sanity check for improved robustness", but require a reason, and it should be more specific than "bug fix". If you have bug-tracking software, a reason like "bug 17043" is good enough.)
These are the sorts of things you want to start with. Obviously you also want some general wording about how clarity is to be preferred over other considerations, optimization only to be done when profiling has targetted a specific block of code and then always commented, and so on and so forth.
> Most of the modern text games I've seen follow this
> ethos; they make it hard, if not always impossible,
> to lose - or at least, to lose without knowing it...
The latter (losing without knowing it, sometimes called "unwinnable state") is what really has been almost entirely stamped out. (Not completely, though; one of last year's popular comp games, All Things Devours, is jam-packed full of unwinnable state, as well as time-based puzzles, another thing fans of the genre have fairly consistently argued against.) Garden-variety losing (provided it's not too arbitrary or random) is much less of a big deal, because almost all modern implementations support undo.
> I took a bathroom break and came back to find that my SANDWICH was eaten by a grue.
Ah, you made the classic mistake of assuming that because the room was lit when you were there (with your lamp, of course), it would remain lit when you left. That's not always true. You have to be careful. Next time, be sure to leave your sandwich in a room with natural light, if you're going to leave it and take your light source with you. Either that, or put the sandwich inside a container (such as a lunch bag) and close the container, so that there's not an edible item laying around visible in the room.
> The study, commissioned by the software giant from Security
> Innovation, a provider of application security services,
> claimed that Linux administrators took 68 per cent longer
> to implement new business requirements than their Windows
> counterparts.
Yeah, 68% longer to implement new requirements, eh? Assuming we believe that, it raises a question: are they also 68% less likely to then have to *reimplement* the same requirements six more times before the work *correctly*? And, once they do get things working, is it also 68% more likely that the implementation will *continue* working, without interruption, for as long as it's needed?
> This grue you speak of sounds terrifying -
> can you provide a screenshot?
Yeah, here's one...
Your lamp is getting dimmer.
> examine the lamp
Exactly the sort of thing you imagine Aladin might have
carried, the lamp appears to be made of polished brass,
with ornate decorations etched around the rim.
The lamp is glowing dimly and appears to be low on oil.
> inventory
You are carrying a lamp.
The lamp is getting very dim now.
> east
DARKNESS
It's pitch dark, and you can't see a thing.
Your lamp has now gone out completely.
> west
You have been eaten by a grue.
*** YOU HAVE DIED ***
Would you like to RESTART, RESTORE a saved game, or QUIT?
> Security through obscurity is not real security, but and you should never rely on it - never
> alone, of course, and also not in conjunction with other security mechanisms -, but that doesn't
> mean it can't be useful.
Obscurity, by itself, does not constitute security. However, obscurity, in one form or another, used correctly, is a *vital* component of every (worthwhile) security system of which I am aware.
In the case of hashing, it's not the hash algorithm that needs to be obscure. For some uses of hashing, it's the source text that needs to be kept obscure, which is the whole point of hashing it in the first place. (This is the case e.g. with password hashing.) Other uses of hashing have different characteristics.
> before the species died out 100,000 years ago
Yeah, or maybe it died out somewhat more recently than that, but there are no fossils from the last while, because by then the critter was starting to get rare. One can readily imagine that such a thing might be the source of some legends.
OTOH, maybe it was never a separate species in the first place, just an unusually large specimen. It's hard to know now.
> Yeah sure, but if we can't adapt to it.. like, say, if the
> temperature triples
The temperature isn't going to triple. The relative humidity might. What would happen to the temperature is that it would be consistent worldwide, probably in the vicinity of 80F in the case of a full greenhouse. You could walk around in a swimsuit at the south pole, and you wouldn't need sunscreen. Yes, there would also be downsides. Significant ones. What I'm saying is that the global warming people act like the greenhouse effect is some new thing that has never happened before and would mean the end of all life on earth, but in fact there has in the past been a very significant greenhouse effect on earth, and yet life is still here; a return to that situation may not be the ideal scenario for our lifestyle, but it would *not* be the end of the world.
Now, keeping that in mind, go back and have another look at how the models of and understanding of how the greenhouse effect and global warming have changed over the last thirty years. When you stop thinking of global warming as the end of the world, the outlook doesn't seem so dire, and then you can think more rationally about the question of how much we really know about it anyhow.