Smalltalk didn't even have self-repairing windows - you had to click in them to get them to repaint, and programs couldn't draw into partially obscured windows. Bill Atkinson did not know this, so he invented regions as the basis of QuickDraw and the Window Manager so that he could quickly draw in covered windows and repaint portions of windows brought to the front.
This makes it sound like Bruce Horn had seen evidence of overlapping, but not auto-repainting windows (without overlap, why would regions have been necessary?). Even so, he supports the notion that Atkinson was unaware of certain aspects of the behavior.
That these two accounts are similar, but show some discrepancy, gives more credibility to what they have in common.
Hmm... if Atkinson thought he saw overlapping windows, then to me whether PARC could have demo'd it or not doesn't matter. My point was that Bill THOUGHT it did (though he was really looking at adjacent, and not overlapping windows), and designed his system to meet the expected capability.
Bill Atkinson left the two PARC visits with a mistaken understanding of the capabilities of the Smalltalk software. While Tesler was giving a demo, Atkinson thought that he had seen two windows layered on top of each other, though they were just bordering each other. This set off a multi month obsession to find out how Xerox had implemented the feature, only to be interrupted by an auto accident. Atkinson implemented the feature, and later found out that the PARC developers had never even considered implementing such a feature...
I wonder how many innovations (software or otherwise) are based upon us thinking something works a certain way, and only finding out later that we have created brand new behavior?
This, to me, is a wonderful example of the frequently serendipitous nature of discovery and invention, and I'm amazed that moments like this don't become more legendary than they already are.
It's been less than 6 months since introduction. Have Bluetooth and Airport Extreme components become that much cheaper in this timeframe? (I'm asking honestly, because I don't know the answer.)
My guess is that it is a competitive response, and not based on technology advance.
The higher end Mac Mini looks much better now. Adding in Bluetooth and Airport makes $599 look more reasonable, and $699 for a Superdrive model makes a good deal of sense.
While I applaud the author too, everyone needs to recognize that there is no substitute for "caring about the reader," and quite frankly, most technical people don't have the time (or want to expend the time) to learn how to explain themselves to a non-technical audience. More specifically, we don't feel that the audience is worth this expenditure of time.
As a project manager, one of the greatest skills I can bring to the table is being able to communicate effectively with the technical people (TP) on my team, and then turn around and explain to the non-technical people (NTP) in our organization what the heck they were talking about, and why it's important. I'm able to do this, in large part, because I have respect for people on both sides of the equation, and take the time to understand what they're saying, and communicate in their terms.
Unfortunately, there is traditionally very little respect from either of these camps, going either way. As long as we TP assume that we're talking to PHB's, Boneheads, and Golden Parachute Weenies(tm), it's going to show in the way we write.
If instead, we presume NTP to be intelligent, with a different (but still valuable) skillset, and keep that mindset at the forefront, our consideration for their intelligence will come through and so will our message.
Here's a test. Take your last technical proposal, and consider how you would structure and word it for (insert name of close, non-technical relative such as Mom, Dad, etc.). Then, write it that way, but without the analogies to Mom's wonderful cooking, or Dad's "Viagra incident." I guarantee that if you respect the audience, and don't talk down to them, you will improve your writing and communication.
Add in the practical suggestions from a book like this, and you should be in good shape. However, neither one of these components is a substitute for the other.
...this still would have some holes. Is the cable company going to also UPS the distribution point where it splits out? Around KY, the cable goes out before the power (most of the time), so you'd lose your IP over cable, and PoE wouldn't help unless all the communication points were similarly UPS'd.
You're correct. At the time we were looking to port these apps (we've since abandoned the plan, but maybe should reconsider), Windows was the only OS candidate being proposed, largely because of UI-client issues. If I remember Gordon Letwellin's (sp?) input correctly, several of the the OS/2 core services had a strong UNIX influence, and named pipes and device access are probably at the front.
Unfortunately, all of the OS/2 code was developed by a company which was acquired several years ago by a much larger player in the market. Given that this product competes directly with our new overlord's flagship product, it has been difficult for us to convince anyone to perform any maintenance on the code, even for known bugs.
Your comment makes me think we need to review the possibility of porting to Linux, and ignoring the OS/2 vs Windows angle.
Funny... whenever we've done end-user training and the end-users don't have a preconceived notion of what a computer OS is supposed to look like, they seem to latch on to OS/2 just fine. And yes, we had users that would wave the mouse around in the air, so much so that I (when I was working as a tech writer) created a graphic that showed that the mouse had to be in contact with the table.
Once we got people to that level of understanding, the interface was reasonably consistent throughout.
Not sure what your benchmark is, but as someone who used OS/2 as my day-to-day OS for several years, and have supported apps developed under this OS for several more, and spent more than a few hours writing articles for "Inside OS/2," your comments strike me as bogus.
The body of code we wrote (routing manager and 13 protocol-specific subsystems) depend on lots of OS/2-specific features. The two that jump out quickly are named-pipes (for IPC) and direct serial port access. We did so many things that were down at that level, that don't easily move to another OS (as far as I know).
I have done some moderate research into porting these apps, but given that many of them are UL-listed for life-safety applications, and all of them are used for real-time applications, we have not seen good options for moving the code easily.
If I've missed some "magic bullet," a Rosetta for OS/2 apps under Linux, or something like it, I would love to know. However, we haven't found any such solution.
I'll check out the links though. Thanks for the help.
We wrote a large body of building automation software subsystems in OS/2. There was no easy way to provide the same functionality in Windows, so it was never cost effective to port it.
To this day, we keep the central routing server and all the subsystems in OS/2 boxes that are treated like embedded control systems, and have written Windows 2K-based interface code that proxies everything as BACnet devices.
OS/2 was a good combination of modern OS services (named pipes, threads, etc.) and easy development. Given how simple it was to access serial ports, we could easily interface via DigiBoard multiplexers and such, and could write a new system driver (including reverse engineering time) in less than six months.
I'm the primary contact for IBM in our office, so they've been flooding me with information about porting these apps to Linux, which sadly, may never be cost effective.
I am *very* sorry to see this event, even though I fully understand and appreciate all the factors that led to OS/2's demise. It's like watching a very dependable ship being sent to the bottom of the ocean because it's too expensive to keep it afloat.
I don't know... mine rests underneath my shirtsleeve on my armband, and I'm able to easily switch tracks, pause, and adjust volume without even thinking about it. The variation of the scroll wheel is *very* simple to use.
In contrast, I see people all over the gym dorking around with other players, and not just so they can try to read the tiny displays.
Slashdot Mirror
That these two accounts are similar, but show some discrepancy, gives more credibility to what they have in common.
Tim
Hmm... if Atkinson thought he saw overlapping windows, then to me whether PARC could have demo'd it or not doesn't matter. My point was that Bill THOUGHT it did (though he was really looking at adjacent, and not overlapping windows), and designed his system to meet the expected capability.
Tim
This, to me, is a wonderful example of the frequently serendipitous nature of discovery and invention, and I'm amazed that moments like this don't become more legendary than they already are.
Tim
Does The Brain know about this?
Tim
It's been less than 6 months since introduction. Have Bluetooth and Airport Extreme components become that much cheaper in this timeframe? (I'm asking honestly, because I don't know the answer.)
My guess is that it is a competitive response, and not based on technology advance.
Tim
The higher end Mac Mini looks much better now. Adding in Bluetooth and Airport makes $599 look more reasonable, and $699 for a Superdrive model makes a good deal of sense.
:-(
It should have been this way from day 1.
Tim
What's interesting in listening to the MP3 is the sense of sustained energy over such a long period of time. Surreal...
Tim
While I applaud the author too, everyone needs to recognize that there is no substitute for "caring about the reader," and quite frankly, most technical people don't have the time (or want to expend the time) to learn how to explain themselves to a non-technical audience. More specifically, we don't feel that the audience is worth this expenditure of time.
As a project manager, one of the greatest skills I can bring to the table is being able to communicate effectively with the technical people (TP) on my team, and then turn around and explain to the non-technical people (NTP) in our organization what the heck they were talking about, and why it's important. I'm able to do this, in large part, because I have respect for people on both sides of the equation, and take the time to understand what they're saying, and communicate in their terms.
Unfortunately, there is traditionally very little respect from either of these camps, going either way. As long as we TP assume that we're talking to PHB's, Boneheads, and Golden Parachute Weenies(tm), it's going to show in the way we write.
If instead, we presume NTP to be intelligent, with a different (but still valuable) skillset, and keep that mindset at the forefront, our consideration for their intelligence will come through and so will our message.
Here's a test. Take your last technical proposal, and consider how you would structure and word it for (insert name of close, non-technical relative such as Mom, Dad, etc.). Then, write it that way, but without the analogies to Mom's wonderful cooking, or Dad's "Viagra incident." I guarantee that if you respect the audience, and don't talk down to them, you will improve your writing and communication.
Add in the practical suggestions from a book like this, and you should be in good shape. However, neither one of these components is a substitute for the other.
Tim
Yeah... CUT THE CHEESE already
<sniff><sniff>
Wait...
Tim
In retrospect, I would have gone with...
"Quoth the VOIP maven... nevermore"
I guess I can dispense with the testosterone treatments and Enzyte prescription. I'm clearly not fooling anyone.
Tim
Wow... I knew there was a reason I made you my friend...
Tim
...this still would have some holes. Is the cable company going to also UPS the distribution point where it splits out? Around KY, the cable goes out before the power (most of the time), so you'd lose your IP over cable, and PoE wouldn't help unless all the communication points were similarly UPS'd.
Tim
Troll?
I guess I should have writte POE in big, bold letters to make sure everyone got the joke.
Tim
...nevermore... nevermore....
Tim
But aside from porn...
Tim
Thank you for correcting the correction. The person responsible for the original correction has been sacked.
As usual, I was correct, in spite of my best efforts.
Tim
Doh!
"He said 'hand'... not 'head' you twit!"
Tim
Third hand... Zaphod! Is that you????
Tim
You're correct. At the time we were looking to port these apps (we've since abandoned the plan, but maybe should reconsider), Windows was the only OS candidate being proposed, largely because of UI-client issues. If I remember Gordon Letwellin's (sp?) input correctly, several of the the OS/2 core services had a strong UNIX influence, and named pipes and device access are probably at the front.
Unfortunately, all of the OS/2 code was developed by a company which was acquired several years ago by a much larger player in the market. Given that this product competes directly with our new overlord's flagship product, it has been difficult for us to convince anyone to perform any maintenance on the code, even for known bugs.
Your comment makes me think we need to review the possibility of porting to Linux, and ignoring the OS/2 vs Windows angle.
Thanks,
Tim
We used Cimetrics BACstac library to build a gateway application that runs under XP/2000. No MS/TP... BACnet/IP.
Tim
Funny... whenever we've done end-user training and the end-users don't have a preconceived notion of what a computer OS is supposed to look like, they seem to latch on to OS/2 just fine. And yes, we had users that would wave the mouse around in the air, so much so that I (when I was working as a tech writer) created a graphic that showed that the mouse had to be in contact with the table.
Once we got people to that level of understanding, the interface was reasonably consistent throughout.
Not sure what your benchmark is, but as someone who used OS/2 as my day-to-day OS for several years, and have supported apps developed under this OS for several more, and spent more than a few hours writing articles for "Inside OS/2," your comments strike me as bogus.
Tim
Here's the problem.
The body of code we wrote (routing manager and 13 protocol-specific subsystems) depend on lots of OS/2-specific features. The two that jump out quickly are named-pipes (for IPC) and direct serial port access. We did so many things that were down at that level, that don't easily move to another OS (as far as I know).
I have done some moderate research into porting these apps, but given that many of them are UL-listed for life-safety applications, and all of them are used for real-time applications, we have not seen good options for moving the code easily.
If I've missed some "magic bullet," a Rosetta for OS/2 apps under Linux, or something like it, I would love to know. However, we haven't found any such solution.
I'll check out the links though. Thanks for the help.
Tim
We wrote a large body of building automation software subsystems in OS/2. There was no easy way to provide the same functionality in Windows, so it was never cost effective to port it.
To this day, we keep the central routing server and all the subsystems in OS/2 boxes that are treated like embedded control systems, and have written Windows 2K-based interface code that proxies everything as BACnet devices.
OS/2 was a good combination of modern OS services (named pipes, threads, etc.) and easy development. Given how simple it was to access serial ports, we could easily interface via DigiBoard multiplexers and such, and could write a new system driver (including reverse engineering time) in less than six months.
I'm the primary contact for IBM in our office, so they've been flooding me with information about porting these apps to Linux, which sadly, may never be cost effective.
I am *very* sorry to see this event, even though I fully understand and appreciate all the factors that led to OS/2's demise. It's like watching a very dependable ship being sent to the bottom of the ocean because it's too expensive to keep it afloat.
Oh well...
Tim
I don't know... mine rests underneath my shirtsleeve on my armband, and I'm able to easily switch tracks, pause, and adjust volume without even thinking about it. The variation of the scroll wheel is *very* simple to use.
In contrast, I see people all over the gym dorking around with other players, and not just so they can try to read the tiny displays.
Tim