By recomending that we fix it you're implying that the current system is broken, I am simply stating that it's NOT BROKEN.
In other words, "I would not know anything about good human factors UI design if it bit me on the nose. And why are you gesturing at my nose like that? Cut it out!"
A properly restricted UI will not restrict what the user is capable of doing with the system. Quit the contrary: it will lock in best practices that encourage efficient habits in the user, while allowing enough flexibilty to approach a task in different ways if they choose.
I'm not saying that OSX is the perfect GUI -- far from it. Nor am I saying that there is one right way to define an interface -- there isn't.
But there is a proper balance to be struck between what an interface allows and what it restricts. An interface is not better just because you have absolute control over how widgets are displayed -- in fact, this is often an invitation to greatly de-optimize the quality of the interface, even while superficially "empowering" the user.
Don't argue with me though, I just dabble in this stuff. Pick up a good introductory user interface / human factors textbook, skim over the first few chapters, and then think carefully about what you're sticking up for here. While you're right that not all humans use things the same way, you also miss that there are some approaches that are simply wrong for almost everyone, and a good interface will protect the user from making such misconfigurations.
Put another way, if freeform, user selected UI is such a great thing, then how come we see it in no other industry? Granted, software is more configurable than.... well just about anything. But still, if there were a market for people that wanted, say, their car's steering wheel in the trunk -- because that would be more 'leet -- then the auto manufacturers would have found a way to oblige. No, they allow some mild degree of customization -- all the damn souped up Hondas with the obnoxious growling mufflers & stereo systems -- but they draw the line at changes that would actually impair the user's ability to operate the vehicle: the steering wheel is never in the trunk, no matter how "k3w1" that would be.
This is a good thing. As are computer UIs witih a similar sense of restraint.
Damned straight, we don't need to bow to the pressure to use a sandardised anything, we need to improve our marketing and SELL CHOICE.
In other words, "Don't bother FIXING IT you damned slobs, SELL IT!"
Choice is nice and all, but as Perl well demonstrates, just because there's more than one way to do it doesn't mean that 90% of those ways aren't wrong. "Choice" and "correctness" have very little to do with each other, as anyone even moderately well read in UI research could tell you.
The really great thing about OSX's Aqua interface is that it restricts choice. At first this can feel constricting, but once you give in & go with the flow, you realize that the defaults are actually pretty efficient, and more importantly you're not wasting your time fiddling around with all the settings: we've all got more important things to do than hand-craft the bestest wickedest GUI theme evahhh!??!?!
Sadly, many Linux (esp Enlightenment) users don't seem to agree with that. That's their choice...:-)
I'm currently freelancing as an editor for the official manual on a certain general code compiler that you may have used before. It's not exactly a writing job, but because the book was written by a committee a big part of the work involves rewriting sections to make sure it doesn't read like something written by a committee.
I think this work & some other random writing I've done gives me a little bit of room to reply here.
(1) what are the general opinions of programmers on technical writers;
The work I've done so far has been very well received by the members of this general code compiler's list. Apparently, no one has sat down and attempted to do a cleanup of the text in years, and it shows. Parts of the text were written by people for whom English isn't their strongest language, and most of it was written by people who are more talented as programmers than in explaining complex material to a lay audience. Moreover, the writing style changes drastically from section to section, and even from paragraph to paragraph. Trying to follow such a twisted text would be difficult even if the material wasn't so advanced, so if anyone steps forward and offers to make this material more accessible to people, it seems like that person is likely to be well received.
(2) is there someone out there who has first-hand experience in technical writing who can tell me about the work and their experiences;
What do you want to know? I could go into detail, but the work I've done to date has mostly been editing, not first-hand writing. It's a related task, but not identical. Basically it means looking over the manuscript, making sure that the text is understandable, consistent, and adheres to the house style guidelines. In cases where the text needs to be rewritten, I have to be careful to be sure that the edited text still expresses the same intent that the original version did (and sometimes, that means muddling through what the original intent was in the first place). In cases where the meaning is especially ambiguous, it has meant consulting with experts on the topic, either over the phone, by personal email, or by asking on relevant mailing lists. It has been a lot of work.
Much more than I anticipated when I started (but then, apparently no one realized how messy the text was, how out of date in parts, how ambiguous in others...)
(3) what software is used mainly in the process; and of course
Well, this book is formatted in Texinfo, but that's probably a quirk of this organization. The other book I was involved with was written in Perl's POD documentation format, but again that may have just been the whim of the author's as much as anything else.
I think, more generally, that most pubishers will let authors work in the tool of their choice, provided that the end result is in a format they can work with. The books I've been involved with were edited in Emacs, Vim, and presumably similar editors; others I'm told are done in Word, other word processors, other text editors, and other desktop publishing applications.
A good source of info on this question might be the colophon page in the back of many reference books. A lot of the O'Reilly books cite FrameMaker and Quark, but these may come up later in the production process than the authorship stage, and I'm assuming that it isn't as important for you to know the minutae of how a manuscript gets typeset and printed -- at least at this point.
(4) what seems to be the average pay?
I'm working for a non-profit, so you may not want my opinion on this one:-)
----
Another good source of material would be the so you want to write for us section on O'Reilly's site. Whether or not you intend to actually write for them, it's a good overview of things to be aware of. Other publishers probably have similar documents, and being familiar with this kind of material can't hurt you whether you're planning to be a book author or if you intend to do in-house documentation for some company.
But isn't the shell case-sensitive & preserving already? Hasn't it been that way since the first versions of OSX came out? We're not talking about some magical otherworldly shell here -- it's just tcsh or bash. They can be customized a bit, but the behavior isn't ever going to be wildly out of step with what they can do on Linux or Solaris or Cygwin or what have you.
Anyway, I'm actually agnostic on the question of whether case should be relevant. It's just not a big deal to me: though I can appreciate the argument for & against a case sensitive shell, I just can't make myself care about which approach is "correct". But what I don't like is when case is handled inconsistently.
On Linux or *nix, Case Matters, and I can deal with that.
On Windows, case basically Doesn't Matter, and I can deal with that too.
On the Mac, case can be ignored when you're working at the Aqua level, but becomes significant in the shell. That's annoying.
What I like about a case insensitive shell for the Mac is that it'll behave the same way that the GUI behaves, which seems like the Right Approach to me.
Thanks, that did it. Apparently set doesn't change environment settings unless it's part of shell initialization. Or something. Anyhow, it works now, so thanks everyone for the <aol/>'s:-)
More importantly, it doesn't seem to work. I've added this to my ~/.inputrc, and have also tried the "set..." command directly from a bash shell, but the same case-sensitive behavior is happening either way.
Go back to my original example: if I type "ls ~/m<TAB>" under tcsh with case insensitivity enabled, the shell will offer to complete with either of "Music" or "mail" (or anything else beginning with 'M' or 'm').
Under bash, the case seems to be relevant even with this directive in effect: if I hit "ls ~/m<TAB>" under bash, the shell automatically expands that to "ls ~/mail/".
That's not the same thing.
I'd be happy to be corrected, but this command doesn't appear to work on the bash that comes with OSX 10.2.
% ls -1/usr/bin/*emacs* /usr/bin/emacs /usr/bin/emacs-21.1 /usr/bin/emacsclient
Funny troll, but emacs is part of the default install.
Caveat: it's possible that emacs is part of the developer's tools rather than a base OSX installation. I don't think that matters though: if you're looking for a "real Unix", then you're going to want a C compiler and all the rest anyway, so you're going to check off the button for "install BSD subsystem" at system install time and you're going to install the developer's tools immediately after you first log in to the system. So whether Emacs was available 0 minutes or 2 minutes after the first login, I still would call that part of a complete operating system, and saying that it's not available is just trolling.
I have my tcsh environment set up to do case-insensitive tab-completion.
% cd ~/m<TAB>
Music/ mail/
% cd ~/mu<TAB>
% cd ~/Music
This is a wonderful feature, especially when working on a case-preserving-yet-insensitive filesystem like HFS+.
I also have my tcsh shell set up to use a built-in spell checker. If I try to run a command & have a typo, the shell will attempt to fix it for me:
% greb foo ~/mail/sent-mail
CORRECT>grep foo ~/mail/sent-mail (y|n|e|a)?
This one doesn't always save me -- one of my common typos is to repeat the 'd' when changing directory, thus:
% cdd ~/Desktop/
CORRECT>dd ~/Desktop/ (y|n|e|a)?
But it's enough of a win that I wouldn't want to go back to an interactive shell that doesn't have such a feature.
Whenever I'm trying to do anything complex, I tend to drop into a bash subshell, but for 90% of interactive work I find that tcsh can do about everything bash can, and has a lot of interesting enhancements that AFAIK bash doesn't. Please feel free to correct me if that's not true, and bash can now do such things.
(Also, another nice thing about being comfortable in an alternative shell, aside from being able to work productively when dropped on a machine that maybe doesn't have a wide variety of shells, is the built in security factor. It has been long observed that using an unusual keyboard or pointing device is an excellent (if mild) way to discourage people from messing around with your computer when you're away from your desk. Using an unusual command shell can have the same mild deterrance effect: it may not keep your Linux-loving neighbor from messing around in a login session you forgot to close, but it might annoy him enough to get it to get bored & go away pretty quickly:-)
Scary thought: in the sixties we had the spagetti western, when for budget reasons "American" westerns were filmed in Italy. Could the oughts (or whatever this decade is called) end up having the curry scifi?
In the spagetti westerns, Italian actors were passed off as Mexicans. I wonder if any director today would dare to do the same thing in India...
In my opinion, the two most interesting modern masters of special effects, by a wide margin, are David Fincher and Jean-Pierre Jeunet.
Fincher is probably known to most Slashdot readers as the director of Fight Club, Se7en, and Panic Room, among others.
Jeunet is a French director, and wouldn't be as well known if not for the fact that Amelie was such a big hit a couple of years ago. In addition to that movie, he's also the director or co-director of City of Lost Children and Delicatessen.
(Interestingly, it turns out that Fincher and Jeunet also did the last two Alien movies, Alien3 and Alien: Resurrection. Neither reviewed very well, but both directors have gone on to establish pretty good reputations; it would be interesting to go back & watch them in comparison to their more recent work. In any case, I haven't seen these two movies, and they're not why I choose them as among my favorite modern filmmakers:-)
---
In any case, the thing I love about these guys is that, unlike a company like Pixar or a director like (say) James Cameron, these guys have digital special effects so ingrained into the way they make movies that it's no more of a gimmick than, say, choosing a camera lens of film stock to work with. Their movies are for the most part not gratuitous special effects extravaganzas, full of the standard pyrotechnics, monsters, and other gimmicks that are the hallmark of the standard,
standardboringeffects
fare. (Okay, maybe trolling just a little in that last bit...:-)
Just to pick a few random examples off the top of my head:
In "Amelie", almost the whole movie is washed over with a greenish-yellow tint. The first impression this gives may be a sense of the old sepia-toned movies & photographed, but that's not right: sepia tone is tan colored, not green or yellow. Jeunet got the effect by digitally pushing the color palatte in post-production so that, like the choice of soundtrack music, the tint of the film would help set the mood. Very subtle.
In "Panic Room", Fincher does of a series of tracking shots that would be impossible to do with a physical camera. One of these shots has the camera make a perfectly straight zoom from one end of the apartment to the other, going smoothly over furniture, under cabinets, and through the handle of a coffee pot. In another shot, the camera zooms through a keyhole to shows what's going on in the next room, and in yet another shot the camera goes in through a ventilation grate, down the duct, and out another grate in a different room. These camera shots are only possible because the coffee pot was never there, the keyhole was either not there or was part of a carefully done jump-cut, and the ventilation shot is all cartoon, seamlessly blended into the rest of the action.
In "City of Lost Children" -- which is a really wonderful movie by the way, like a weird, beautiful 21st century fairy tale -- one of the characters is a hitman who's weapon of choice is a trained flea assassin: as he plays his music, we see the flea leaping down the street, finding its quarry, jumping on the scalp, and injecting a poison among the hair follicles on the skull. All of this is done from the flea's point of view: those hair follicles loom as large as oaks. But there's little gratuituous about it: if you want to have a flea
It's just like driving on the right hand side of the road. It's more dangerous when shit happens, because nine times out of ten, you'll pull to the left - into oncomming traffic. Driving on the left hand side of the road fixes this, as you'll be pulling off the road. It's just that pretty much everyone is used to driving on the right hand side of the road and changing that is not going to go over well with the general public.
Eh? Why do you figure that people would pull to the left in an emergency? Can you cite research to support this? Does it have something to do with typical people (right-handers) using the typical dominant hand (the, err, right hand) to push the steering whell, and so cause the car to go left? If so, how would lefties like myself be expected to react -- by pulling to the right, away from traffic?
Another example is how you open a door. Here in Denmark almost all doors open inwards, which is extremely stupid in an emergency situation, because in a panic and/or stampede you'll be unable to open the door. In most public buildings the doors open outwards for safety reasons, but it's a pain in the ass to get used to, when you're not dealing with automated doors.
Here in the USA, the rule is similar, but possibly simpler: private dwellings open inward, public buildings open outward. The only exception is if a building has dedicated "in" and "out" doors, in which case the "in" doors swing in, and the "out" doors swing out. (Private homes basically never have in/out doors, so the division doesn't come up on that side.) With things working this way, if there's an emergency in a home, emergency personnel can storm in efficiently, and you typically don't have to worry about a stampede of people leaving a private home all at once, even if there's a fire. (If a fire broke out when everyone was sleeping, which is the case I think these rules were designed for, getting emergency personnel in quickly is more important than allowing a "stampede" of residents to come out.)
The decision about which doors to build which way makes sense, if you think about it. I'm not sure if the arrangements are quite the same in Denmark, but it doesn't sound like it's completely out of step with this organization.
Actually, as at least one other person has noted,
the correct way to do it would not be with simplistic "yes/no/cancel" dialogs, but with verbs. This is part of Apple's UI guidelines for the Aqua/OSX interface, and one of the commenters below notes that apparently this is a rule for Gnome as well (if, apparently, and ignored one).
Think about it, which is clearer --
Positive / negative assertions:
Would you like to quit without saving?
[YES] [NO] [CANCEL]
Verbs:
Would you like to quit without saving?
[QUIT] [SAVE FIRST] [DON'T QUIT]
Can you even parse out how "no" and "cancel" are different, or what would be the expected behavior if you chose one? Usually you end up seeing silly hints such as this:
Would you like to quit without saving? Hit NO to save first, hit CANCEL to not quit the program.
[YES] [NO] [CANCEL]
Note to UI designers: if you have to add explanatory footnotes to your dialogs, your dialogs are broken.
You can argue all your want about the sequence of the buttons. Some of the people responding have alluded to UI research suggesting that "NO" "YES" is more intuitive for people than "YES" "NO", but I'm not familiar with that research so I won't get into it. I do know, however, that people are very good at unambiguously interpreting what simple verbs mean, and don't have to think through the consequences of a simple "do this" or "do that". On the other hand, figuring out what "yes, no, maybe" in response to a seemingly simple question, like the one above, can be annoyingly ambiguous. Quit making this mistake!
Yes/No/Cancel may be the UI model that Windows is stuck with, but there's still enough wiggle room for Gnome & KDE to avoid that trap. I hope that they manage to do so. Don't you agree?
I really doubt that a company that current has more than 90% market share, and focuses it's products on 90% of the populace are going to worry about an obscure feature such as regular expressions that only 1% of the populace uses.
Not that I disagree with you, but there is precedent for this at Microsoft.
There was an interesting interview a couple of years back -- I apologize for not googling for a URL, but it's been too long and I remember it too vaguely -- where one of the project managers for Microsoft Office acknowledged that the suite is, as many people accuse, bloated with features, 90% of which the average user never takes advantage of.
Of course that's a problem, and they were willing to try to fix it. The problem was, they did some user testing, and learned a curious thing: while pretty much all users felt that a suite with 10% of the functionality would meet their needs, every user had a different idea about what 10% should be kept & which 90% should go.
It turned out that, as bloated as Office is, there was some portion of the user population interested in each part of the available functionality, and that would have been unhappy (possibly unhappy enough to seek out an alternative product) if that functionality was removed.
Purging the suite would have been a bigger problem than the bloat itself.
The solution that they came up with was a more modular installer, first seen (as far as I can recall) with Win2000/Office2000, where the user could select which subsystems to install, which to permanently ignore, and which to allow to be installed on demand. [Ironically, this modular installer would be a perfect tool for the "thousands of versions of Windows" canard that MS execs started crying about when the government threatened to enforce the anti-trust decision; thankfully for MS they were able to afford an administration that would let them go about their business, illegal or not.]
---
But anyway, to go back to the point: yes, things like a regex engine would be of interest to only a small subset of the Windows userbase, but it wouldn't be the first time that a feature made it into the system that a similar small slice of the userbase would be interested in. (As another commenter noted, a regex engine would be at least as popular as, say, MIDI support.)
Personally, I think Microsoft is heading in exactly this direction -- or at least, parts of the heterogeneous behemoth that is Microsoft are collectively staggering in this direction. As was noted in articles here last year, and as confirmed by ongoing job postings on Microsoft's Indian Development Center, Microsoft is studying which aspects of Linux and the typical Linux command shell (bash, tcsh, ksh etc) appeal most to users, and seems to be working on bringing these ideas into a future version of Windows. Consider this quote from the above linked MS-India jobs site:
The Microsoft Next Generation Shell Team is designing and developing a new command line scripting environment from the ground up. The new shell and utilities, based on the.NET Frameworks, will provide a very rich object-based mechanism for managing system properties. To be delivered in the next release of Windows, it will include the attributes of shells (e.g. aliases, job control, command substitution, pipelines, regular expressions, transparent remote execution) plus rich features based on Windows and.NET (e.g. command discovery via.NET reflection API's, object-based properties/methods, 1:many server scripting, pervasive auto-complete).
Microsoft realizes that a big reason for OSX's popularity is that it's a soft creamy interface wrapped around a tasty, crunchy tcsh shell, and they want to bring some of that appeal to
For an article that already had 50 or so comments scored as +5, I wasn't too worried about the visibility of my puny little server. Rather, I really did just want to be able to have a permanent link to the image, in case the original site or Google removed it in time.
But now that you ask, as of this writing, there's only 47 hits on the image -- and a couple of those were from me testing to make sure the link worked. You did motivate me to come up with a tool to check on how often my images are being served though, so thanks for that. It turns out that this image is only the 40th most frequently served, but it is tied for the most popular "non-furniture" image (that is, something other than the icons on Apache directory listings, etc.)
It'll be interesting (to me anyway) if the image continues to get traffic...
The introduction (a large chunk of which is available via Amazon)
Ahh, nevermind that, the whole thing is available, and in plain HTML at that. Here's the intro to the original, and here's the intro to the 25th anniversary edition.
I always shudder at that point in the story when, yet again, I realize that the story is a tale of a quest performed by the bold little people of the Shire.
You went to one of those schools that skips over the difference between fiction & reality, didn't you?
This twist is hardly new, and considering all the pseudo-myths that Tolkein crammed into his boredom-opus, I'd assume that anyone that read it saw it coming if they were thinking: of course Tolkein would have wanted to bring this pseudo-mythology to a higher level by wrapping the whole series under the cloak of pseudo-history. Quelle surprise.
My favorite "I didn't write this, I just found it" is the novel version of "The Princess Bride", or as author William Goldman called it, The Princess Bride: S. Morgenstern's Classic Tale of True Love and High Adventure (The 'Good Parts' Version). The introduction (a large chunk of which is available via Amazon) writes about how when he was a kid his Florinese father used to read him the history by S. Morgenstern, and all his adult life he wanted to go back & reread his favorite childhood bedtime story but could never seem to find a copy. Eventually, after a long, difficult search, he turned up a copy in a little Manhattan rare books shop, brought it home, read it,...and hated it. It turned out, he realized then, that his father had been reading him the "good parts" version of S. Morganstern's tome, and so he decided to republish that as the novel and, later movie: "The Princess Bride."
I've long thought that Goldman was making fun of Tolkein here;)
You seem to forget about the EXTREME contraction of the time lapse between Bilbo's farewell party, and the first appearance of the Nazgul.
Like the Phish & Grateful Dead concerts I went to because everyone swore up & down how wonderful they are -- they are not wonderful, and those friends were damned dirty liars -- I find that the more I can forget about Tolkein's books, the happier I am:-)
Nonetheless...
In the movie, it almost seems to be the next day -- in the book, years pass [....] But you are right in that the main action occurs in one year [....]
I appear to have caught you in a contradiction here, but then...
[....], namely 3018TA. (The Hobbit takes place in 2941TA. Of course both The Hobbit and LOTR actually end much later, but let's keep our attention on the main action only.)
...after this you went off the deep end completely, and I'm not going to follow you down to those depths. Sorry:-)
Please note that I try to be charitible, but long & boring just isn't my thing. I absolutely hated "The Godfather" trilogy, in spite of how wonderful everyone says they are, but then I really like "Lawrence of Arabia" and "Seven Samurai". I would have liked "Heat" more if Michael Mann had been brave enough to admit that the movie would have been much tighter if he cut out at least 1/3 of it. The strength of "Heat" was that it was a very well done action movie (an oxymoron, in most cases) wrapped up in a long, boring soap opera.
The strength of "Lawrence" and "Samurai" is there is no melodramatics bogging down the story. The flaw in heat is that the story is drowned in a tub of soap opera. The fatal flaw of "Godfather" and "LOTR" is that the melodramatics is the story.
Some people love that. I'm not one of them. To each their own...
It looks like the staff at E-Commerce Times have come up with a wonderful new logo for SCO articles, as scaled down to icon size by Google News (and I've stashed a backup of, just in case).
It shouldn't be a Caldera logo anymore anyway. I think a picture of someone shooting themself in the foot is much more apropos:-)
Three years? Surely you're joking. The plot arc of both "LOTR" and "The Hobbit" is one calendar year: "The Hobbit" begins one spring & finishes the following spring, while LOTR begins & ends in the fall. By stretching it out over 3 years, you're effectively making it three times slower than molasses. Sounds like a blast...:-)
All you need is to imagine a Beowulf cluster of...
Waitaminute!
You actually could think of this as a Beowulf cluster! The main twist is that each node in the network is being used interactively, rather than just acting as a slave that churns away on data chunks autonomously.
You don't state what kind of systems your colleagues are using, but if you're using Macs, then Rendezvous mDNS networking can take care of the "plumbing" part of the problem for you -- everyone can instantly start publishing their shared resources, and the trick then is to just figure out a way to search who has what content.
The search function could be done from a machine set up to automatically spider everyone's content & basically set up a little in-house search engine, with links back to each user's version of "http://johndoe.local/weather/data/2003/08/21/1530 _nws" or whatever.
If you're not running Macs, well that's a problem on several levels:), but the mDNS spec is an open standard, and it is IIRC available as an Apache module. There's mod_rendezvous, but it seems to have stalled with an OSX version only -- porting to Linux shouldn't be bad but is left as an exercise for the reader. There also seems to be the Net::MDNS::Server & Net::MDNS::Client Perl modules on CPAN, but they seem to have been born & stalled in the same week back in June. Not sure what that means.
In any case, if you can set up a spontaneous mDNS network, then that would solve the problem of getting every node on your network to be able to advertise what resources are available to other nodes on the network. The step after that is to set up a search interface, and that's really a solved problem -- any Perl hacker comfortable with LWP should be able to whip up a reasonably good search mechanism using &/or extending existing tools.
If you manage to get this to work, it would be interesting to read a writeup of how the lego parts end up being assembled:-)
They need to inspect the header and only send a response when they can have some reasonable confidence that it is in fact from a user. If the hosts used to send the mail don't match the email address, it probably didn't come from that person.
But that doesn't work either. I use a pobox.com mail forwarding address. My outgoing mail never has their servers in the headers, but it is a legit "From:" line, and mail delivered there does make it back to me.
On the other hand, for the last company I worked at there were a number of mail aliases for directing mail to different teams or departments. Some of these were easy to guess, others were pretty obscure. None of them were, as far as I know, ever used as the From: line on an outgoing email: of the handful of people that knew how to munge their mail headers to spoof this, I can't picture anyone bothering to do this.
Nonetheless, all of these mail aliases got a steady stream of spam, and as far as I could tell, they must have been in somebody's Outlook address book, because we'd regularly get "helpful" messages like:
Dear systemadministratorteam, A message you sent has been determined to have the WhatEver.F virus. Please update your virus scanners. Thank you.
Signed, The SuperExpensive Mail Scanner at Whatsamatta U
But the thing is, we weren't an Outlook company, so [a] there was no question that it was someone internal that had the virus, and [b] there was almost no possibility that one of these internal addresses should have been out in the public unless an employee deliberately forwarded something (which, I suppose, must be exactly what happened).
In any case, the point is, spoofing the From: line is trivial if you have the right tools, and determining if a spoofed address is legit is impossible without manual verification by sending a message to the recipient. My pobox.com address is legit, but may not appear to be so; allstaff@widgets.com is probably never legit, but it doesn't look any different than the pobox.com address.
Moreover, covering your tracks is easy -- just choose a random From: line and tack on some random Received: headers to make it appear as if the message really did come from where it claims. Such a message might be detectable by a human scanning the headers, but the whole "store & forward" architecture of the internet mail system demands that each receiving server has to trust what another host claims about prior headers -- so the whole system is vulnerable to anybody running a maliciously configured server.
So to give my opinion on the original article's question, no, I don't think auto-responses for mail viruses make sense anymore. The current wave has generated at least as much bandwidth waste from the "helpful" replies as from the virus itself -- as anyone on a gnu.org mailing list (to pick a random example) would have noticed lately. (Really, of all people to be feeling the side effects of a Windows issue -- GNU.org?)
It might arguably be okay to send mail to abuse@..., etc, but even then, [a] the spoofing problem is still there, so you don't know which of the Received: lines is legit, and [b] contacting these addresses won't necessarily do any good. Most of the people propagating the current worm seem to be home users, and so are connected via one or another ISP; what ISP is going to take on the tech support expense of walking all their users through how to patch their systems?
Few, if any have the resources to do this.
For better or worse, the only solution I see is mandatory updates from the software vendor. As long as people continue to use Outlook but refuse to update it, the proposal from Microsoft to possibly force home users to install patches is the only solution I can think of that seems to have any chance of helping. It'll be interesting to see if & how they do that.
Slashdot Mirror
Say it again! Huh!
In other words, "I would not know anything about good human factors UI design if it bit me on the nose. And why are you gesturing at my nose like that? Cut it out!"
A properly restricted UI will not restrict what the user is capable of doing with the system. Quit the contrary: it will lock in best practices that encourage efficient habits in the user, while allowing enough flexibilty to approach a task in different ways if they choose.
I'm not saying that OSX is the perfect GUI -- far from it. Nor am I saying that there is one right way to define an interface -- there isn't.
But there is a proper balance to be struck between what an interface allows and what it restricts. An interface is not better just because you have absolute control over how widgets are displayed -- in fact, this is often an invitation to greatly de-optimize the quality of the interface, even while superficially "empowering" the user.
Don't argue with me though, I just dabble in this stuff. Pick up a good introductory user interface / human factors textbook, skim over the first few chapters, and then think carefully about what you're sticking up for here. While you're right that not all humans use things the same way, you also miss that there are some approaches that are simply wrong for almost everyone, and a good interface will protect the user from making such misconfigurations.
Put another way, if freeform, user selected UI is such a great thing, then how come we see it in no other industry? Granted, software is more configurable than.... well just about anything. But still, if there were a market for people that wanted, say, their car's steering wheel in the trunk -- because that would be more 'leet -- then the auto manufacturers would have found a way to oblige. No, they allow some mild degree of customization -- all the damn souped up Hondas with the obnoxious growling mufflers & stereo systems -- but they draw the line at changes that would actually impair the user's ability to operate the vehicle: the steering wheel is never in the trunk, no matter how "k3w1" that would be.
This is a good thing. As are computer UIs witih a similar sense of restraint.
In other words, "Don't bother FIXING IT you damned slobs, SELL IT!"
Choice is nice and all, but as Perl well demonstrates, just because there's more than one way to do it doesn't mean that 90% of those ways aren't wrong. "Choice" and "correctness" have very little to do with each other, as anyone even moderately well read in UI research could tell you.
The really great thing about OSX's Aqua interface is that it restricts choice. At first this can feel constricting, but once you give in & go with the flow, you realize that the defaults are actually pretty efficient, and more importantly you're not wasting your time fiddling around with all the settings: we've all got more important things to do than hand-craft the bestest wickedest GUI theme evahhh!??!?!
Sadly, many Linux (esp Enlightenment) users don't seem to agree with that. That's their choice... :-)
I'm currently freelancing as an editor for the official manual on a certain general code compiler that you may have used before. It's not exactly a writing job, but because the book was written by a committee a big part of the work involves rewriting sections to make sure it doesn't read like something written by a committee.
I think this work & some other random writing I've done gives me a little bit of room to reply here.
The work I've done so far has been very well received by the members of this general code compiler's list. Apparently, no one has sat down and attempted to do a cleanup of the text in years, and it shows. Parts of the text were written by people for whom English isn't their strongest language, and most of it was written by people who are more talented as programmers than in explaining complex material to a lay audience. Moreover, the writing style changes drastically from section to section, and even from paragraph to paragraph. Trying to follow such a twisted text would be difficult even if the material wasn't so advanced, so if anyone steps forward and offers to make this material more accessible to people, it seems like that person is likely to be well received.
What do you want to know? I could go into detail, but the work I've done to date has mostly been editing, not first-hand writing. It's a related task, but not identical. Basically it means looking over the manuscript, making sure that the text is understandable, consistent, and adheres to the house style guidelines. In cases where the text needs to be rewritten, I have to be careful to be sure that the edited text still expresses the same intent that the original version did (and sometimes, that means muddling through what the original intent was in the first place). In cases where the meaning is especially ambiguous, it has meant consulting with experts on the topic, either over the phone, by personal email, or by asking on relevant mailing lists. It has been a lot of work. Much more than I anticipated when I started (but then, apparently no one realized how messy the text was, how out of date in parts, how ambiguous in others...)
Well, this book is formatted in Texinfo, but that's probably a quirk of this organization. The other book I was involved with was written in Perl's POD documentation format, but again that may have just been the whim of the author's as much as anything else.
I think, more generally, that most pubishers will let authors work in the tool of their choice, provided that the end result is in a format they can work with. The books I've been involved with were edited in Emacs, Vim, and presumably similar editors; others I'm told are done in Word, other word processors, other text editors, and other desktop publishing applications.
A good source of info on this question might be the colophon page in the back of many reference books. A lot of the O'Reilly books cite FrameMaker and Quark, but these may come up later in the production process than the authorship stage, and I'm assuming that it isn't as important for you to know the minutae of how a manuscript gets typeset and printed -- at least at this point.
I'm working for a non-profit, so you may not want my opinion on this one :-)
----
Another good source of material would be the so you want to write for us section on O'Reilly's site. Whether or not you intend to actually write for them, it's a good overview of things to be aware of. Other publishers probably have similar documents, and being familiar with this kind of material can't hurt you whether you're planning to be a book author or if you intend to do in-house documentation for some company.
But isn't the shell case-sensitive & preserving already? Hasn't it been that way since the first versions of OSX came out? We're not talking about some magical otherworldly shell here -- it's just tcsh or bash. They can be customized a bit, but the behavior isn't ever going to be wildly out of step with what they can do on Linux or Solaris or Cygwin or what have you.
Anyway, I'm actually agnostic on the question of whether case should be relevant. It's just not a big deal to me: though I can appreciate the argument for & against a case sensitive shell, I just can't make myself care about which approach is "correct". But what I don't like is when case is handled inconsistently.
On Linux or *nix, Case Matters, and I can deal with that.
On Windows, case basically Doesn't Matter, and I can deal with that too.
On the Mac, case can be ignored when you're working at the Aqua level, but becomes significant in the shell. That's annoying.
What I like about a case insensitive shell for the Mac is that it'll behave the same way that the GUI behaves, which seems like the Right Approach to me.
Thanks, that did it. Apparently set doesn't change environment settings unless it's part of shell initialization. Or something. Anyhow, it works now, so thanks everyone for the <aol />'s :-)
More importantly, it doesn't seem to work. I've added this to my ~/.inputrc, and have also tried the "set..." command directly from a bash shell, but the same case-sensitive behavior is happening either way.
Go back to my original example: if I type "ls ~/m<TAB> " under tcsh with case insensitivity enabled, the shell will offer to complete with either of "Music" or "mail" (or anything else beginning with 'M' or 'm').
Under bash, the case seems to be relevant even with this directive in effect: if I hit "ls ~/m<TAB> " under bash, the shell automatically expands that to "ls ~/mail/".
That's not the same thing.
I'd be happy to be corrected, but this command doesn't appear to work on the bash that comes with OSX 10.2.
Or skip the "here's how to use a text editor" steps entirely:
The file redirection operators are your friend, no matter what shell dialect you prefer. :)
Come again?
Funny troll, but emacs is part of the default install.
Caveat: it's possible that emacs is part of the developer's tools rather than a base OSX installation. I don't think that matters though: if you're looking for a "real Unix", then you're going to want a C compiler and all the rest anyway, so you're going to check off the button for "install BSD subsystem" at system install time and you're going to install the developer's tools immediately after you first log in to the system. So whether Emacs was available 0 minutes or 2 minutes after the first login, I still would call that part of a complete operating system, and saying that it's not available is just trolling.
But I like working in tcsh!
This is a wonderful feature, especially when working on a case-preserving-yet-insensitive filesystem like HFS+.
This one doesn't always save me -- one of my common typos is to repeat the 'd' when changing directory, thus:
But it's enough of a win that I wouldn't want to go back to an interactive shell that doesn't have such a feature.
Whenever I'm trying to do anything complex, I tend to drop into a bash subshell, but for 90% of interactive work I find that tcsh can do about everything bash can, and has a lot of interesting enhancements that AFAIK bash doesn't. Please feel free to correct me if that's not true, and bash can now do such things.
(Also, another nice thing about being comfortable in an alternative shell, aside from being able to work productively when dropped on a machine that maybe doesn't have a wide variety of shells, is the built in security factor. It has been long observed that using an unusual keyboard or pointing device is an excellent (if mild) way to discourage people from messing around with your computer when you're away from your desk. Using an unusual command shell can have the same mild deterrance effect: it may not keep your Linux-loving neighbor from messing around in a login session you forgot to close, but it might annoy him enough to get it to get bored & go away pretty quickly :-)
Scary thought: in the sixties we had the spagetti western, when for budget reasons "American" westerns were filmed in Italy. Could the oughts (or whatever this decade is called) end up having the curry scifi?
In the spagetti westerns, Italian actors were passed off as Mexicans. I wonder if any director today would dare to do the same thing in India...
In my opinion, the two most interesting modern masters of special effects, by a wide margin, are David Fincher and Jean-Pierre Jeunet.
Fincher is probably known to most Slashdot readers as the director of Fight Club, Se7en, and Panic Room, among others.
Jeunet is a French director, and wouldn't be as well known if not for the fact that Amelie was such a big hit a couple of years ago. In addition to that movie, he's also the director or co-director of City of Lost Children and Delicatessen.
(Interestingly, it turns out that Fincher and Jeunet also did the last two Alien movies, Alien3 and Alien: Resurrection. Neither reviewed very well, but both directors have gone on to establish pretty good reputations; it would be interesting to go back & watch them in comparison to their more recent work. In any case, I haven't seen these two movies, and they're not why I choose them as among my favorite modern filmmakers :-)
---
In any case, the thing I love about these guys is that, unlike a company like Pixar or a director like (say) James Cameron, these guys have digital special effects so ingrained into the way they make movies that it's no more of a gimmick than, say, choosing a camera lens of film stock to work with. Their movies are for the most part not gratuitous special effects extravaganzas, full of the standard pyrotechnics, monsters, and other gimmicks that are the hallmark of the standard, standard boring effects fare. (Okay, maybe trolling just a little in that last bit... :-)
Just to pick a few random examples off the top of my head:
Eh? Why do you figure that people would pull to the left in an emergency? Can you cite research to support this? Does it have something to do with typical people (right-handers) using the typical dominant hand (the, err, right hand) to push the steering whell, and so cause the car to go left? If so, how would lefties like myself be expected to react -- by pulling to the right, away from traffic?
Here in the USA, the rule is similar, but possibly simpler: private dwellings open inward, public buildings open outward. The only exception is if a building has dedicated "in" and "out" doors, in which case the "in" doors swing in, and the "out" doors swing out. (Private homes basically never have in/out doors, so the division doesn't come up on that side.) With things working this way, if there's an emergency in a home, emergency personnel can storm in efficiently, and you typically don't have to worry about a stampede of people leaving a private home all at once, even if there's a fire. (If a fire broke out when everyone was sleeping, which is the case I think these rules were designed for, getting emergency personnel in quickly is more important than allowing a "stampede" of residents to come out.)
The decision about which doors to build which way makes sense, if you think about it. I'm not sure if the arrangements are quite the same in Denmark, but it doesn't sound like it's completely out of step with this organization.
Actually, as at least one other person has noted, the correct way to do it would not be with simplistic "yes/no/cancel" dialogs, but with verbs. This is part of Apple's UI guidelines for the Aqua/OSX interface, and one of the commenters below notes that apparently this is a rule for Gnome as well (if, apparently, and ignored one).
Think about it, which is clearer --
Can you even parse out how "no" and "cancel" are different, or what would be the expected behavior if you chose one? Usually you end up seeing silly hints such as this:
Note to UI designers: if you have to add explanatory footnotes to your dialogs, your dialogs are broken .
You can argue all your want about the sequence of the buttons. Some of the people responding have alluded to UI research suggesting that "NO" "YES" is more intuitive for people than "YES" "NO", but I'm not familiar with that research so I won't get into it. I do know, however, that people are very good at unambiguously interpreting what simple verbs mean, and don't have to think through the consequences of a simple "do this" or "do that". On the other hand, figuring out what "yes, no, maybe" in response to a seemingly simple question, like the one above, can be annoyingly ambiguous. Quit making this mistake!
Yes/No/Cancel may be the UI model that Windows is stuck with, but there's still enough wiggle room for Gnome & KDE to avoid that trap. I hope that they manage to do so. Don't you agree?
Not that I disagree with you, but there is precedent for this at Microsoft.
There was an interesting interview a couple of years back -- I apologize for not googling for a URL, but it's been too long and I remember it too vaguely -- where one of the project managers for Microsoft Office acknowledged that the suite is, as many people accuse, bloated with features, 90% of which the average user never takes advantage of.
Of course that's a problem, and they were willing to try to fix it. The problem was, they did some user testing, and learned a curious thing: while pretty much all users felt that a suite with 10% of the functionality would meet their needs, every user had a different idea about what 10% should be kept & which 90% should go.
It turned out that, as bloated as Office is, there was some portion of the user population interested in each part of the available functionality, and that would have been unhappy (possibly unhappy enough to seek out an alternative product) if that functionality was removed.
Purging the suite would have been a bigger problem than the bloat itself.
The solution that they came up with was a more modular installer, first seen (as far as I can recall) with Win2000/Office2000, where the user could select which subsystems to install, which to permanently ignore, and which to allow to be installed on demand. [Ironically, this modular installer would be a perfect tool for the "thousands of versions of Windows" canard that MS execs started crying about when the government threatened to enforce the anti-trust decision; thankfully for MS they were able to afford an administration that would let them go about their business, illegal or not.]
---
But anyway, to go back to the point: yes, things like a regex engine would be of interest to only a small subset of the Windows userbase, but it wouldn't be the first time that a feature made it into the system that a similar small slice of the userbase would be interested in. (As another commenter noted, a regex engine would be at least as popular as, say, MIDI support.)
Personally, I think Microsoft is heading in exactly this direction -- or at least, parts of the heterogeneous behemoth that is Microsoft are collectively staggering in this direction. As was noted in articles here last year, and as confirmed by ongoing job postings on Microsoft's Indian Development Center, Microsoft is studying which aspects of Linux and the typical Linux command shell (bash, tcsh, ksh etc) appeal most to users, and seems to be working on bringing these ideas into a future version of Windows. Consider this quote from the above linked MS-India jobs site:
Microsoft realizes that a big reason for OSX's popularity is that it's a soft creamy interface wrapped around a tasty, crunchy tcsh shell, and they want to bring some of that appeal to
For an article that already had 50 or so comments scored as +5, I wasn't too worried about the visibility of my puny little server. Rather, I really did just want to be able to have a permanent link to the image, in case the original site or Google removed it in time.
But now that you ask, as of this writing, there's only 47 hits on the image -- and a couple of those were from me testing to make sure the link worked. You did motivate me to come up with a tool to check on how often my images are being served though, so thanks for that. It turns out that this image is only the 40th most frequently served, but it is tied for the most popular "non-furniture" image (that is, something other than the icons on Apache directory listings, etc.)
It'll be interesting (to me anyway) if the image continues to get traffic...
Ahh, nevermind that, the whole thing is available, and in plain HTML at that. Here's the intro to the original, and here's the intro to the 25th anniversary edition.
They're almost as entertaining as the PB itself :)
You went to one of those schools that skips over the difference between fiction & reality, didn't you?
This twist is hardly new, and considering all the pseudo-myths that Tolkein crammed into his boredom-opus, I'd assume that anyone that read it saw it coming if they were thinking: of course Tolkein would have wanted to bring this pseudo-mythology to a higher level by wrapping the whole series under the cloak of pseudo-history. Quelle surprise.
My favorite "I didn't write this, I just found it" is the novel version of "The Princess Bride", or as author William Goldman called it, The Princess Bride: S. Morgenstern's Classic Tale of True Love and High Adventure (The 'Good Parts' Version). The introduction (a large chunk of which is available via Amazon) writes about how when he was a kid his Florinese father used to read him the history by S. Morgenstern, and all his adult life he wanted to go back & reread his favorite childhood bedtime story but could never seem to find a copy. Eventually, after a long, difficult search, he turned up a copy in a little Manhattan rare books shop, brought it home, read it, ...and hated it. It turned out, he realized then, that his father had been reading him the "good parts" version of S. Morganstern's tome, and so he decided to republish that as the novel and, later movie: "The Princess Bride."
I've long thought that Goldman was making fun of Tolkein here ;)
Like the Phish & Grateful Dead concerts I went to because everyone swore up & down how wonderful they are -- they are not wonderful, and those friends were damned dirty liars -- I find that the more I can forget about Tolkein's books, the happier I am :-)
Nonetheless...
I appear to have caught you in a contradiction here, but then...
...after this you went off the deep end completely, and I'm not going to follow you down to those depths. Sorry :-)
Please note that I try to be charitible, but long & boring just isn't my thing. I absolutely hated "The Godfather" trilogy, in spite of how wonderful everyone says they are, but then I really like "Lawrence of Arabia" and "Seven Samurai". I would have liked "Heat" more if Michael Mann had been brave enough to admit that the movie would have been much tighter if he cut out at least 1/3 of it. The strength of "Heat" was that it was a very well done action movie (an oxymoron, in most cases) wrapped up in a long, boring soap opera.
The strength of "Lawrence" and "Samurai" is there is no melodramatics bogging down the story. The flaw in heat is that the story is drowned in a tub of soap opera. The fatal flaw of "Godfather" and "LOTR" is that the melodramatics is the story.
Some people love that. I'm not one of them. To each their own...
It shouldn't be a Caldera logo anymore anyway. I think a picture of someone shooting themself in the foot is much more apropos :-)
Three years? Surely you're joking. The plot arc of both "LOTR" and "The Hobbit" is one calendar year: "The Hobbit" begins one spring & finishes the following spring, while LOTR begins & ends in the fall. By stretching it out over 3 years, you're effectively making it three times slower than molasses. Sounds like a blast... :-)
Right -- fix a long, tedious movie by doing what? Watching the even longer, even more tedious version. SOUNDS FUN! :-)
All you need is to imagine a Beowulf cluster of...
Waitaminute!
You actually could think of this as a Beowulf cluster! The main twist is that each node in the network is being used interactively, rather than just acting as a slave that churns away on data chunks autonomously.
You don't state what kind of systems your colleagues are using, but if you're using Macs, then Rendezvous mDNS networking can take care of the "plumbing" part of the problem for you -- everyone can instantly start publishing their shared resources, and the trick then is to just figure out a way to search who has what content.
The search function could be done from a machine set up to automatically spider everyone's content & basically set up a little in-house search engine, with links back to each user's version of "http://johndoe.local/weather/data/2003/08/21/1530 _nws" or whatever.
If you're not running Macs, well that's a problem on several levels :), but the mDNS spec is an open standard, and it is IIRC available as an Apache module. There's mod_rendezvous , but it seems to have stalled with an OSX version only -- porting to Linux shouldn't be bad but is left as an exercise for the reader. There also seems to be the Net::MDNS::Server & Net::MDNS::Client Perl modules on CPAN, but they seem to have been born & stalled in the same week back in June. Not sure what that means.
In any case, if you can set up a spontaneous mDNS network, then that would solve the problem of getting every node on your network to be able to advertise what resources are available to other nodes on the network. The step after that is to set up a search interface, and that's really a solved problem -- any Perl hacker comfortable with LWP should be able to whip up a reasonably good search mechanism using &/or extending existing tools.
If you manage to get this to work, it would be interesting to read a writeup of how the lego parts end up being assembled :-)
But that doesn't work either. I use a pobox.com mail forwarding address. My outgoing mail never has their servers in the headers, but it is a legit "From:" line, and mail delivered there does make it back to me.
On the other hand, for the last company I worked at there were a number of mail aliases for directing mail to different teams or departments. Some of these were easy to guess, others were pretty obscure. None of them were, as far as I know, ever used as the From: line on an outgoing email: of the handful of people that knew how to munge their mail headers to spoof this, I can't picture anyone bothering to do this.
Nonetheless, all of these mail aliases got a steady stream of spam, and as far as I could tell, they must have been in somebody's Outlook address book, because we'd regularly get "helpful" messages like:
But the thing is, we weren't an Outlook company, so [a] there was no question that it was someone internal that had the virus, and [b] there was almost no possibility that one of these internal addresses should have been out in the public unless an employee deliberately forwarded something (which, I suppose, must be exactly what happened).
In any case, the point is, spoofing the From: line is trivial if you have the right tools, and determining if a spoofed address is legit is impossible without manual verification by sending a message to the recipient. My pobox.com address is legit, but may not appear to be so; allstaff@widgets.com is probably never legit, but it doesn't look any different than the pobox.com address.
Moreover, covering your tracks is easy -- just choose a random From: line and tack on some random Received: headers to make it appear as if the message really did come from where it claims. Such a message might be detectable by a human scanning the headers, but the whole "store & forward" architecture of the internet mail system demands that each receiving server has to trust what another host claims about prior headers -- so the whole system is vulnerable to anybody running a maliciously configured server.
So to give my opinion on the original article's question, no, I don't think auto-responses for mail viruses make sense anymore. The current wave has generated at least as much bandwidth waste from the "helpful" replies as from the virus itself -- as anyone on a gnu.org mailing list (to pick a random example) would have noticed lately. (Really, of all people to be feeling the side effects of a Windows issue -- GNU.org?)
It might arguably be okay to send mail to abuse@..., etc, but even then, [a] the spoofing problem is still there, so you don't know which of the Received: lines is legit, and [b] contacting these addresses won't necessarily do any good. Most of the people propagating the current worm seem to be home users, and so are connected via one or another ISP; what ISP is going to take on the tech support expense of walking all their users through how to patch their systems? Few, if any have the resources to do this.
For better or worse, the only solution I see is mandatory updates from the software vendor. As long as people continue to use Outlook but refuse to update it, the proposal from Microsoft to possibly force home users to install patches is the only solution I can think of that seems to have any chance of helping. It'll be interesting to see if & how they do that.