One last thing. Resist the urge to interrupt the music frequently with voiceovers explaining how important the call (allegedly) is to you. One such voiceover early in the hold (possibly even before the music starts) is probably a good idea; beyond that, spread them out at least twice as far as you think they ought to go, and either put them between music tracks or leave the music playing in the background during the voiceover. Above all, do *not* stop the music every fifteen seconds, giving false hope that a live person is about to pick up, only to play a voice recording. That's more annoying than almost any music you could pick. Once you start the music, just let it play. (Exception: if you have the capability to notify the user when they move up in the queue due to completion of a previous call (a la, "Thanks for holding; you are now second in line to speak to a tech support representative. Calls are answered in the order they are received"), that would be better received, due to being an indicator of real progress. Still, avoid abruptly stopping the music for this announcement, since that introduces false hope that the call is being picked up by a live human. Instead, run the voice overtop without stopping the music if possible.)
IMO, you want to go with something instrumental, preferably something venerable.
You have a couple of options here. You could go with something slow and soothing, on the theory that it will keep people calm; in that case, something from the Romantic era is probably what you want, e.g. Chopin. This has the disadvantage that it will put people to sleep, however. The other choice is to go with something with a bit more pizazz (but not so much pizazz as to be annoying). The Baroque era is rich in music that is peppy enough to be interesting but nevertheless sedate enough to avoid making anyone crazy. If I were picking, I'd tell you to get Munchinger's performance of the _Art of Fugue_, which is really excellent; I've received positive comments about it from people who generally don't listen to old music in general or Baroque in particular but liked this album. Contrapunctus II is particularly fetching. Another reasonable option would be something classical. Very few people have a strong dislike for Mozart, for example; people may feel that he's overrated (e.g., I do), but they won't be hanging themselves with the phone cord after the tenth measure.
What you absolutely want to avoid is anything with lyrics. Lyrics get more attention, get noticed, and get a reaction. That's bad. Lyrics make fans, but they also make foes. Genres with lyrics sell a lot of albums, because a lot of people like them -- but a lot of people hate (any given genre of) them too. You pick any genre with lyrics -- rap, rock-and-roll, metal, country,... -- and there are people who passionately hate it. That's not what you want for hold music; you want something everyone can at least put up with; it's not necessary for anyone to be _excited_ about the music; you just want them to be able to stand it okay.
There's another strategy you could follow: Make it play the tail end of something obnoxious for the first ten seconds and then switch to something else. People will be so relieved they won't mind if the thing it switches to is not their first choice. But this only works if the obnoxious music is significantly obnoxious. Perhaps a polka rendition of MacArthur Park, or an amateur nobody singing a Neil Diamond song, or something like that. Of course, that breaks down once people have been on hold enough times to know the trick. What I would really recommend is going with the Bach. But don't get a recording played on organ; Bach fans love that, but a lot of people dislike organ music. Go with an orchestral recording, like the the abovementioned Munchinger one. That's harder to hate.
Finally, realize that no matter *what* you pick, you *cannot* please absolutely everyone. There will always be some loon who thinks you should play Country music, and he'll be mildly irritated that you don't; you have to reconcile yourself to the fact that it's a choice between irritating that guy mildly, by not playing his first choice, versus playing the Country and driving other people out of their skulls with loathing. (If it's not Country, it'll be metal or rap or some other love-it-or-hate-it genre; avoid these, and go for something hard-to-hate instead of something that some people really love.)
Re:Great for paranoid nuts, useless for real peopl
on
RF-Blocking Wallpaper
·
· Score: 1
If it blocks cellphones, I want it for the library where I work. All of my coworkers would agree.
You say you've been using Linux for years? Okay, so then you know about IP Masquerade, yes? Use it. Pull a spare Pentium-90 out of the closet, put an extra $8 NIC in it, set it up with your favorite distro, and connect *that* system directly to the net. Set it up with a second, local network on the second NIC (I usually use 192.168.0.*), and have it masq that network onto the internet. Hook your Windows system up to the local network and have it use the IP-Masq box as the gateway. This protects you from anything that relies on open ports to spread, which includes most worms. You still have some vulnerabilities, mostly in clients, _especially_ Outlook Express, which you should avoid entirely if at all possible and certainly at least until you've got all the updates installed.
People with no Linux experience can buy a hardware NAT gateway or firewall and accomplish basically the same thing.
When you finish getting Linux installed, you should still leave it behind the NAT gateway. You can turn off all the software firewalls you want then; although they do provide one additional piece of protection (namely, flagging certain kinds of rogue outgoing traffic that can be caused e.g. by spyware), that's more a form of detection than prevention, so switching it off for a few minutes to install some updates is not a big deal. The NAT gateway will cover the more important function of preventing rogue incoming traffic.
> 1) Not all pictures are suited to a scalable graphics format. (eg. > Continuous tone images for which JPEGs are appropriate.)
While it's true that not all images are suitable to SVG specifically, I don't think it necessarily follows that they are not suitable to any scalable format at all, in theory. (Of course, in practice there is a dearth of scalable image formats widely supported by browsers, but that may not always remain the case.)
As for JPEGs, if everyone in the whole world stopped using them yesterday it wouldn't be soon enough for me. I guess I notice different things from most people, but JPEG compression to me is uglier than almost any other type of ugliness an image can have. (Color-depth reduction a la GIF is nearly as bad.) I'd rather look at an out-of-focus badly-cropped poorly-exposed snapshot taken with no thought given to composition than look at a JPEG. Any time I have to do anything with an image that's been JPEG-compressed I end up having to scale it to a quarter of its size just to make it look passably decent, and in particularly bad cases sometimes I have to also run a Gaussian blur over it to kill the remaining artifacts.
Okay, so the alpha channel in PNG has lousy support in legacy browsers, but you can still use PNG without relying on the alpha channel. That extra 20% compression you get from JPEG isn't worth making the image look like that.
> Current CSS does not allow for portable image scaling. The use of > tables vs. CSS has little to do with the issue of resolution scaling.
It's relatively easy to make a scalable page without scalable images, provided no single image is larger than about 300 pixels -- which for bandwidth reasons is larger than most sites ought to have any single image be anyway, except for a few special cases where one particular image is the whole point of the page (e.g., maps).
There are a few basic rules that lead to scalable pages... * No single image is larger than about 300 pixels in either dimension. * All non-image sizes (e.g., font sizes) are specified in em or %.
You can make an exception for very thin borders (1 pixel) if you don't
mind their becomming arbitrarily thin hairlines at insane resolutions. * Don't use an image when the same visual effect can be achieved with plain
old HTML and CSS. For example, you don't use an image for a region of
solid color; you style it that way with CSS. Similarly, instead of using
an image of some blue letters, you style the letters blue, with the font
you like (and a couple of similar backup options), and so on. Yes, there
is a risk the user won't have the font, but unless the font is obscure
it's no greater than the risk that the user will have a different res and
it degrades more gracefully; if you pick good substitute fonts, the user
will never even know anything is wrong. You can make an exception to this
for esoteric fonts, e.g. if you really want a heading to be in an Old
English font, since almost nobody has one installed. Also logos are an
exception here; a logo should almost always be an image (though SVG is
a good choice for logos, or would be if browser support were better). * Test at 640x480 and 1600x1200 in two browsers that use different rendering
engines (e.g., if one uses Gecko the other should not).
I'm probably forgetting one or two other things, but it's all pretty basic and obvious stuff, and contrary to popular myth, use or non-use of tables is almost entirely irrelevant, as you said. It's what you put in the tables that determines how well they scale.
> Computer displays are in pixels.
Yeah, but they're all in different numbers of pixels. If you check the window size of twenty random browsers, you'll get 18 or 19 different sets of dimensions. Two or three will be the same because they'll be maximized at 640x480 or 800x600.
> I'm a bit surprised though that you could move from VB to Delphi without > having some background in pascal... basic and pascal weren't all that > syntactically similar.
From what I remember (and it *has* been a while; these days I think in Perl or lisp), VB isn't terribly similar[1] syntactically to BASIC, either, and seems to borrow quite a bit from Pascal. Not everything, of course, and there are significant and obvious signs of a BASIC heritage (e.g., optional sigil-like one-punctuation-character type suffices, some of which even have the same meaning as in BASIC), but you also find in VB some rather unBASICish things like do loops and such, which smack heavily of Pascal -- and of course both VB and Delphi put a lot of stock in supporting the event-oriented paradigm, so they're also similar from that standpoint.
[1] By "not terribly similar" I of course don't mean "completely dissimilar".
BASIC and Pascal are similar enough to be grouped together and contrasted
with lisp, for example. But VB is somewhere between more traditional
BASICs and Pascal, and while it may be closer to the BASIC side, the
differences are significant.
> Of course, Gates and Allen did not invent BASIC either, so to even claim > that they " develop[ed] the first commercial programming language for a > personal microcomputer." is a stretch
I believe the correct form of the statement would be, "developed the first implementation of a high-level programming language for that platform". My first guess would be that the person who shorted that to "developed the first programming language" probably wasn't a programmer, in which case he wouldn't understand the difference between a language and an implementation or understand the difference between "developed the first foo for the bar platform" and "used the bar platform to develop the first foo". (To know that the difference is significant, you have to parse the first one based on the knowledge that an implementation may be platform-specific, something a lot of people wouldn't know.) In other words, it was probably written or edited by someone who didn't know enough to be accurate about this topic. I very much doubt there was any deliberate deception in the statement; it's more likely inaccurate due to garden-variety incompetence.
> that's the first time on Slashdot I've ever seen someone use the words > "Fortran" and "happily" in the same sentence!
Fortran is actually very good at what it does (i.e., crunch numbers). It's completely inappropriate for most of the things most people do with computers most of the time (e.g., anything that involves any text processing), but for what it was designed for, it's excellent.
The trouble comes when you mistake it for a general-purpose language and try to use it to program something you shouldn't. For example, you should not use it to implement a mail server (unless your goal is to impress the everliving daylights out of the same sort of people who think it's really cool to write a quine that's valid in four different languages including C and Postscript). No, you should use probably Perl or Python or something along those lines for that sort of thing, or in a pinch you could get by with C better than Fortran, although C isn't particularly good for text processing either.
But that doesn't make Fortran bad, any more than Postscript is bad for being designed for printing. It just makes it a special-purpose language rather than a general-purpose one. Code written in special-purpose languages often has a symbiotic relationship with code written in glue languages (e.g., shell scripts or these days more likely Perl). There's no reason your high-end physics simulation couldn't use Fortran for the heavy numerical stuff and Perl to handle other things like I/O -- or even use Perl to glue the Fortran number-crunching code together to a UI written in something else, maybe XUL.
Fortran would only be painful if you tried to use it for the parts of the project it's not good for. Stick to doing numbers with it and you'll be much happier.
Actually, Internet Explorer is no longer a separate project, but has been merged with their larger browser-application-suite project, which (just like the browser we're discussing) seems to change codenames every version. Right now there are at least two different codenamed-versions of it under development, Longhorn and Blackcomb. (Weird project codenames? Check. And you thought that Phoenix -> Firebird and Firebird -> Firefox were gratuitously odd project codename transitions. At least Longhorn and Blackcomb are relatively unique, in the sense of not having been used as product names millions of times already, unlike Phoenix and Firebird. Firefox also seems okay in that regard, though.)
Of course, Firebird and Longhorn/Blackcomb aren't really aimed at the same browser market niche. Firebird is aimed at people who think the Mozilla Seamonkey suite is too bloated with non-browser features like email and usenet; Longhorn/Blackcomb are aimed at people who think the web browser should be integrated with the file manager and maybe also integrated with a word processing suite and include a music player and possibly a Solitaire game and all sorts of other technically-non-browser features plus convenient automatic-remote-execution features. It's really the opposite approach from Firefox and would appeal to completely different market segments.
> Don't suppose you have any info or resources on how to deploy Mozilla > Firefox in a standard Windows Active Directory network do you?
The same way you would deploy any other application in AD. (No, I don't know how to do that, but I don't use AD. If we used AD where I work, I'd make it my business to know how to use it. I think O'Reilly has a book on it.)
> It'd be essential that Firefox could be restricted in a similar way to IE.
Firefox is naturally secure, if that's what you're worried about; you don't need to lock it down like you would IE because it doesn't have IE's holes. If you're more worried about users visiting sites they're not supposed to, then you should be using a proxy and blocking outgoing ports 80 and 443 at the firewall; otherwise, savy users can get around your AD restrictions. (Actually, they *still* can get around even the port blocking, but it's a lot more of a pain and will leave a trail if IT is paying attention.)
> Why doesn't Mozilla ship with the Modern theme on by default
Accessibility. Modern ignores the system colors, which violates accessibility guidelines. Classic may be ugly, but it adheres to the guidelines better in this respect. (It would of course be possible to create a non-ugly theme that looks modern and non-NS4-like but uses the system colors properly. But Modern isn't it.)
> If you need 20 lines of C# to check if a file exists
Yeesh, I hope you made that number up. I think even COBOL can do it in less than twenty lines (though probably not much less), and Perl is probably not the only language that would do it in one line. Heck, it'd be about three lines in BASIC.
> "hey man, would you like to try out call display, I'll give it to you for > two months free if you want to try it!", so the customer accepts (hey! it's > free!), gets told that the feature is normally 4$ and that unless he calls > in to have the option removed before the end of the promotion, he'll start > getting charged automatically for the feature once the promotion ends.
*This* should be illegal. It's the same sort of scam the record company CD clubs and certain less-than-altogether-ethical book clubs use to sell people stuff they don't actually want to buy. ("Every month we send you a selection listing [that looks like an advert so you'll throw it away immediately] showing what the month's selections are, and if you don't want them simply return the included order form with the box marked that says you don't want them this month, and you are under no obligation.")
This effectively reverses the normal order of things. Normally you take action to buy something or inaction to not buy; this reverses it and requires action to not buy, and that should be illegal. Mind you, I'm not talking about action to *stop* buying (e.g., cancelling your ISP or phone service); that's different, because you took action to *start* buying and knew it would be a monthly bill. The record club scam is different because the thing you agreed to specifically said you'd be under no obligation, but in fact it places you under an obligation to either buy or take action in order to not buy. Your "free trial" is similar -- the thing you agreed to was to try something out for free; they shouldn't be allowed to charge you for it without contacting you again: "Hey, you know that free trial of Foo Service I extended to you? How's that going? Is it a useful service? Shall I cancel it for you, or would you like to subscribe to it?" They don't do this because they want to sell it to you whether you want it or not.
The only saving grace is that you only have to take action once to cancel, unlike the record clubs which require you to take action every month for an undisclosed period of time.
> you're talking to an entry-level CS person and you have to convince them > you're not an idiot to get them to transfer you to a level-2 CS person.
I've had good success at this, by speaking calmly and clearly about the problem and sprinkling in a mixture of obviously-literate standard English vocabulary and correctly-used technical jargon. You don't want to talk *completely* over their heads, but you want them to occasionally have to infer the meaning of a word or two from context if they're not highly literate -- or on the off-chance that they _are_ highly literate, you want them to know that you are also. Similarly, in terms of technical jargon, you don't want to lose them completely in a sea of TLAs they don't have a hope of understanding, but you do want to use just enough that they get the idea you have a clue what you are talking about.
Also, for reasons having to do with ego, you don't want to belittle their (probably scripted) ideas, but you want to give them the idea you wouldn't have called if it could be solved that easily. If you can truthfully say, "Yes, I tried that, and this is what happened... [relate details] Hang on a second, I'll try it one more time..." to three of their first four suggestions, you're on your way to their thinking you have some clue -- and that's what gets you escalated to tier 2.
The only situation in which I've found that all of this doesn't work is when dealing with APC tech support about an issue with Powerchute for OpenVMS, but as near as I can tell they don't *have* any tier 2 for that product.
> Unfortunately, the literacy rate of the United States is not necessarily > equal to the literacy rate among Sprint customer service representatives
On the contrary, a low-end job with poor pay will land mostly employees who are substantially less literate than average. I can confirm this with regard to fast food from personal experience. I worked fast food for six years, but *most* of my coworkers were... how shall I put this... not extensively educated. In some cases, I was *concerned* by the fact that they'd been given high school diplomas at some point in their past, something that they clearly hadn't earned. Perhaps alarmingly, and definitely surprising to me at the time, the average educational level among managers was even lower than among the crew.
> Please forgive my ignorance of html
You really should learn it -- at least the basics. It takes about three hours, give or take half of that, and is quite useful if you spend any time on the internet on an even remotely regular basis.
> there is more information about the status of Ebonics as a separate language > at www.cal.org/ebonics/ [...] I'm sure we'd be a little upset if the call > centers in India allowed their representatives to speak to all callers in > Indian.
By "Indian" I imagine you mean "one of the Hindustani languages"? If so, you're being dense. There is absolutely no comparison between a minor, dialectical, type of difference such as that between (say) British English versus Ebonics, and an all-out sweeping almost-complete lack of similarity such as between a language descended from Sanskrit and one that comes mostly from Latin-derived ("Romance") languages, Germanic languages, and Greek. Yes, the Hindustani languages are Indo-European, but they are from the extreme opposite end of the spectrum of IE languages, as dissimilar from English as it is possible for any Indo-European language to be. They have three or four times as many consanants, don't use an alphabetic writing system,... in short, they are *WAY* more foreign than Ebonics (though not quite as foreign as, say, Hangul).
Yes, I have some trouble understanding Ebonics (which, incidentally, is misnamed; skin color has very little to do *directly* with who speaks it (though there's a strong correlation for historical reasons); it's all about where you're from, a cultural phenomenon), but it's *nothing* like as hard to follow (for someone who speaks English) as e.g. Hindi.
> When I did a review of Mandrake 10.0, I found that nearly all the software > was beta stuff
All Mandrake anything.0 releases have a lot of bleeding-edge stuff. 9.0 had a version of gcc that was binary incompatible with both past *and* future versions, for crying out loud, because the binary-incompatible changes were halfway finished. If you want stability, you hold out for the.1 or.2 release.
I have Windows on one computer. In some ways that computer's better than my Linux box, hardware-wise (though it does have less RAM and a worse soundcard). The CPU is a lot faster, and it's got more hard drives, a CD burner (which I've actually thought about moving to the Linux box... xcdroast is actually a lot easier to use than that Nero thingy), a LOT more USB ports than I can ever use, plus FireWire (for which I also have yet to discover a use), and a better graphics card (Matrox, as opposed to onboard junk in the Linux box). So you'd think I'd use the Windows system quite a lot...
I have a KVM switch and can go back and forth between them at will. But I spend *almost* all of my time under Linux, even when editing a file that's actually stored on the Windows system. Why? I don't know, exactly... It's just more... comfortable. Things work properly. I don't have to jump through hoops to get things to do what I want.
There is an exception. Copy & Paste works better on Windows. On Windows, I don't have any trouble e.g. copying from Emacs/Gnus and pasting in Mozilla.
But a lot of things work better/smoother on Linux. The terminal emulators are better. The Gimp runs more smoothly and crashes less. Symlinks are supported better, which makes it easier to get to things I often need to get to without navigating through a bunch of nested directories. Little stuff like that.
I do have Windows in a *much* more usable state than it would be out of the box. I have Mozilla all set up and properly customized, plus Emacs, Gimp, and OpenOffice. (OpenOffice actually runs pretty well on Windows, except I have to remember to save from time to time.) And I installed ActiveState Perl, plus Cygwin, plus various Windows ports of various other utilities, ttssh, and assorted other things to try to bring it up to snuff. But I haven't yet got *everything* installed. There's no dig for example.
The big thing, though, is a complete lack of adequate customizeability. With sawfish I have a windowshade button on my window titlebars. On Windows that's just not available. On Gnome I have a panel full of launchers and drawers up the left edge of the screen, and the task list along the bottom edge. On Windows that's not possible. (No, I know about LiteStep, but... No, just, No.) I could go on listing little things like this for paragraphs, but I don't need to list every one. Individually they're all very little and mostly insignificant quibbles, but they add up to quite a lot, taken all together.
Oh, and I can't ssh into my Windows system remotely.
> While I and many other people know English well enough to use english- > centered programs, many other people have environments completely in their > own language. For example, in Spain pretty much everybody sees Spanish and > other Spanish on the screen.
That's fine. You can localize for Spanish all you want. People in France and Africa can localize for French. I was talking about a very necessary component of localizing for English.
> For example in Spanish, some words have completely different meanings > depending on whether they have an accent or not.
Yes, also in Greek and various other languages -- but not in English. So those languages (Spanish, Greek,...) would localize such things as tab completion rather differently from English. That's fine. I was only talking about how it should be on systems localized for English. I'm quite aware of the fact that it would be different for users who use other languages. If you go back and reread my post, you'll discover I said that already.
> Then there are more problems. Don't think there's only Unicode.
Yeah, the people figuring out how to make l10n work for Hindi and Russian and whatnot have to deal with those problems. However, they have no impact on English localization, which is what I was talking about. Character sets are largely irrelevant to English. We do have a few dozen words with diacritical marks, most of them borrowed from French, but nobody ever types the marks, because typewriters and computer keyboards don't support them. Books that are typeset for publication have the marks, but stuff typed up by normal people leaves them out, and it's not a problem. We still know what a facade is even without the cedilla. In fact, there are some words that people get confused about and aren't sure where the diacritical marks go.
As far as Unicode, there's an entire large continent where it's almost totally irrelevant, because it's virtually impossible to buy a keyboard here capable of typing anything other than ASCII. We couldn't use unicode if we wanted to do so. If we want to type in a foreign language, we get a transliterative font and use that. (For example, to typeset Greek, I use the Mounce font, from Teknia, which allows me to type an a and have it appear as an alpha, and so on. It even has the diacritical marks as separate characters that display over the previous letter.) There are a number of difficulties with this approach, but they are outweighed by the fact that this approach is one we are actually capable of using with keyboards that we can buy without going to Europe.
> If you move from the 'filenames are sequences of bytes' concept you suddenly > have to implement lots and lots of stuff. Things like having the OS know > about every encoding out there, how to change case, what characters are > equivalent...
People who need to implement case-insensitivity for various languages will have to deal with those issues, but we can implement it for English without worrying about them. Like I said, for the purpose of localizing tab completion for English-language users, it would be good enough to only support the letters in the ASCII character set. Also supporting Latin-1 would be icing on the cake, since most of use can't type those characters anyway. Forget about Unicode; let the people localizing for other languages worry about that. English-language users don't need it.
> 20 years, in that time if mores law holds the average processor will be > 2^(20/1.5) times more powerful, which is to say 10321x more powerful than today
Yes, but meanwhile expectations (regarding resolution, object complexity, and so on and so forth) also keep going up, as existing game technology develops. It is not enough to have the processing power to raytrace something that would look very impressive today.
20 years could be longer than is required, but it's very hard to tell ahead of time how long it will be. My point is that the time isn't here yet, though experiments like this are interesting anyway of course.
> So my question is, for those of us who don't know the first thing about 3D > graphics, what are the pros and cons of a raytracing GPU, compared to the > polygon pushers we currently know and love.
Raytracing requires a good deal more out of your hardware. They're running a twenty-node cluster and only getting 20 fps, and I bet they're not even doing some of the fancier tricks raytracing is capable of doing. So the downside is, raytracing is slower, a *lot* slower on the same hardware.
The advantages to raytracing are threefold: 1. It looks better. 2. It looks better. 3. It looks better.
For still images, raytracing is definitely the way to go. If you've never had a serious look at it, go over to www.irtc.org and flip through their gallery.
IMO, it's only a matter of time before games adopt realtime raytracing, but it may be quite a bit of time yet, perhaps 20 years or so before it really goes mainstream. Because, let's face it, 20 fps isn't really playable, and they wouldn't even be getting that kind of speed if they weren't cutting some fairly significant corners (probably disabled things like refraction and focal blur and area lights, unless I've missed my guess), and it's going to be a few months yet (ahem) before the average gamer has a twenty-node cluster.
I liked how I had my DOS system organized. Root directories included C:\DOS and C:\UTIL and C:\BAT (which were in my PATH and held the core OS commands, third-party one-file addon commands, and batch files that launched apps), C:\APPS (which included directories for each application), and I had a separate partition D: for data (documents, images, mail, and so on). C:\APPS and D: of course both had multiple subdirectories. Each application had a batch file in C:\BAT that changed to the application directory if necessary and launched the application.
I tried to keep this structure with Windows, but too many Windows applications refused to install in a non-default location, so I ended up with applications in both C:\APPS and C:\PROGRA~1, and my organization degenerated from there.
Mandrake is in some ways worse, though it's pretty good about keeping my data in my home directory, along with a lot of my customizations (the ones that don't go in/etc, that is). This makes knowing what to back up easy enough. Application files are stored all over the place, though, which is a real pain on occasion, when I'm trying to find something particular. (For example, I knew I had a Java2 runtime installed, but when I was installing a new version of OOo and it asked where, I couldn't for the life of me find it and ended up installing Java all over again just to note where it put itself, which I now don't remember again because it was a horrifically unobvious place. I've been using Linux since 1998; I should NOT have trouble figuring out where Java is installed. This is not a problem unique to Sun's software, and it's something that needs to be worked on.)
> In Linux, it's just all bytes, it doesn't care if it's english, cyrillic
> or whatever. With case insensitivity it suddenly has to know what to
> do with cyrillic letters as well.
I'd be happy if case-insensitivity were only supported for the twenty-six
letters in the ASCII character set. I'd award extra bonus points for also
handling accented Latin characters and allowing
the user to type plain unaccented versions of filenames that canonically have
some diacritical marks, hit tab, and have it "complete" by substituting the
accented characters where appropriate. (Obviously, if there's a file called
Resume.HTM and I type Resu and hit tab, it should complete to that first, only
finding resumé.html if a closer match didn't exist. Whether it should
find case-altered versions before versions with different diactritics is an
open (but IMO unimportant) question. The key thing is to get the completion
right when it's obvious which file is meant, and otherwise the user can
either name his files more uniquely or cycle through several possible
completions each time.
I understand why case-insensitivity isn't entirely straightforward in
all languages, but I'm not asking for case-insensitivity for all
languages; I'm asking
for case-insensitivity for languages where it's really easy to do and
traditionally assumed in many contexts (even many non-computer
contexts) -- notably English. Consider it part of localizing
the system for English-speaking countries, if you want. I'm sure
other languages might have other types of localization that might not
make sense in English. For example, I can readily imagine that Hebrew
localization might include the ability to just type the consonants and
have the vowells automatically filled in, or something like that. (I
made up the example, but you get the idea.) Just because that would be
a real pain and of limited utility for English doesn't mean it shouldn't
be implemented for
any other language. Just make it part of the l10n and users of other
languages don't even have to know about it. But English should definitely
have case-insensitivity at least optionally.
> I figure the key is most for people who find holding down shift while typing > several letters difficult
Yep, people who don't touch-type use the caps lock a lot, sometimes even when they only need one capital letter. People who type a lot know that its faster and easier to just hold shift and type the letters.
> I can't stand using a mouse unless I'm doing CAD
I find the mouse is also quite useful in Gimp, and middle-clicking links on the web to queue them in tabs is also handy.
I agree about the 101-key layout; the new keys in-between the main body of the keyboard and the keypad: I never use them. I use the keypad for cursor control still, to this day, because it's arranged so that I can reach all of the keys on it without moving my hand.
Slashdot Mirror
One last thing. Resist the urge to interrupt the music frequently with
voiceovers explaining how important the call (allegedly) is to you. One
such voiceover early in the hold (possibly even before the music starts)
is probably a good idea; beyond that, spread them out at least twice as far
as you think they ought to go, and either put them between music tracks or
leave the music playing in the background during the voiceover. Above all,
do *not* stop the music every fifteen seconds, giving false hope that a
live person is about to pick up, only to play a voice recording. That's
more annoying than almost any music you could pick. Once you start the
music, just let it play. (Exception: if you have the capability to notify
the user when they move up in the queue due to completion of a previous call
(a la, "Thanks for holding; you are now second in line to speak to a tech
support representative. Calls are answered in the order they are received"),
that would be better received, due to being an indicator of real progress.
Still, avoid abruptly stopping the music for this announcement, since that
introduces false hope that the call is being picked up by a live human.
Instead, run the voice overtop without stopping the music if possible.)
IMO, you want to go with something instrumental, preferably something
... -- and there are people who passionately hate it. That's not
venerable.
You have a couple of options here. You could go with something slow and
soothing, on the theory that it will keep people calm; in that case, something
from the Romantic era is probably what you want, e.g. Chopin. This has the
disadvantage that it will put people to sleep, however. The other choice is
to go with something with a bit more pizazz (but not so much pizazz as to be
annoying). The Baroque era is rich in music that is peppy enough to be
interesting but nevertheless sedate enough to avoid making anyone crazy. If
I were picking, I'd tell you to get Munchinger's performance of the _Art of
Fugue_, which is really excellent; I've received positive comments about it
from people who generally don't listen to old music in general or Baroque in
particular but liked this album. Contrapunctus II is particularly fetching.
Another reasonable option would be something classical. Very few people have
a strong dislike for Mozart, for example; people may feel that he's overrated
(e.g., I do), but they won't be hanging themselves with the phone cord after
the tenth measure.
What you absolutely want to avoid is anything with lyrics. Lyrics get more
attention, get noticed, and get a reaction. That's bad. Lyrics make fans,
but they also make foes. Genres with lyrics sell a lot of albums, because
a lot of people like them -- but a lot of people hate (any given genre of)
them too. You pick any genre with lyrics -- rap, rock-and-roll, metal,
country,
what you want for hold music; you want something everyone can at least put
up with; it's not necessary for anyone to be _excited_ about the music; you
just want them to be able to stand it okay.
There's another strategy you could follow: Make it play the tail end of
something obnoxious for the first ten seconds and then switch to something
else. People will be so relieved they won't mind if the thing it switches
to is not their first choice. But this only works if the obnoxious music
is significantly obnoxious. Perhaps a polka rendition of MacArthur Park,
or an amateur nobody singing a Neil Diamond song, or something like that.
Of course, that breaks down once people have been on hold enough times to
know the trick. What I would really recommend is going with the Bach.
But don't get a recording played on organ; Bach fans love that, but a lot
of people dislike organ music. Go with an orchestral recording, like the
the abovementioned Munchinger one. That's harder to hate.
Finally, realize that no matter *what* you pick, you *cannot* please
absolutely everyone. There will always be some loon who thinks you should
play Country music, and he'll be mildly irritated that you don't; you have
to reconcile yourself to the fact that it's a choice between irritating that
guy mildly, by not playing his first choice, versus playing the Country and
driving other people out of their skulls with loathing. (If it's not
Country, it'll be metal or rap or some other love-it-or-hate-it genre;
avoid these, and go for something hard-to-hate instead of something that
some people really love.)
If it blocks cellphones, I want it for the library where I work. All of my
coworkers would agree.
You say you've been using Linux for years? Okay, so then you know about IP
Masquerade, yes? Use it. Pull a spare Pentium-90 out of the closet, put an
extra $8 NIC in it, set it up with your favorite distro, and connect *that*
system directly to the net. Set it up with a second, local network on the
second NIC (I usually use 192.168.0.*), and have it masq that network onto
the internet. Hook your Windows system up to the local network and have it
use the IP-Masq box as the gateway. This protects you from anything that
relies on open ports to spread, which includes most worms. You still have
some vulnerabilities, mostly in clients, _especially_ Outlook Express, which
you should avoid entirely if at all possible and certainly at least until
you've got all the updates installed.
People with no Linux experience can buy a hardware NAT gateway or firewall
and accomplish basically the same thing.
When you finish getting Linux installed, you should still leave it behind
the NAT gateway. You can turn off all the software firewalls you want then;
although they do provide one additional piece of protection (namely, flagging
certain kinds of rogue outgoing traffic that can be caused e.g. by spyware),
that's more a form of detection than prevention, so switching it off for a
few minutes to install some updates is not a big deal. The NAT gateway will
cover the more important function of preventing rogue incoming traffic.
> 1) Not all pictures are suited to a scalable graphics format. (eg.
> Continuous tone images for which JPEGs are appropriate.)
While it's true that not all images are suitable to SVG specifically, I don't
think it necessarily follows that they are not suitable to any scalable format
at all, in theory. (Of course, in practice there is a dearth of scalable
image formats widely supported by browsers, but that may not always remain
the case.)
As for JPEGs, if everyone in the whole world stopped using them yesterday it
wouldn't be soon enough for me. I guess I notice different things from most
people, but JPEG compression to me is uglier than almost any other type of
ugliness an image can have. (Color-depth reduction a la GIF is nearly as
bad.) I'd rather look at an out-of-focus badly-cropped poorly-exposed
snapshot taken with no thought given to composition than look at a JPEG.
Any time I have to do anything with an image that's been JPEG-compressed I
end up having to scale it to a quarter of its size just to make it look
passably decent, and in particularly bad cases sometimes I have to also run
a Gaussian blur over it to kill the remaining artifacts.
Okay, so the alpha channel in PNG has lousy support in legacy browsers, but
you can still use PNG without relying on the alpha channel. That extra 20%
compression you get from JPEG isn't worth making the image look like that.
> Current CSS does not allow for portable image scaling. The use of
> tables vs. CSS has little to do with the issue of resolution scaling.
It's relatively easy to make a scalable page without scalable images,
provided no single image is larger than about 300 pixels -- which for
bandwidth reasons is larger than most sites ought to have any single image
be anyway, except for a few special cases where one particular image is
the whole point of the page (e.g., maps).
There are a few basic rules that lead to scalable pages...
* No single image is larger than about 300 pixels in either dimension.
* All non-image sizes (e.g., font sizes) are specified in em or %.
You can make an exception for very thin borders (1 pixel) if you don't
mind their becomming arbitrarily thin hairlines at insane resolutions.
* Don't use an image when the same visual effect can be achieved with plain
old HTML and CSS. For example, you don't use an image for a region of
solid color; you style it that way with CSS. Similarly, instead of using
an image of some blue letters, you style the letters blue, with the font
you like (and a couple of similar backup options), and so on. Yes, there
is a risk the user won't have the font, but unless the font is obscure
it's no greater than the risk that the user will have a different res and
it degrades more gracefully; if you pick good substitute fonts, the user
will never even know anything is wrong. You can make an exception to this
for esoteric fonts, e.g. if you really want a heading to be in an Old
English font, since almost nobody has one installed. Also logos are an
exception here; a logo should almost always be an image (though SVG is
a good choice for logos, or would be if browser support were better).
* Test at 640x480 and 1600x1200 in two browsers that use different rendering
engines (e.g., if one uses Gecko the other should not).
I'm probably forgetting one or two other things, but it's all pretty basic
and obvious stuff, and contrary to popular myth, use or non-use of tables
is almost entirely irrelevant, as you said. It's what you put in the tables
that determines how well they scale.
> Computer displays are in pixels.
Yeah, but they're all in different numbers of pixels. If you check the
window size of twenty random browsers, you'll get 18 or 19 different sets
of dimensions. Two or three will be the same because they'll be maximized
at 640x480 or 800x600.
> I'm a bit surprised though that you could move from VB to Delphi without
> having some background in pascal... basic and pascal weren't all that
> syntactically similar.
From what I remember (and it *has* been a while; these days I think in Perl
or lisp), VB isn't terribly similar[1] syntactically to BASIC, either, and
seems to borrow quite a bit from Pascal. Not everything, of course, and
there are significant and obvious signs of a BASIC heritage (e.g., optional
sigil-like one-punctuation-character type suffices, some of which even have
the same meaning as in BASIC), but you also find in VB some rather unBASICish
things like do loops and such, which smack heavily of Pascal -- and of course
both VB and Delphi put a lot of stock in supporting the event-oriented
paradigm, so they're also similar from that standpoint.
[1] By "not terribly similar" I of course don't mean "completely dissimilar".
BASIC and Pascal are similar enough to be grouped together and contrasted
with lisp, for example. But VB is somewhere between more traditional
BASICs and Pascal, and while it may be closer to the BASIC side, the
differences are significant.
> Of course, Gates and Allen did not invent BASIC either, so to even claim
> that they " develop[ed] the first commercial programming language for a
> personal microcomputer." is a stretch
I believe the correct form of the statement would be, "developed the first
implementation of a high-level programming language for that platform". My
first guess would be that the person who shorted that to "developed the
first programming language" probably wasn't a programmer, in which case he
wouldn't understand the difference between a language and an implementation
or understand the difference between "developed the first foo for the bar
platform" and "used the bar platform to develop the first foo". (To know
that the difference is significant, you have to parse the first one based
on the knowledge that an implementation may be platform-specific, something
a lot of people wouldn't know.) In other words, it was probably written or
edited by someone who didn't know enough to be accurate about this topic.
I very much doubt there was any deliberate deception in the statement; it's
more likely inaccurate due to garden-variety incompetence.
> that's the first time on Slashdot I've ever seen someone use the words
> "Fortran" and "happily" in the same sentence!
Fortran is actually very good at what it does (i.e., crunch numbers). It's
completely inappropriate for most of the things most people do with computers
most of the time (e.g., anything that involves any text processing), but for
what it was designed for, it's excellent.
The trouble comes when you mistake it for a general-purpose language and try
to use it to program something you shouldn't. For example, you should not use
it to implement a mail server (unless your goal is to impress the everliving
daylights out of the same sort of people who think it's really cool to write
a quine that's valid in four different languages including C and Postscript).
No, you should use probably Perl or Python or something along those lines
for that sort of thing, or in a pinch you could get by with C better than
Fortran, although C isn't particularly good for text processing either.
But that doesn't make Fortran bad, any more than Postscript is bad for being
designed for printing. It just makes it a special-purpose language rather
than a general-purpose one. Code written in special-purpose languages often
has a symbiotic relationship with code written in glue languages (e.g., shell
scripts or these days more likely Perl). There's no reason your high-end
physics simulation couldn't use Fortran for the heavy numerical stuff and
Perl to handle other things like I/O -- or even use Perl to glue the Fortran
number-crunching code together to a UI written in something else, maybe XUL.
Fortran would only be painful if you tried to use it for the parts of the
project it's not good for. Stick to doing numbers with it and you'll be
much happier.
Actually, Internet Explorer is no longer a separate project, but has been
merged with their larger browser-application-suite project, which (just like
the browser we're discussing) seems to change codenames every version.
Right now there are at least two different codenamed-versions of it under
development, Longhorn and Blackcomb. (Weird project codenames? Check. And
you thought that Phoenix -> Firebird and Firebird -> Firefox were gratuitously
odd project codename transitions. At least Longhorn and Blackcomb are
relatively unique, in the sense of not having been used as product names
millions of times already, unlike Phoenix and Firebird. Firefox also seems
okay in that regard, though.)
Of course, Firebird and Longhorn/Blackcomb aren't really aimed at the same
browser market niche. Firebird is aimed at people who think the Mozilla
Seamonkey suite is too bloated with non-browser features like email and
usenet; Longhorn/Blackcomb are aimed at people who think the web browser
should be integrated with the file manager and maybe also integrated with
a word processing suite and include a music player and possibly a Solitaire
game and all sorts of other technically-non-browser features plus convenient
automatic-remote-execution features. It's really the opposite approach from
Firefox and would appeal to completely different market segments.
> Don't suppose you have any info or resources on how to deploy Mozilla
> Firefox in a standard Windows Active Directory network do you?
The same way you would deploy any other application in AD. (No, I don't know
how to do that, but I don't use AD. If we used AD where I work, I'd make it
my business to know how to use it. I think O'Reilly has a book on it.)
> It'd be essential that Firefox could be restricted in a similar way to IE.
Firefox is naturally secure, if that's what you're worried about; you don't
need to lock it down like you would IE because it doesn't have IE's holes.
If you're more worried about users visiting sites they're not supposed to,
then you should be using a proxy and blocking outgoing ports 80 and 443 at
the firewall; otherwise, savy users can get around your AD restrictions.
(Actually, they *still* can get around even the port blocking, but it's a
lot more of a pain and will leave a trail if IT is paying attention.)
> Why doesn't Mozilla ship with the Modern theme on by default
Accessibility. Modern ignores the system colors, which violates accessibility
guidelines. Classic may be ugly, but it adheres to the guidelines better in
this respect. (It would of course be possible to create a non-ugly theme
that looks modern and non-NS4-like but uses the system colors properly. But
Modern isn't it.)
> If you need 20 lines of C# to check if a file exists
Yeesh, I hope you made that number up. I think even COBOL can do it in less
than twenty lines (though probably not much less), and Perl is probably not
the only language that would do it in one line. Heck, it'd be about three
lines in BASIC.
Actually, HQ9+ has an even shorter Hello, World.
> "hey man, would you like to try out call display, I'll give it to you for
> two months free if you want to try it!", so the customer accepts (hey! it's
> free!), gets told that the feature is normally 4$ and that unless he calls
> in to have the option removed before the end of the promotion, he'll start
> getting charged automatically for the feature once the promotion ends.
*This* should be illegal. It's the same sort of scam the record company CD
clubs and certain less-than-altogether-ethical book clubs use to sell people
stuff they don't actually want to buy. ("Every month we send you a selection
listing [that looks like an advert so you'll throw it away immediately] showing
what the month's selections are, and if you don't want them simply return the
included order form with the box marked that says you don't want them this
month, and you are under no obligation.")
This effectively reverses the normal order of things. Normally you take
action to buy something or inaction to not buy; this reverses it and requires
action to not buy, and that should be illegal. Mind you, I'm not talking about
action to *stop* buying (e.g., cancelling your ISP or phone service); that's
different, because you took action to *start* buying and knew it would be a
monthly bill. The record club scam is different because the thing you agreed
to specifically said you'd be under no obligation, but in fact it places you
under an obligation to either buy or take action in order to not buy. Your
"free trial" is similar -- the thing you agreed to was to try something out
for free; they shouldn't be allowed to charge you for it without contacting
you again: "Hey, you know that free trial of Foo Service I extended to you?
How's that going? Is it a useful service? Shall I cancel it for you, or
would you like to subscribe to it?" They don't do this because they want to
sell it to you whether you want it or not.
The only saving grace is that you only have to take action once to cancel,
unlike the record clubs which require you to take action every month for
an undisclosed period of time.
> you're talking to an entry-level CS person and you have to convince them
> you're not an idiot to get them to transfer you to a level-2 CS person.
I've had good success at this, by speaking calmly and clearly about the problem
and sprinkling in a mixture of obviously-literate standard English vocabulary
and correctly-used technical jargon. You don't want to talk *completely* over
their heads, but you want them to occasionally have to infer the meaning of a
word or two from context if they're not highly literate -- or on the off-chance
that they _are_ highly literate, you want them to know that you are also.
Similarly, in terms of technical jargon, you don't want to lose them completely
in a sea of TLAs they don't have a hope of understanding, but you do want to
use just enough that they get the idea you have a clue what you are talking
about.
Also, for reasons having to do with ego, you don't want to belittle their
(probably scripted) ideas, but you want to give them the idea you wouldn't
have called if it could be solved that easily. If you can truthfully say,
"Yes, I tried that, and this is what happened... [relate details] Hang on
a second, I'll try it one more time..." to three of their first four
suggestions, you're on your way to their thinking you have some clue --
and that's what gets you escalated to tier 2.
The only situation in which I've found that all of this doesn't work is when
dealing with APC tech support about an issue with Powerchute for OpenVMS, but
as near as I can tell they don't *have* any tier 2 for that product.
> Unfortunately, the literacy rate of the United States is not necessarily
... in short, they are *WAY* more foreign than Ebonics (though
> equal to the literacy rate among Sprint customer service representatives
On the contrary, a low-end job with poor pay will land mostly employees who
are substantially less literate than average. I can confirm this with regard
to fast food from personal experience. I worked fast food for six years, but
*most* of my coworkers were... how shall I put this... not extensively
educated. In some cases, I was *concerned* by the fact that they'd been
given high school diplomas at some point in their past, something that they
clearly hadn't earned. Perhaps alarmingly, and definitely surprising to me
at the time, the average educational level among managers was even lower than
among the crew.
> Please forgive my ignorance of html
You really should learn it -- at least the basics. It takes about three hours,
give or take half of that, and is quite useful if you spend any time on the
internet on an even remotely regular basis.
> there is more information about the status of Ebonics as a separate language
> at www.cal.org/ebonics/ [...] I'm sure we'd be a little upset if the call
> centers in India allowed their representatives to speak to all callers in
> Indian.
By "Indian" I imagine you mean "one of the Hindustani languages"? If so,
you're being dense. There is absolutely no comparison between a minor,
dialectical, type of difference such as that between (say) British English
versus Ebonics, and an all-out sweeping almost-complete lack of similarity
such as between a language descended from Sanskrit and one that comes
mostly from Latin-derived ("Romance") languages, Germanic languages, and
Greek. Yes, the Hindustani languages are Indo-European, but they are from
the extreme opposite end of the spectrum of IE languages, as dissimilar from
English as it is possible for any Indo-European language to be. They have
three or four times as many consanants, don't use an alphabetic writing
system,
not quite as foreign as, say, Hangul).
Yes, I have some trouble understanding Ebonics (which, incidentally, is
misnamed; skin color has very little to do *directly* with who speaks it
(though there's a strong correlation for historical reasons); it's all
about where you're from, a cultural phenomenon), but it's *nothing* like
as hard to follow (for someone who speaks English) as e.g. Hindi.
> When I did a review of Mandrake 10.0, I found that nearly all the software
.1 or .2 release.
> was beta stuff
All Mandrake anything.0 releases have a lot of bleeding-edge stuff. 9.0 had
a version of gcc that was binary incompatible with both past *and* future
versions, for crying out loud, because the binary-incompatible changes were
halfway finished. If you want stability, you hold out for the
I have Windows on one computer. In some ways that computer's better than my
Linux box, hardware-wise (though it does have less RAM and a worse soundcard).
The CPU is a lot faster, and it's got more hard drives, a CD burner (which
I've actually thought about moving to the Linux box... xcdroast is actually
a lot easier to use than that Nero thingy), a LOT more USB ports than I can
ever use, plus FireWire (for which I also have yet to discover a use), and
a better graphics card (Matrox, as opposed to onboard junk in the Linux box).
So you'd think I'd use the Windows system quite a lot...
I have a KVM switch and can go back and forth between them at will. But I
spend *almost* all of my time under Linux, even when editing a file that's
actually stored on the Windows system. Why? I don't know, exactly... It's
just more... comfortable. Things work properly. I don't have to jump through
hoops to get things to do what I want.
There is an exception. Copy & Paste works better on Windows. On Windows, I
don't have any trouble e.g. copying from Emacs/Gnus and pasting in Mozilla.
But a lot of things work better/smoother on Linux. The terminal emulators
are better. The Gimp runs more smoothly and crashes less. Symlinks are
supported better, which makes it easier to get to things I often need to get
to without navigating through a bunch of nested directories. Little stuff
like that.
I do have Windows in a *much* more usable state than it would be out of the
box. I have Mozilla all set up and properly customized, plus Emacs, Gimp,
and OpenOffice. (OpenOffice actually runs pretty well on Windows, except
I have to remember to save from time to time.) And I installed ActiveState
Perl, plus Cygwin, plus various Windows ports of various other utilities,
ttssh, and assorted other things to try to bring it up to snuff. But I
haven't yet got *everything* installed. There's no dig for example.
The big thing, though, is a complete lack of adequate customizeability.
With sawfish I have a windowshade button on my window titlebars. On Windows
that's just not available. On Gnome I have a panel full of launchers and
drawers up the left edge of the screen, and the task list along the bottom
edge. On Windows that's not possible. (No, I know about LiteStep, but...
No, just, No.) I could go on listing little things like this for paragraphs,
but I don't need to list every one. Individually they're all very little
and mostly insignificant quibbles, but they add up to quite a lot, taken
all together.
Oh, and I can't ssh into my Windows system remotely.
> While I and many other people know English well enough to use english-
...) would localize such things as tab completion
> centered programs, many other people have environments completely in their
> own language. For example, in Spain pretty much everybody sees Spanish and
> other Spanish on the screen.
That's fine. You can localize for Spanish all you want. People in France
and Africa can localize for French. I was talking about a very necessary
component of localizing for English.
> For example in Spanish, some words have completely different meanings
> depending on whether they have an accent or not.
Yes, also in Greek and various other languages -- but not in English. So those
languages (Spanish, Greek,
rather differently from English. That's fine. I was only talking about how
it should be on systems localized for English. I'm quite aware of the fact
that it would be different for users who use other languages. If you go back
and reread my post, you'll discover I said that already.
> Then there are more problems. Don't think there's only Unicode.
Yeah, the people figuring out how to make l10n work for Hindi and Russian and
whatnot have to deal with those problems. However, they have no impact on
English localization, which is what I was talking about. Character sets are
largely irrelevant to English. We do have a few dozen words with diacritical
marks, most of them borrowed from French, but nobody ever types the marks,
because typewriters and computer keyboards don't support them. Books that
are typeset for publication have the marks, but stuff typed up by normal
people leaves them out, and it's not a problem. We still know what a facade
is even without the cedilla. In fact, there are some words that people get
confused about and aren't sure where the diacritical marks go.
As far as Unicode, there's an entire large continent where it's almost totally
irrelevant, because it's virtually impossible to buy a keyboard here capable
of typing anything other than ASCII. We couldn't use unicode if we wanted
to do so. If we want to type in a foreign language, we get a transliterative
font and use that. (For example, to typeset Greek, I use the Mounce font,
from Teknia, which allows me to type an a and have it appear as an alpha,
and so on. It even has the diacritical marks as separate characters that
display over the previous letter.) There are a number of difficulties with
this approach, but they are outweighed by the fact that this approach is
one we are actually capable of using with keyboards that we can buy without
going to Europe.
> If you move from the 'filenames are sequences of bytes' concept you suddenly
> have to implement lots and lots of stuff. Things like having the OS know
> about every encoding out there, how to change case, what characters are
> equivalent...
People who need to implement case-insensitivity for various languages will
have to deal with those issues, but we can implement it for English without
worrying about them. Like I said, for the purpose of localizing tab completion
for English-language users, it would be good enough to only support the letters
in the ASCII character set. Also supporting Latin-1 would be icing on the
cake, since most of use can't type those characters anyway. Forget about
Unicode; let the people localizing for other languages worry about that.
English-language users don't need it.
> 20 years, in that time if mores law holds the average processor will be
> 2^(20/1.5) times more powerful, which is to say 10321x more powerful than today
Yes, but meanwhile expectations (regarding resolution, object complexity, and so
on and so forth) also keep going up, as existing game technology develops. It
is not enough to have the processing power to raytrace something that would
look very impressive today.
20 years could be longer than is required, but it's very hard to tell ahead of
time how long it will be. My point is that the time isn't here yet, though
experiments like this are interesting anyway of course.
> So my question is, for those of us who don't know the first thing about 3D
> graphics, what are the pros and cons of a raytracing GPU, compared to the
> polygon pushers we currently know and love.
Raytracing requires a good deal more out of your hardware. They're running a
twenty-node cluster and only getting 20 fps, and I bet they're not even doing
some of the fancier tricks raytracing is capable of doing. So the downside is,
raytracing is slower, a *lot* slower on the same hardware.
The advantages to raytracing are threefold: 1. It looks better. 2. It looks
better. 3. It looks better.
For still images, raytracing is definitely the way to go. If you've never had
a serious look at it, go over to www.irtc.org and flip through their gallery.
IMO, it's only a matter of time before games adopt realtime raytracing, but it
may be quite a bit of time yet, perhaps 20 years or so before it really goes
mainstream. Because, let's face it, 20 fps isn't really playable, and they
wouldn't even be getting that kind of speed if they weren't cutting some fairly
significant corners (probably disabled things like refraction and focal blur
and area lights, unless I've missed my guess), and it's going to be a few
months yet (ahem) before the average gamer has a twenty-node cluster.
But it will come in time.
I liked how I had my DOS system organized. Root directories included C:\DOS
/etc, that is). This makes knowing what to back up easy enough.
and C:\UTIL and C:\BAT (which were in my PATH and held the core OS commands,
third-party one-file addon commands, and batch files that launched apps),
C:\APPS (which included directories for each application), and I had a separate
partition D: for data (documents, images, mail, and so on). C:\APPS and D:
of course both had multiple subdirectories. Each application had a batch file
in C:\BAT that changed to the application directory if necessary and launched
the application.
I tried to keep this structure with Windows, but too many Windows applications
refused to install in a non-default location, so I ended up with applications
in both C:\APPS and C:\PROGRA~1, and my organization degenerated from there.
Mandrake is in some ways worse, though it's pretty good about keeping my data
in my home directory, along with a lot of my customizations (the ones that
don't go in
Application files are stored all over the place, though, which is a real pain
on occasion, when I'm trying to find something particular. (For example, I
knew I had a Java2 runtime installed, but when I was installing a new version
of OOo and it asked where, I couldn't for the life of me find it and ended up
installing Java all over again just to note where it put itself, which I now
don't remember again because it was a horrifically unobvious place. I've
been using Linux since 1998; I should NOT have trouble figuring out where
Java is installed. This is not a problem unique to Sun's software, and it's
something that needs to be worked on.)
I'd be happy if case-insensitivity were only supported for the twenty-six letters in the ASCII character set. I'd award extra bonus points for also handling accented Latin characters and allowing the user to type plain unaccented versions of filenames that canonically have some diacritical marks, hit tab, and have it "complete" by substituting the accented characters where appropriate. (Obviously, if there's a file called Resume.HTM and I type Resu and hit tab, it should complete to that first, only finding resumé.html if a closer match didn't exist. Whether it should find case-altered versions before versions with different diactritics is an open (but IMO unimportant) question. The key thing is to get the completion right when it's obvious which file is meant, and otherwise the user can either name his files more uniquely or cycle through several possible completions each time.
I understand why case-insensitivity isn't entirely straightforward in all languages, but I'm not asking for case-insensitivity for all languages; I'm asking for case-insensitivity for languages where it's really easy to do and traditionally assumed in many contexts (even many non-computer contexts) -- notably English. Consider it part of localizing the system for English-speaking countries, if you want. I'm sure other languages might have other types of localization that might not make sense in English. For example, I can readily imagine that Hebrew localization might include the ability to just type the consonants and have the vowells automatically filled in, or something like that. (I made up the example, but you get the idea.) Just because that would be a real pain and of limited utility for English doesn't mean it shouldn't be implemented for any other language. Just make it part of the l10n and users of other languages don't even have to know about it. But English should definitely have case-insensitivity at least optionally.
> I figure the key is most for people who find holding down shift while typing
> several letters difficult
Yep, people who don't touch-type use the caps lock a lot, sometimes even when
they only need one capital letter. People who type a lot know that its faster
and easier to just hold shift and type the letters.
> I can't stand using a mouse unless I'm doing CAD
I find the mouse is also quite useful in Gimp, and middle-clicking links on
the web to queue them in tabs is also handy.
I agree about the 101-key layout; the new keys in-between the main body of the
keyboard and the keypad: I never use them. I use the keypad for cursor control
still, to this day, because it's arranged so that I can reach all of the keys
on it without moving my hand.