It's a WHOLE lot easier to code in *nix with BSD sockets than it is to code in Win32/MAPI.
That's why I was able to DOUBLE my hourly rate when doing server-side MAPI code in C, vs. what it had been doing generic tcp/ip apps code in *nix C.
Given that, why use MAPI? At the time, it was the only way to get to the Exchange message store. And some of those apps are still around, hence the issues with Exchange -> anything else migration. -- * Helen *
I think you missed your last dose of ritalin. Go take it. We'll wait.;-)
I did indeed write a compiler -- for an awful dialect of Pascal (ob/. tech content: I did this on the Pyramid OS-X platform, home of the broken ATT-semantic-based chgrp() syscall that didn't clear the sgid-bit as part of chgrp(), and thus allowed anyone to create a shell setgid to group-of-choice at any time).
As for posting the URL's for code I wrote 8-17 years ago: Not likely, sorry. -- * Helen *
A "super simple httpd for *BSD"? Why do that, when I've already written a load-balancing one -- a decade ago, kiddo.;-)
Besides, it'd be stupid to waste my time coding something that's already out there, unless I was doing it as an intellectual exercise to see if I could figure out how to do it. I prefer to write code that folks actually *WANT* -- and yes, in the mid/late 1980's, some of that which paid quite well, involved MAPI.
I first used vi in the early 1980's, wrote a compiler in C in the mid-80's and that load-balancing http server in the mid-90's. Let's see... taught UNIX security in the late-1980's, founded a ISP with a handful of Sparcstations and a T-1, was lead maintainer of the internals of a commercial (read: folks paid for it) RDBMS for a while. I just happen to know how to code well enough to be paid for it, on more than one platform.
There are many women whose technical limits are exceeded when talk goes beyond VB and SQL. I, however, am not one of them.
If you don't want to read any details about MS software, you'd do well to stay away from articles which seek to equivalence other packages to it.
Bzzzt, wrong answer! One more time: MAPI is NOT just a client-side technology.
I will say that server-side MAPI did have lots of brokenness back in its early days (circa mid-90's) -- things like server-side functions which displayed dialog boxes on the server and waited for someone to see them and press "OK" before the server process calling the MAPI function that errored would continue.
The point of MAPI is not just to make it easy for any client to send mail via a "common protocol" (did you mean API?). Another point is that a single client can select WHICH protocol to use, to send mail -- because it was developed back in the days before everyone decided SMTP/POP3/IMAP were the way to go. At least this is true of the versions of MAPI supplied with typical Exchange clients. (I believe Simple MAPI as supplied with vanilla Windows may be limited to God's Intended Email Protocols, SMTP/POP3/IMAP).
And being MAPI-free doesn't mean code is virus free, by any means. -- * Helen *
It depends which MAPI you're talking about. Most apps folks know about the client-side functionality in Simple MAPI.
There is another version, called Extended MAPI. This does indeed support many server-side functions, for the creation of "message store providers" and "transport providers" and other such things that are part of the underlying plumbing of Exchange. It's definitely not a client-side-only technology. -- * Helen *
It thinks so little of its users that it blocked all outbound access to non-Earthlink servers' port 25, without notice to users, a couple years ago.
Nevermind that some of us telecommuters NEEDED to be able to send mail to customers through our employers' servers (rather than through our local ISP's servers), of course.:-(
The employer ended up installing a second mail server on a high-numbered port for me to connect to, so that I wouldn't have to change ISP's. This only happened after a full day of troubleshooting -- over the same night that Earthlink messed with port blocking, my employer had tweaked its network security and email server config.
I understand they did it to provide a net.guardrail against spammers using open relays, but they'd make no exceptions even in the case of my employer sending them a note requesting that I be given access to port 25 on site mumble.com. Really tells me how much they think of their users. (They're more concerned about preventing their dumbie (dummy+newbie collection) users from ticking off the net, than about providing experienced users with the full access we expect.) -- * Helen *
Sun's Java license goes into great detail about what you may not do with the product. (Basically, they skirt the whole issue of liability by saying that you can't use java when reliability/proper functionality/etc. are a life and death issue.)
So if Microsoft is saying, "We're not going there; and if we do, boy, it'll cost you," they're not singing that different a song than Sun -- other then leaving open the possibility of pursuing the big dollars in the mission critical space. -- * Helen *
[ There are many variations of this. Here is one, which is shorter than others but has more of the feel of the "original" I remember from way back when... source: http://www.cirr.com/~barkley/jokes/realprog.html ]
Real Programmers...
Don't eat quiche. Real programmers don't even know how to spell quiche. They like Twinkies, Coke, and palate-scorching Szechwan food.
Don't write applications programs. They program right down to the bare metal. Applications programs are for dullards who can't do systems programming.
Don't comment their code. If it was hard to write, it should be hard to understand and even harder to modify.
Don't draw flowcharts. Flowcharts are, after all, the illiterate's form of documentation. Cavemen drew flowcharts; look how much it did for them.
Don't use COBOL. COBOL is for wimpy applications programmers.
Don't use FORTRAN. FORTRAN is for wimpy engineers who wear white socks, pipe stress freaks, and crystallography weenies. They get excited over finite state analysis and nuclear reactor simulations.
Don't use LOGO. In fact programmers use LOGO after puberty.
Don't use APL unless the whole program can be written on one line.
Don't use LISP. Only effeminate programmers use more parentheses than actual code.
Don't use Pascal, BLISS, ADA, or any of those sissy-pinko computer science languages. Strong typing is a crutch for people with weak memories.
Never work 9 to 5. If any are around at 9 a.m. it's because they were up all night.
Don't play tennis or any other sport that requires a change of clothes. Mountain climbing is OK, though, and real programmers often wear climbing boots to work in case a mountain should suddenly spring up in the middle of the machine room.
Don't like the team programming concept. Unless, of course, they are the Chief Programmer.
Have no use for managers. Managers are a necessary evil. They are for dealing with personnel bozos, bean counters, senior planners, and other mental defectives.
Don't drive around in clapped out mavericks. They prefer BMW's, Lincolns, or pick-up trucks with floor shifts. Fast motorcycles are highly regarded.
Like vending machine popcorn. Coders pop it in the microwave oven. Real programmers use the heat given off by the CPU. They can tell what job is running just by listening to the rate the corn is popping.
Know every nuance of every instruction and use them all in every real program. Puppy architects won't allow execute instructions to address another execute as the target instruction. Real programmers despise such petty restrictions.
Don't bring brown bag lunches to work. If the vending machine sells it, they eat it. If the vending machine doesn't sell it, they don't eat it. Vending machines don't sell quiche.
If you want to do something beyond a slideshow with that Contura, all 486-dx33 or whatever of it;-), I do suggest Linux.
Oddly, I acquired a small stack of these over the years from a former employer who tossed them in the junk heap as they decayed (which the Conturas tend to do), and by ripping them apart managed to cobble together a few working ones. They run Linux well enough, as long as you don't need a GUI.
--
* Helen *
I had one of these too, and wore it into the ground over the course of about *10* years, which is quite a good lifetime for a digital watch, IMHO.
I still use a modern Casio calculator watch, which has lots of databank features I don't use because it's easier to let my cell phone handle those tasks. But I'd rather have the classic scientific calculator watch -- the ability to do hex math and logs on my wrist was very handy!
--
* Helen *
[BTW: You can get rid of those pesky X-10 ads for 30 days at a time by visiting their opt-out page [x10.com] which I found in their customer service FAQ.]
A simple
127.0.0.1 ads.x10.com
in your hosts file causes your browser to open a blank window, instead of an x10 ad, when it encounters an x10 pop-whatever. True, you have to close the window, but I find a browser window with an error message in it much less objectionable than a blaring, flashing X10 ad, and I don't have to take action every 30 days to keep it that way.
X10 ad free for years, and proud of it, -- * Helen *
I am convinced that Shockwave Flash is a tool of the devil designed to drive ordinary people insane.
Hmmm. Flash is ACTUALLY a semi-useful delay timer for pop-up ads, for those of us living in areas without broadband.
Flash pop-up or pop-under? No problem! I can close that window before the first full screenful of ad graphics appears, because it takes so damn long for it to load, and my reaction time is good!
Think about THAT, advertisers who use Flash! I see a blank window, get annoyed, want to immediately kill that waste of bandwidth, and close it... never even knowing which product you were intending to advertise!
We have no problems with Swing. Its working quite well. But if you do not like it, then use other GUI package, such as SWT from IBM (check out www.eclipse.org). It uses native widgets, and lightning fast
Oh *goody*! Yet another GUI port. Yes, that's just what we need.... You see, we started before Swing was even around. We've already changed GUI's once (to Swing), to get where we are. (And then waited, and waited, and waited, for it to work even as well as it does today. I'm glad to hear Swing works better in 1.4.)
But the fact remains, we've been waiting 3, 4, maybe more, years to have a usable GUI. AS HAVE OUR PAYING CUSTOMERS, who haven't been entirely happy with performance/GUI bugs/delays, and who probably would have been happier sooner if we'd chosen a different implementation platform. This experience does not a ringing endorsement of java as a client-side platform make. This is my point.
It's taken Java YEARS to get to the point that production-level GUI's, with the performance and interface polish that the Fortune 500 expects for internal mission-critical apps, can be efficiently coded, without spending lots of time diagnosing and programming special-case workarounds.
The promise of java was great. I was as excited as anyone when Oak was demo'd at Usenix many years ago. But some early implementors have had a bumpy enough ride, that they've already lept off the train, given up chasing the java holy grail (which may, 5 or 6 versions after initial release, work well -- what was that we say about not trusting a Version 1.1 from M$? I'm up to not trusting a 1.3 from Sun...) and gone on to other, more stable, languages, possibly never to return.
Don't get me wrong. I like Sun. I think SunOS was pretty much the one true "proprietary" UNIX, because it had so many of the good BSD features lacking in most other commercial unices, which were usually based on System V. That only causes me to shake my head in puzzlement, all the more, at how java's development has gone. It really should have been as debugged as it is today, a couple years ago.
Coming from the MS side of development a few years ago, Swing does some VERY weird things with focus control (1.4 seems to have fixed this, but we have not switched over yet). I have had to do more work-arounds for focus-related bugs (in AWT) than anything else. Our product is designed to be very data-entry friendly, so providing tight focus control is of major importance. Our previous UI was character-based, so long-term clients have come to rely on VERY fast response when doing data-entry. So far Swing has handled everything great.
Pete, is that you? If not, there's another company out here who's been a bit frustrated by focus issues. Those who say.Net needs a long time to grow up were probably burned on java's early versions -- IMHO, the stuff important on the client side (read: GUI) was rushed out the door, then fixed over and over again, necessitating constant java middleware updates by customers and changes to API usage in code.
YMMV, of course. But until recently, trying to release a product with a complex, production-level GUI built in java, was like a cat chasing its tail, complicated by the fact that periodically the cat would start to grow a new tail and started chasing it before it was full-grown, only to find out that the new tail had completely different movement properties and could not be chased exactly the same way as the old tail (read: API's that completely changed just when you had modified your code to work around the old bugs).
This isn't in any way meant to diminish java's back-end server-side usefulness. Just saying that it marketed itself as all things to all people, but that for a long time, it was really only suited to server-side processing and (maybe) simplistic graphical apps.
Now java folks can say, "We've been around, it's stable," which is by orders of magnitude a more true statement than it used to be. But their apparent assumption that any competitor's product will be as awf^H^H^Hdeveloper challenging as java's GUI features were for the first couple years, isn't quite on the mark.
OK, one can giggle at MS' endless succession of incompatible data access API's, but on the other hand, few folks in the "real world" spent more than a few minutes on RDO and OLEDB. ODBC works, folks still use it for serious coding, and it's still supported.
The FreeCharge should be in everyone's hurricane/earthquake/riot prepardness kit.
There's a much better chance of the cell-phone tower working (they have generators) than the 3 miles of cable between you and the CO still being in one piece.
After the Nisqually quake in the Seattle area last year, power was off in the well-shaken Green River Valley area until late that night. Our office phone system did not work, because the PBX didn't have power. Cell phones did (when you could get a connection, since everyone was on them).
I have a FreePlay radio in each of my emergency kits (one in the bedroom and one in the garage), and will add this gadget. A few minutes of winding in order to be able to call someone and tell them where I am and that I'm OK sounds reasonable to me.
Why do I sometimes put bogus information in surveys? Because the survey stands between me and something I'm after, and I don't want to waste any more time than necessary, getting whatever it is. For example, reading an online article, downloading eval software, entering an etailer's contest, getting on a geek mailing list, etc. are all things for which I've been asked to fill out surveys.
Privacy concerns don't necessarily enter into the equation in those situations. I may or may not want to take the time/brain power to even attempt to answer accurately.
As for Unix GUI tools, I have no difficulty understanding why they came around so late in the game. In many ways a GUI is anathema to Unix.
And that is why Unix is anathema to folks who don't read slashdot.
Clearly, you're not seeing the point I'm trying to make. Perhaps that's because I spent last weekend doing a 200-mile bike ride and am still fried. Or perhaps you just don't get it.
I'm not saying UNIX isn't a superior platform for folks not afraid of a command line.
I am saying that for the 99.99% of the world that *IS* afraid of a command line, and the 97% of the developer community which is (sad but true in IT), GUI's and monkey-level GUI builders are where it's at. And for whatever reason (like the "we're better than that; clearly it's an issue of educating users that OUR way is better, not just giving them what they say they want, that we know isn't as good" attitude hinted at in the above post), UNIX platform and tool vendors preferred not to go after that market for a really long time. At the same time, they were fretting about eroding market share. Hello?
Without the pipe, what advantage does Unix have?
For one, from a developer's perspective, system call traces that don't require buying multi-hundred or multi-thousand-dollar third party packages, to do the job.;-)
Do you have any experiance with the interface builders listed here [gmu.edu]?
I'm not doubting your story or anything, but details about these tools a pretty sketchy.
Thanks. I'd suggest not doubting my story. I was there, and it struck me by surprise so much that it's one of my more vivid memories from my Usenix-attending days.
IBM's Visual Age Smalltalk was hampered by its choice of language and speed.
I'll give you that NeXT had a darn nice dev environment. I didn't do much work on it, but of the interface builders I remember from that day and age, it was the one that worked most like an efficient tool and least like a research project. Still, it was NeXT-only, and NeXT boxes were rare in my neck of the woods in IT departments (where most developers are) even in comparison to AIX, Solaris and HP-UX based boxes. If it's not available for the platforms folks are actually using in the business world, is it truly an alternative?
All MS has done since they started developing NT is chase *nix. The only thing I can think of that they might have had a head start on is the GUI, but I have my doubts about that, too.
Ummmm.... I was at Usenix in the early/mid-1990's when someone (Rob Kolstad?) got up and said something like, "Hey folks, how many of you have seen Visual Basic? Now I know we think of Windows as a toy OS, but if you haven't how easy VB makes Windows GUI app coding easy for the masses, you need to go look at it, and get worried." It was a very clear HELLO?!? to the UNIX dev tool community, that they needed to get to work, to play catch up and come up with something that made UNIX GUI app development as easy as VB made Windows GUI app development. Only nearly a decade later did a tool show up that is similarly easy for a typical lightweight IT apps programmer (as opposed to real, CS-trained coders like most of us) to use, to create apps -- and it was Kylix, by *BORLAND*, not a traditional UNIX tool company.
Say what you will about Java. A monkey can use VB and turn out a data entry form. A somewhat-trained monkey can use Kylix on Linux and do the same. One has to be a bit more skilled to do the same task in any Java dev environment I've seen. UNIX is still trailing Windows in terms of development environments "anyone" can use to turn out good looking, reasonably functional apps.
The Java people from Sun were at that Usenix. I know this, because there was a demo of the java-to-be product, perhaps even in the same session as the one in which the VB remark was made. So it can't be said that lots of folks didn't have clear hints that GUI app development needed to be monkey-accessible nearly a decade ago.
Some years ago, I spent some time trying to learn the Dvorak, and finally gave up, annoyed at the productivity hit during the week.
Then my thoughts turned to, WTF is this not working well for me, even after I've learned the positions of the keys pretty well?
So, what's a geek to do? Well, of course, I started doing analyses of my keystrokes, to try to figure this out.;-) What I found out was that when using QWERTY, my left hand was typically typing 55%+ of the letters, and the right 45%-, and when using Dvorak, it's reversed.
I'm left-hand-dominant (though officially right-handed thanks to pre-school training). I want to use the fingers on my left hand as much as possible, because they're the ones that have the highest dex (obD reference). QWERTY lets me do that, so I decided then and there that QWERTY wins for me, and haven't bothered with the "efficiency" of Dvorak since then.
An easy method to determine the quality of your keyboard. 1. Take the keyboard and remove the cable. Bonus points if the cable is designed to be replaceable. 2. Find and old CGA monitor. 3. Raise the keyboard high above your head. 4. Bring it down onto the monitor as if you were chopping wood. 5. Repeat until either the monitor or the keyboard breaks. If this test renders the keyboard useless, it's probably one of those wireless multimedia internet pieces of crud. If the keyboard miraculously survives and/or the monitor smashes to bits, congratulations! You have an IBM Model M!
Oh, I wish I had moderator access today and had not already contributed to this thread. That post is CLASSIC and its author deserves some karma.
I never (intentionally) use a caps-lock key. I got so pissed at triggering the caps-lock key on my Dell Inspiron accidentally that I found a utility to just neuter the darn thing. Now it behaves as a normal shift key, not a caps-lock. (Just curious... Do you code in FORTRAN IV? Do you send lots of spam about a kid named Craig who wants cards? Why do you need a shift lock?)
Hear, hear! These clicky-clacky keyboards are great for dancing one's fingers across the keys with a minimum of force while still getting great tactile and audible feedback that yes, the keys you think you hit, really were hit. Nothing quite like them for "sureness" of typing.
(Do I use one now? No, I don't have one, but if I tripped over one in good condition, I'd probably buy it. By the way, barc0001, why did you get an AT in 1992? They were quite old by then...)
Sadly, I have worked in a place that disallowed listening even to legit CD's with headphones. The idea being that it isolated you from what else was going on in the office and you couldn't hear the phone/pages. It wasn't understood that sometimes "virtual isolation" was teh way to get work done. That's really the only negative comment I have about the place... overall it's a good company with pleasant staff and (eek!) ethical managers.
Slashdot Mirror
It's a WHOLE lot easier to code in *nix with BSD sockets than it is to code in Win32/MAPI.
That's why I was able to DOUBLE my hourly rate when doing server-side MAPI code in C, vs. what it had been doing generic tcp/ip apps code in *nix C.
Given that, why use MAPI? At the time, it was the only way to get to the Exchange message store. And some of those apps are still around, hence the issues with Exchange -> anything else migration.
--
* Helen *
Well, AC,
;-)
/. tech content: I did this on the Pyramid OS-X platform, home of the broken ATT-semantic-based chgrp() syscall that didn't clear the sgid-bit as part of chgrp(), and thus allowed anyone to create a shell setgid to group-of-choice at any time).
I think you missed your last dose of ritalin. Go take it. We'll wait.
I did indeed write a compiler -- for an awful dialect of Pascal (ob
As for posting the URL's for code I wrote 8-17 years ago: Not likely, sorry.
--
* Helen *
Sorry AC droid,
;-)
A "super simple httpd for *BSD"? Why do that, when I've already written a load-balancing one -- a decade ago, kiddo.
Besides, it'd be stupid to waste my time coding something that's already out there, unless I was doing it as an intellectual exercise to see if I could figure out how to do it. I prefer to write code that folks actually *WANT* -- and yes, in the mid/late 1980's, some of that which paid quite well, involved MAPI.
I first used vi in the early 1980's, wrote a compiler in C in the mid-80's and that load-balancing http server in the mid-90's. Let's see... taught UNIX security in the late-1980's, founded a ISP with a handful of Sparcstations and a T-1, was lead maintainer of the internals of a commercial (read: folks paid for it) RDBMS for a while. I just happen to know how to code well enough to be paid for it, on more than one platform.
There are many women whose technical limits are exceeded when talk goes beyond VB and SQL. I, however, am not one of them.
If you don't want to read any details about MS software, you'd do well to stay away from articles which seek to equivalence other packages to it.
Better luck next troll my friend,
--
* Helen *
AC,
Bzzzt, wrong answer! One more time: MAPI is NOT just a client-side technology.
I will say that server-side MAPI did have lots of brokenness back in its early days (circa mid-90's) -- things like server-side functions which displayed dialog boxes on the server and waited for someone to see them and press "OK" before the server process calling the MAPI function that errored would continue.
The point of MAPI is not just to make it easy for any client to send mail via a "common protocol" (did you mean API?). Another point is that a single client can select WHICH protocol to use, to send mail -- because it was developed back in the days before everyone decided SMTP/POP3/IMAP were the way to go. At least this is true of the versions of MAPI supplied with typical Exchange clients. (I believe Simple MAPI as supplied with vanilla Windows may be limited to God's Intended Email Protocols, SMTP/POP3/IMAP).
And being MAPI-free doesn't mean code is virus free, by any means.
--
* Helen *
Whatever Fits,
It depends which MAPI you're talking about. Most apps folks know about the client-side functionality in Simple MAPI.
There is another version, called Extended MAPI. This does indeed support many server-side functions, for the creation of "message store providers" and "transport providers" and other such things that are part of the underlying plumbing of Exchange. It's definitely not a client-side-only technology.
--
* Helen *
Errr, Earthlink has its problems, too.
:-(
It thinks so little of its users that it blocked all outbound access to non-Earthlink servers' port 25, without notice to users, a couple years ago.
Nevermind that some of us telecommuters NEEDED to be able to send mail to customers through our employers' servers (rather than through our local ISP's servers), of course.
The employer ended up installing a second mail server on a high-numbered port for me to connect to, so that I wouldn't have to change ISP's. This only happened after a full day of troubleshooting -- over the same night that Earthlink messed with port blocking, my employer had tweaked its network security and email server config.
I understand they did it to provide a net.guardrail against spammers using open relays, but they'd make no exceptions even in the case of my employer sending them a note requesting that I be given access to port 25 on site mumble.com. Really tells me how much they think of their users. (They're more concerned about preventing their dumbie (dummy+newbie collection) users from ticking off the net, than about providing experienced users with the full access we expect.)
--
* Helen *
Sun's Java license goes into great detail about what you may not do with the product. (Basically, they skirt the whole issue of liability by saying that you can't use java when reliability/proper functionality/etc. are a life and death issue.)
So if Microsoft is saying, "We're not going there; and if we do, boy, it'll cost you," they're not singing that different a song than Sun -- other then leaving open the possibility of pursuing the big dollars in the mission critical space.
--
* Helen *
[ There are many variations of this. Here is one, which is shorter than others but has more of the feel of the "original" I remember from way back when... source: http://www.cirr.com/~barkley/jokes/realprog.html ]
Real Programmers...
Don't eat quiche. Real programmers don't even know how to spell quiche. They like Twinkies, Coke, and palate-scorching Szechwan food.
Don't write applications programs. They program right down to the bare metal. Applications programs are for dullards who can't do systems programming.
Don't comment their code. If it was hard to write, it should be hard to understand and even harder to modify.
Don't draw flowcharts. Flowcharts are, after all, the illiterate's form of documentation. Cavemen drew flowcharts; look how much it did for them.
Don't use COBOL. COBOL is for wimpy applications programmers.
Don't use FORTRAN. FORTRAN is for wimpy engineers who wear white socks, pipe stress freaks, and crystallography weenies. They get excited over finite state analysis and nuclear reactor simulations.
Don't use LOGO. In fact programmers use LOGO after puberty.
Don't use APL unless the whole program can be written on one line.
Don't use LISP. Only effeminate programmers use more parentheses than actual code.
Don't use Pascal, BLISS, ADA, or any of those sissy-pinko computer science languages. Strong typing is a crutch for people with weak memories.
Never work 9 to 5. If any are around at 9 a.m. it's because they were up all night.
Don't play tennis or any other sport that requires a change of clothes. Mountain climbing is OK, though, and real programmers often wear climbing boots to work in case a mountain should suddenly spring up in the middle of the machine room.
Don't like the team programming concept. Unless, of course, they are the Chief Programmer.
Have no use for managers. Managers are a necessary evil. They are for dealing with personnel bozos, bean counters, senior planners, and other mental defectives.
Don't drive around in clapped out mavericks. They prefer BMW's, Lincolns, or pick-up trucks with floor shifts. Fast motorcycles are highly regarded.
Like vending machine popcorn. Coders pop it in the microwave oven. Real programmers use the heat given off by the CPU. They can tell what job is running just by listening to the rate the corn is popping.
Know every nuance of every instruction and use them all in every real program. Puppy architects won't allow execute instructions to address another execute as the target instruction. Real programmers despise such petty restrictions.
Don't bring brown bag lunches to work. If the vending machine sells it, they eat it. If the vending machine doesn't sell it, they don't eat it. Vending machines don't sell quiche.
Oddly, I acquired a small stack of these over the years from a former employer who tossed them in the junk heap as they decayed (which the Conturas tend to do), and by ripping them apart managed to cobble together a few working ones. They run Linux well enough, as long as you don't need a GUI.
--
* Helen *
I still use a modern Casio calculator watch, which has lots of databank features I don't use because it's easier to let my cell phone handle those tasks. But I'd rather have the classic scientific calculator watch -- the ability to do hex math and logs on my wrist was very handy!
--
* Helen *
127.0.0.1 ads.x10.com
in your hosts file causes your browser to open a blank window, instead of an x10 ad, when it encounters an x10 pop-whatever. True, you have to close the window, but I find a browser window with an error message in it much less objectionable than a blaring, flashing X10 ad, and I don't have to take action every 30 days to keep it that way.
X10 ad free for years, and proud of it,
--
* Helen *
Flash pop-up or pop-under? No problem! I can close that window before the first full screenful of ad graphics appears, because it takes so damn long for it to load, and my reaction time is good!
Think about THAT, advertisers who use Flash! I see a blank window, get annoyed, want to immediately kill that waste of bandwidth, and close it ... never even knowing which product you were intending to advertise!
But the fact remains, we've been waiting 3, 4, maybe more, years to have a usable GUI. AS HAVE OUR PAYING CUSTOMERS, who haven't been entirely happy with performance/GUI bugs/delays, and who probably would have been happier sooner if we'd chosen a different implementation platform. This experience does not a ringing endorsement of java as a client-side platform make. This is my point.
It's taken Java YEARS to get to the point that production-level GUI's, with the performance and interface polish that the Fortune 500 expects for internal mission-critical apps, can be efficiently coded, without spending lots of time diagnosing and programming special-case workarounds.
The promise of java was great. I was as excited as anyone when Oak was demo'd at Usenix many years ago. But some early implementors have had a bumpy enough ride, that they've already lept off the train, given up chasing the java holy grail (which may, 5 or 6 versions after initial release, work well -- what was that we say about not trusting a Version 1.1 from M$? I'm up to not trusting a 1.3 from Sun...) and gone on to other, more stable, languages, possibly never to return.
Don't get me wrong. I like Sun. I think SunOS was pretty much the one true "proprietary" UNIX, because it had so many of the good BSD features lacking in most other commercial unices, which were usually based on System V. That only causes me to shake my head in puzzlement, all the more, at how java's development has gone. It really should have been as debugged as it is today, a couple years ago.
YMMV, of course. But until recently, trying to release a product with a complex, production-level GUI built in java, was like a cat chasing its tail, complicated by the fact that periodically the cat would start to grow a new tail and started chasing it before it was full-grown, only to find out that the new tail had completely different movement properties and could not be chased exactly the same way as the old tail (read: API's that completely changed just when you had modified your code to work around the old bugs).
This isn't in any way meant to diminish java's back-end server-side usefulness. Just saying that it marketed itself as all things to all people, but that for a long time, it was really only suited to server-side processing and (maybe) simplistic graphical apps.
Now java folks can say, "We've been around, it's stable," which is by orders of magnitude a more true statement than it used to be. But their apparent assumption that any competitor's product will be as awf^H^H^Hdeveloper challenging as java's GUI features were for the first couple years, isn't quite on the mark.
OK, one can giggle at MS' endless succession of incompatible data access API's, but on the other hand, few folks in the "real world" spent more than a few minutes on RDO and OLEDB. ODBC works, folks still use it for serious coding, and it's still supported.
I have a FreePlay radio in each of my emergency kits (one in the bedroom and one in the garage), and will add this gadget. A few minutes of winding in order to be able to call someone and tell them where I am and that I'm OK sounds reasonable to me.
Why do I sometimes put bogus information in surveys? Because the survey stands between me and something I'm after, and I don't want to waste any more time than necessary, getting whatever it is. For example, reading an online article, downloading eval software, entering an etailer's contest, getting on a geek mailing list, etc. are all things for which I've been asked to fill out surveys.
Privacy concerns don't necessarily enter into the equation in those situations. I may or may not want to take the time/brain power to even attempt to answer accurately.
And that is why Unix is anathema to folks who don't read slashdot.
Clearly, you're not seeing the point I'm trying to make. Perhaps that's because I spent last weekend doing a 200-mile bike ride and am still fried. Or perhaps you just don't get it.
I'm not saying UNIX isn't a superior platform for folks not afraid of a command line.
I am saying that for the 99.99% of the world that *IS* afraid of a command line, and the 97% of the developer community which is (sad but true in IT), GUI's and monkey-level GUI builders are where it's at. And for whatever reason (like the "we're better than that; clearly it's an issue of educating users that OUR way is better, not just giving them what they say they want, that we know isn't as good" attitude hinted at in the above post), UNIX platform and tool vendors preferred not to go after that market for a really long time. At the same time, they were fretting about eroding market share. Hello?
For one, from a developer's perspective, system call traces that don't require buying multi-hundred or multi-thousand-dollar third party packages, to do the job.IBM's Visual Age Smalltalk was hampered by its choice of language and speed.
I'll give you that NeXT had a darn nice dev environment. I didn't do much work on it, but of the interface builders I remember from that day and age, it was the one that worked most like an efficient tool and least like a research project. Still, it was NeXT-only, and NeXT boxes were rare in my neck of the woods in IT departments (where most developers are) even in comparison to AIX, Solaris and HP-UX based boxes. If it's not available for the platforms folks are actually using in the business world, is it truly an alternative?
Some years ago, I spent some time trying to learn the Dvorak, and finally gave up, annoyed at the productivity hit during the week.
;-) What I found out was that when using QWERTY, my left hand was typically typing 55%+ of the letters, and the right 45%-, and when using Dvorak, it's reversed.
Then my thoughts turned to, WTF is this not working well for me, even after I've learned the positions of the keys pretty well?
So, what's a geek to do? Well, of course, I started doing analyses of my keystrokes, to try to figure this out.
I'm left-hand-dominant (though officially right-handed thanks to pre-school training). I want to use the fingers on my left hand as much as possible, because they're the ones that have the highest dex (obD reference). QWERTY lets me do that, so I decided then and there that QWERTY wins for me, and haven't bothered with the "efficiency" of Dvorak since then.
Oh, I wish I had moderator access today and had not already contributed to this thread. That post is CLASSIC and its author deserves some karma.
Somebody mod this guy up!!
Lock LED's are for wimps who use lock keys.
I never (intentionally) use a caps-lock key. I got so pissed at triggering the caps-lock key on my Dell Inspiron accidentally that I found a utility to just neuter the darn thing. Now it behaves as a normal shift key, not a caps-lock. (Just curious... Do you code in FORTRAN IV? Do you send lots of spam about a kid named Craig who wants cards? Why do you need a shift lock?)
Hear, hear! These clicky-clacky keyboards are great for dancing one's fingers across the keys with a minimum of force while still getting great tactile and audible feedback that yes, the keys you think you hit, really were hit. Nothing quite like them for "sureness" of typing.
(Do I use one now? No, I don't have one, but if I tripped over one in good condition, I'd probably buy it. By the way, barc0001, why did you get an AT in 1992? They were quite old by then...)
Sadly, I have worked in a place that disallowed listening even to legit CD's with headphones. The idea being that it isolated you from what else was going on in the office and you couldn't hear the phone/pages. It wasn't understood that sometimes "virtual isolation" was teh way to get work done. That's really the only negative comment I have about the place... overall it's a good company with pleasant staff and (eek!) ethical managers.