O-chem is useless for practicing physicians. Took it, did OK at it, passed the required tests in undergrad and early med school, never used it again. Licensing boards understand this; there is no organic chemistry on the final board examinations for Internal Medicine.
In fact, thinking you understand low-level chemistry and biology can be dangerous for a practicing physician. For example, beta-blocker blood pressure medicines slow your heart rate and make your heart "squeeze" less strongly. We were initially taught that you should never give them to patients with heart failure -- their hearts didn't beat strongly to begin with. Given a basic understanding of the underlying biology withholding the medication made sense. Until someone studied them and found that for patients with mild heart failure beta-blockers reduced hospitalizations and death. And we had been withholding them for years. Whoops.
You don't want your doctor prescribing things based on their understanding of biology. You want them prescribing on the basis of clinical trial data and statistics.
I'm one of those young-ish MD degree people. High school grad age 17, BA computer science age 18, MS computer science age 19, MD age 23. Medical school was rough. Everybody else in my class had so much more life experience to draw on, which gives you better perspective about aging, disease, family issues and the like. Also, it was hard at age 19 to relate personally to my classmates who were married, had kids, etc. -- or the patients who might be four times my age. I learned how to do it, and got reasonably good at it, but it was hard.
In the end, I gave up clinical practice and went back into computer science. +1 to the poster who said "insert-name-of-faceless-corporation". I work at Google now. There are lots of smart people here.:-)
Google in particular sucks for more experienced workers...
There are definitely companies out there though that have a place for the second 20 years of your career.... Do you have drector and VP-equivalent tech paygrades? Do you have a fellowship?
You mean like Google? It has a tech-only non-management career ladder all the way up to VP-equivalent. It may not be perfect, but it seems to keep people like Vint Cerf around.
I think the reason you don't see that many 50 and 60 year old workers in the tech industry is that at the time they were in college (70s and early 80s) there weren't nearly as many people in computer-related fields as came later. Sure, there may be age discrimination, but there's also demographics going on here.
I'm using the Yahoo Toolbar on both my Windows and Mac boxes so I can share bookmarks. It's also nice to share my bookmarks live between Firefox and IE.
But Yahoo Toolbar won't install on Deer Park 2 (aka Firefox 1.1 alpha 2). It complains that "0.5b" is not a valid version number.
Can I hack the version string somehow to allow it to install? Change it to "0.5.0" or something?
Callum Linden and I are the two developers at Linden Lab working on Mozilla embedding. Some details:
Why bother? We want to allow people running Second Life full-screen to access our web site. Right now, if you want to bid on a piece of virtual land, or read the scripting language wiki, you have to either run in a window or switch out to your browser. That sucks, so we're fixing it.
The second goal is to get to third-party web sites. I want to trade SL currency on Gaming Open Market while staying in-world. Our internal scripting language supports e-mail into and out of the world, as well as XML-RPC. Lots of people have used this to build cool web sites that tie into the virtual world. See the postcards on Snapzilla postcards and the Second Life del.icio.us tag for examples. Getting these connected into the world would be a big win.
Why Mozilla? Could there be any other choice?:-) Our competitor There.com uses Internet Explorer to do their internal web browsing, but they only support PCs. We love open source tools and use LGPL stuff extensively in both server and client. Plus, we need support for Win32, Mac and Linux.
Working with the Mozilla codebase has been interesting. It's huge, and very complex. But I'm proud to say we've found and fixed a couple bugs in Mozilla, and contributed the changes back to the Mozilla folks. I'm looking forward to Firefox 1.1 and the potential for the new Cairo/OpenGL rendering subsystem -- that may really help with embedding for 3D worlds.
So despite the linked description, Callum and I are working on getting an interactive 2D browser working first. Web pages on the surfaces of 3D objects may not ship in the next version (1.7). It'll ship as soon as it's done.
As an aside, if any of the Mozilla developers are reading this, we could use some help with embedding, specifically how to post mouse-click events into an embedded instance, please send me mail.
Substantial user interface design and testing went into the Tivo remote control, including many battles over which buttons to leave off (to reduce complexity), a special rubber for good click feel, and the distinctive peanut shape.
I wonder if Comcast will ship new remotes to their DVR customers if they sign up for Tivo.
My perception is that the PC gaming business is slowly withering away, being replaced by console gaming. I believe the sales numbers support this view -- console games make much more money than PC games.
Consoles have significant user interface advantages for casual players. There's no game selection interface -- just put in the disc you want and turn it on. There's generally no network connection (so no activation) and generally no hard drive (so no install process). Total time from system on to first game-related screen is under a minute.
Legacy game concerns are also less of an issue. Video and audio output are via RCA connectors, which have been standardized for decades. If you've got an old game and an old console, there's a good chance you can still play the game.
I'm just surprised that PC gamers are so willing to put up with long install processes, driver patches, and complex user interfaces. I wonder if games that just autorun when inserted and load data directly off the disc would do better.
(Of course, some games just have to be run on a PC, particularly those that need a high resolution display and a mouse. My current favorite is Strange Adventures in Infinite Space from www.digital-eel.com. It installs in seconds, launches in seconds, and each game session is under 15 minutes.)
I know that what you want is a C-based UI toolkit that can render widgets in OpenGL. I recently had to research this, and my impression is that you're stuck. As others have suggested, you might consider switching to a C++ compiler and just linking in your C code. You'll be hard pressed to find an advanced UI toolkit that isn't based in C++. Object orientation just matches user interface coding too well.
Here's the results of my search. This was for an application which had a very large number of Windows-like UI elements, but had to be able to render a 3D world using OpenGL.
FLTK -- Unsuitable. LGPL. Can open GL windows. Uses direct calls to OS line-drawing routines, so could be adapted to render directly to GL. Reasonable number of widgets, but ugly. No skin support. Development slow (two check-ins in last month).
wxWidgets(aka wxWindows) -- Good. LGPL. Can open GL windows.Used by Mitch Kapor's Chandler PIM project. Would require separate UI thread not to block. Requires awkward preprocessor macros in UI classes. Third-party graphical widget layout tools.
GLOW -- Unsuitable. Renders to GL. Not actively maintained. Uses advanced C++ (STL, RTTI). Clean code. No access to OS features, based on GLUT. Very simple, ugly widgets. Small library of widgets
Qt -- Very good. Commercial license. Can open GL windows. Included graphical UI layout tools. XML-based UI files, but compiled into code rather than loaded at runtime.
GLUI -- Unsuitable. LGPL. Renders to GL. Not actively maintained. Simplistic C++ code. No access to OS features, based on GLUT. Very simple, ugly widgets. Small library of widgets.
XPToolkit(aka Mozilla/XUL) -- Unsuitable. Tri-license MPL/LGPL/GPL. No GL support. Would need to ship Mozilla or Firefox as part of app. Excellent ideas for XML-based UI layout, though.
Full-custom with XML library -- Good. Renders to GL. Easiest for migration. Could do in-game UI editing, both for default skin, user skins, and script UI controls. Probably more work for you.
Also, if you're new to UI library development, I strongly suggest you read the Qt whitepapers. Their concept of signals and slots seems quite powerful (though I have not used it myself).
As a long-time player of Strange Adventures in Infinite Space, I have this to say about Weird Worlds:
It rocks!
It has smooth, OpenGL-based 3D graphics. The universe is bigger. The images are sharper. But it still retains the quirky, simple gameplay that made the original so great.
To quote Bruce Perens, if security really matters, you should base it on three things:
* Something you know (password or PIN) * Something you have (badge or bank card) * Something you are (thumbprint, hand scan, voice check)
This is how CounterPane security locks up its own colo facility. (Of course, they also tape everybody coming in, and there's a live guard who knows your face.)
Each of these components can be relatively weak, but in combination they are quite strong. For instance, you could probably let people choose any password they wanted as long as you required, say, their badge and a thumbprint to log on.
For backwards compatibility, write a macro that generates random strings of characters the maximum length accepted by the legacy system to which you must log on. Encrypt the list of passwords, and use the method above to decrypt the password archive as needed.
Admittedly, this is because Valve and the mod team have kept updating it, but under the hood, CounterStrike is still the Quake II engine.
I believe the poster was looking for games that got BETTER with new hardware, not just stayed fun due to good gameplay.
I've played CounterStrike on and off for about four years. Every patch or new version (Condition Zero) has brought improved texture resolution, better sounds, and more eye candy to keep the graphics card humming. It's now possible to play 1600x1200 with all sorts of graphics options cranked to the maximum. And since the gameplay mechanics haven't changed much, it's still fun.
James
IPv6 address per-connection?
on
IPv6 is Here
·
· Score: 1
I remember reading somewhere a proposal that IPv6 had a sufficiently large address space that you could allocate yourself an address to use just during the duration of a single connection, then throw it away when you were done. Depending on how this is done, it could add some anonymity to the connection process. Does anyone have a link to this information?
On the other hand, some of the docs I've read say the IPv6 address is based on your MAC. Doesn't that limit actual address space to the number of available MAC addresses (2^48?), rather than 2^128?
When I got my medical license, I was all excited -- yeah, it's dumb, but I was an intern. So when my California Department of Motor Vehicles renewal came up, I asked for "MD" to be added to the end of my name. I was hoping it might help with future encounters with police.
Don't do this.
It turns out the California DMV computers don't have a suffix field, so they made my last name "Cook MD". Later they made some web tools available. But the tools don't work right for me, because my actual last name "Cook" doesn't match the DMV's "Cook MD".
On my most recent renewal, I got rid of the "MD" part. Besides, it's useful sometimes to just be a regular human being -- that way the folks at the bank don't ask me about their arthritis.:-)
Hackers: Heroes of the Computer Revolution was published by Steven Levy in 1984. It's a well-told history of personal computers, starting with the Tech Model Railroad and the early timeshare work at MIT, moving to the Stanford west-coast era and finally to the early personal computer era with Bill Gates and the two Steves. All the side-projects are included: Spacewar, blue boxing, pinball, etc. Levy went on to become Newsweek's technology columnist, and his prose is much less eloquent these days, but in the 80s, it was pure magic.
I read this book when I was twelve or thirteen, and the descriptions of the glories of solving technical challenges inspired me to study computer science.
Doctor-turned-engineer here. I have no personal experience with being sued for medical malpractice. My impression is that lawsuits are not triggered by the actual bad event, but by personality differences between doctors and patients.
Sick people often get sicker, and sometimes die. Many (not all) lawsuits seem to me to be caused by the fact that something bad happened, and the doctor and family didn't communicate well. What's frustrating as a doctor is that the "something bad" isn't always due to something the doctor did wrong, or could have done differently.
It seems like being a smooth talker is more important than practicing effective medicine. But I guess witch doctors have known that all along -- they don't ever seem to get sued.
Anyway, two abstracts from the New England Journal of Medicine. At least the profession monitors itself occasionally.
Volume 335:1963-1967 December 26, 1996 Relation between Negligent Adverse Events and the Outcomes of Medical-Malpractice Litigation Troyen A. Brennan, M.D., J.D., M.P.H., Colin M. Sox, B.A., and Helen R. Burstin, M.D., M.P.H.
Background We have previously shown that in New York State the initiation of malpractice suits correlates poorly with the actual occurrence of adverse events (injuries resulting from medical treatment) and negligence. There is little information on the outcome of such lawsuits, however. To assess the ability of malpractice litigation to make accurate determinations, we studied 51 malpractice suits to identify factors that predict payment to plaintiffs.
Methods Among malpractice claims that we reviewed independently in an earlier study, we identified 51 litigated claims and followed them over a 10-year period to determine whether the malpractice insurer had closed the case. We obtained detailed summaries of the cases from the insurers and reviewed the litigation files if the outcome of a case differed from the outcome predicted in our original review.
Results Of the 51 malpractice cases, 46 had been closed as of December 31, 1995. Among these cases, 10 of 24 that we originally identified as involving no adverse event were settled for the plaintiffs (mean payment, $28,760), as were 6 of 13 cases classified as involving adverse events but no negligence (mean payment, $98,192) and 5 of 9 cases in which adverse events due to negligence were found in our assessment (mean payment, $66,944). Seven of eight claims involving permanent disability were settled for the plaintiffs (mean payment, $201,250). In a multivariate analysis, disability (permanent vs. temporary or none) was the only significant predictor of payment (P = 0.03). There was no association between the occurrence of an adverse event due to negligence (P = 0.32) or an adverse event of any type (P = 0.79) and payment.
Conclusions Among the malpractice claims we studied, the severity of the patient's disability, not the occurrence of an adverse event or an adverse event due to negligence, was predictive of payment to the plaintiff.
July 25, 1991 Relation between malpractice claims and adverse events due to negligence. Results of the Harvard Medical Practice Study III
BACKGROUND AND METHODS. By matching the medical records of a random sample of 31,429 patients hospitalized in New York State in 1984 with statewide data on medical-malpractice claims, we identified patients who had filed claims against physicians and hospitals. These results were then compared with our findings, based on a review of the same medical records, regarding the incidence of injuries to patients caused by medical management (adverse events). RESULTS. We identified 47 malpractice claims among 30,195 patients' records located on our initial visits to the hospitals, and 4 claims among 580 additional records located during follow-up visits. The overall rate of claims per discharge (weighted) was 0.13 percent (95 percent confidence interval, 0.076 to 0.18 percent). Of the 280 patients who had adverse events caused by medical negligence
As a programmer, I have to wonder a little bit about Jon. Maybe he's just more l33t than me. Check out the VideoLAN source respository. The core DRM decryption file is 1014 lines of uncommented C, excluding the GPL comment at the top. Including exciting recursive preprocessor macros. *shudder*
How the heck did he write 1000 lines of nasty bit-twiddling code without a single comment to remind himself of what he was doing? Is it the output of a disassembler cobbled back together into C? Did he intentionally strip the comments before checking it in? Why do that?
Jakob Nielsen wrote a nice article about why advertising doesn't work on the web in September of 1997. It's still true. The web isn't TV. People aren't passively watching the screen. They are actively reading and searching for information (or amusement). Anything that slows that process down will be at least ignored, if not actively blocked. As evidence, take a look at long term ad banner click through rates. They fall by a factor of 2 about every 18 months.
I personally use the Adblock plug-in for Mozilla and Mozilla Firebird. Before Adblock I used to leave Flash uninstalled so I wouldn't be distracted by blinking flashing ads. Now I just don't see them, and in fact, don't even download them.
James
Semi-realtime satellite image of fire status
on
Online Fire Tracking?
·
· Score: 4, Informative
There are a few web pages with live satellite imagery of the fire area. This one shows the entire state of California, including both current fires and old burns. You can see the activity around San Diego quite clearly.
From the site: "MODIS Active Fire Mapping Program Welcome to the USDA Forest Service Remote Sensing Applications Center's (RSAC) MODIS Active Fire Mapping web site. Here you will find information on current large fires, active fire maps, and fire imagery as seen by the MODIS instrument on board NASA's EOS satellites, Terra & Aqua."
Also, the San Diego Union Tribune has a lot of good information at http://www.signonsandiego.com/ I think checking the web site of the local newspaper is probably the best way to keep up to date. They has links to lists of evacuated areas that are cleared for people to return.
Perhaps. In 1997 fredlabs (www.fredlabs.com) demonstrated VirtualMac, which enabled System 7 applications to run in a compatibility layer. I played with it several times, running then-crash-notorious Microsoft Word, Excel and the like without difficulty. It was written, I believe, by two guys named Fred, one of whom was an ex-Apple employee who worked on their 68k emulation engine for PowerPC.
With this technology (and a fair amount of compatibility testing) Apple could have had many Mac applications up and running on the date of purchase. With NeXT they had to write the compatibility layer themselves from scratch. This put Mac developers in limbo while it was written. With Be, the current crop of MacOS applications would have continued to run while developers explored the new API.
While Be did not have a complete QuickTime implementation, without access to source they were able to cobble together enough codec support to play movies. With source they probably could have done much better. And in 1997 all the bells and whistles of QuickTime were less important than just playing audio and video.
Java eventually came to BeOS as part of the several browser projects.
AppleScript would undoubtably have been replaced outside of a compatibility environment. Be supported copy/paste, drag-and-drop, and interapplication communication (all really the same thing if designed properly) with BeMessages, multi-part, typed, intra- and inter-application message packets. These could be generated from any scripting system, or from the command line. (Remember 'tell'? As in, 'tell terminal BeQuit'?) I believe someone wrote or was working on a system to transport these across a network. But basically, you could inject messages into any application's message processing queue, which made most applications scriptable for free.
I ran BeOS starting with the early developer release, through PR1 and 2, up through Person Edition 5. BeOS convinced me to buy a Power Mac clone, and once they transitioned to Intel, to buy Intel hardware.
One thing missing from the above discussion is one of Jean Louis Gassee's original design goals for the BeOS: symmetric multiprocessing. During the early BeOS days he would frequently repeat "one processor per person is not enough." That's what convinced them to build their early AT&T Hobbit-based multiprocessor machines, and eventually the BeBox, the dual PowerPC machine designed by Joe Palmer and beloved by many hackers. They did it because there was no cheap multiprocessor hardware available at that time. The goal, said JLG, was a multiprocessor machine that you could "lift with your credit card."
But JLG was wrong. He thought that people would have a never-ending desire for more processing speed, and that the right way to meet that need was to build computers with multiple CPUs at the price-performance sweet spot. And in 1990 that seemed true. But through the 90's CPU speeds increased to the point that word processing, e-mail, Internet access, and 2D graphics editing became fast enough for ordinary use on even the cheapest hardware. Suddenly there was little benefit to an intentionally-not-backwards-compatible OS.
Doing symmetric multiprocessing (SMP) well is difficult. To do it right requires a lot of thought about which parts of the system can be threaded and how to avoid threads locking on shared resources. Be's solution to this problem was to rewrite the whole system from scratch -- from the kernel to the filesystem to the GUI. And they didn't care about backwards compatibility; it always seemed like the POSIX layer was an afterthought (remember how many versions were released that didn't support select()? )
So once the performance benefit of BeOS (at least for most desktop users) vanished, what was left? Little hardware support, given their small development team and no vendor support. A not-particularly innovative GUI, since they decided to closely follow the predominant Windows/MacOS design. A beautifully designed API and highly modular system, but unfortunately not one that had any end user benefits.
It's ironic to think about what would have happened if Apple had purchased Be. True, they would have lost Steve Jobs, and perhaps the company. But a MacOS X-class OS would have shipped four years earlier, and had outstanding multiprocessor support in the core. Apple didn't bite, Be had nothing left, so they died. Sad.
Cooling actually does speed up asynch CPUs
on
Clockless Computing
·
· Score: 5, Informative
In 1993 I was a graduate student in the Caltech asynchronous circuit design group. That year we had a prototype asynchronous microprocessor that implemented a subset of the MIPS instruction set.
The guys in the lab used to demo this by hooking up an oscilloscope to show the instruction rate. They would then get out a can of liquid nitrogen, and pour it on the CPU. The instruction rate would climb right up... This lead to many jokes about temporary cooling during heavy loads. "Hey, get the ice cubes... He's starting gcc!":-)
I believe our group used a different basic latch design than Sutherland describes. We handled all bits asynchronously using three wires, one that went high for 0, one that went high for 1, and a feedback wire for "got it". His design looks like it could latch a bus of wires simultaneously. Forgive me if I'm wrong... it's been almost a decade.
One of the nice features of these chips is that they are tolerant of manufacturing errors. Often impurities in the silicon will change the resistance or capacitance of a long wire. In asynchronous designs, this just means operations that need that wire will be a little slower. In the synchronous world, either the whole chip fails or you have to underclock it.
A group of ex-Caltech graduate students started a company to sell these asynchronous processors. Details at Fulcrum Microsystems.
(For those at Caltech: Yes, that's me on the asynch VLSI people page. And yes, I wrote prlint. What an awful piece of software that was.)
What can you do with a computer in the Third World?
Use text-to-speech to teach people how to read.
Store reference texts in a very dense manner -- most medical reference books will fit in less than 4 megs on RAM on PalmPilots.
E-mail to nearby villages for trade.
Web-based markets for farming goods.
Web-based road and travel conditions.
E-mail announcements of mobile health-care services coming to nearby regions.
Tolerance of poor phone lines -- make the computer retry every one hour until download succeeds.
I think the fact that it runs off on standard batteries is very powerful. The TRS-80 Model 100 did this, which proved very useful when traveling to regions without reliable power grids. The TRS-80 also had solar-panel power sources available for it... It would be nice if that worked here.
I take offense at this author's description of usability as a "feature." It does a great disservice to the champions of usable software systems to encourage the belief that usability can be added in the same way that reverse-alphabetical file listings can be added.
Usability is a fundamental issue that permeates a system's design. It's just as important to consider what the system will try NOT to do as it is to plan what it will do. I don't want my thermostat turning my lights on and off, even if it does contain a convenient timing circuit. It is very very difficult to take an existing system and "make it usable".
Creating something usable involves repeated evaluations by end users, and a willingness to pay attention to what your usability studies show. Developers are not valid users for this purpose. I'm really glad to see companies like Eazel that purport to be doing end user testing. Until the open source community starts paying attention to feedback from people other than developers, it will create software that only developers can use. And wasn't part of the idea to create better sofware for everyone?
This is a rehash of arguments more elegantly stated at http://www.useit.com, which discusses usability issues.
Slashdot Mirror
O-chem is useless for practicing physicians. Took it, did OK at it, passed the required tests in undergrad and early med school, never used it again. Licensing boards understand this; there is no organic chemistry on the final board examinations for Internal Medicine.
In fact, thinking you understand low-level chemistry and biology can be dangerous for a practicing physician. For example, beta-blocker blood pressure medicines slow your heart rate and make your heart "squeeze" less strongly. We were initially taught that you should never give them to patients with heart failure -- their hearts didn't beat strongly to begin with. Given a basic understanding of the underlying biology withholding the medication made sense. Until someone studied them and found that for patients with mild heart failure beta-blockers reduced hospitalizations and death. And we had been withholding them for years. Whoops.
You don't want your doctor prescribing things based on their understanding of biology. You want them prescribing on the basis of clinical trial data and statistics.
I'm one of those young-ish MD degree people. High school grad age 17, BA computer science age 18, MS computer science age 19, MD age 23. Medical school was rough. Everybody else in my class had so much more life experience to draw on, which gives you better perspective about aging, disease, family issues and the like. Also, it was hard at age 19 to relate personally to my classmates who were married, had kids, etc. -- or the patients who might be four times my age. I learned how to do it, and got reasonably good at it, but it was hard.
In the end, I gave up clinical practice and went back into computer science. +1 to the poster who said "insert-name-of-faceless-corporation". I work at Google now. There are lots of smart people here. :-)
Google in particular sucks for more experienced workers...
There are definitely companies out there though that have a place for the second 20 years of your career.... Do you have drector and VP-equivalent tech paygrades? Do you have a fellowship?
You mean like Google? It has a tech-only non-management career ladder all the way up to VP-equivalent. It may not be perfect, but it seems to keep people like Vint Cerf around.
I think the reason you don't see that many 50 and 60 year old workers in the tech industry is that at the time they were in college (70s and early 80s) there weren't nearly as many people in computer-related fields as came later. Sure, there may be age discrimination, but there's also demographics going on here.
I'm using the Yahoo Toolbar on both my Windows and Mac boxes so I can share bookmarks. It's also nice to share my bookmarks live between Firefox and IE.
But Yahoo Toolbar won't install on Deer Park 2 (aka Firefox 1.1 alpha 2). It complains that "0.5b" is not a valid version number.
Can I hack the version string somehow to allow it to install? Change it to "0.5.0" or something?
James
Callum Linden and I are the two developers at Linden Lab working on Mozilla embedding. Some details:
:-) Our competitor There.com uses Internet Explorer to do their internal web browsing, but they only support PCs. We love open source tools and use LGPL stuff extensively in both server and client. Plus, we need support for Win32, Mac and Linux.
Why bother? We want to allow people running Second Life full-screen to access our web site. Right now, if you want to bid on a piece of virtual land, or read the scripting language wiki, you have to either run in a window or switch out to your browser. That sucks, so we're fixing it.
The second goal is to get to third-party web sites. I want to trade SL currency on Gaming Open Market while staying in-world. Our internal scripting language supports e-mail into and out of the world, as well as XML-RPC. Lots of people have used this to build cool web sites that tie into the virtual world. See the postcards on Snapzilla postcards and the Second Life del.icio.us tag for examples. Getting these connected into the world would be a big win.
Why Mozilla? Could there be any other choice?
Working with the Mozilla codebase has been interesting. It's huge, and very complex. But I'm proud to say we've found and fixed a couple bugs in Mozilla, and contributed the changes back to the Mozilla folks. I'm looking forward to Firefox 1.1 and the potential for the new Cairo/OpenGL rendering subsystem -- that may really help with embedding for 3D worlds.
So despite the linked description, Callum and I are working on getting an interactive 2D browser working first. Web pages on the surfaces of 3D objects may not ship in the next version (1.7). It'll ship as soon as it's done.
As an aside, if any of the Mozilla developers are reading this, we could use some help with embedding, specifically how to post mouse-click events into an embedded instance, please send me mail.
Cheers,
James
Substantial user interface design and testing went into the Tivo remote control, including many battles over which buttons to leave off (to reduce complexity), a special rubber for good click feel, and the distinctive peanut shape.
I wonder if Comcast will ship new remotes to their DVR customers if they sign up for Tivo.
James
I coat my office in posters from www.despair.com, which mock the corporate single-word-and-pretty-picture inspirational posters.
For instance, "Limitations - Until you spread your wings, you have no idea how far you can walk."
James
My perception is that the PC gaming business is slowly withering away, being replaced by console gaming. I believe the sales numbers support this view -- console games make much more money than PC games.
Consoles have significant user interface advantages for casual players. There's no game selection interface -- just put in the disc you want and turn it on. There's generally no network connection (so no activation) and generally no hard drive (so no install process). Total time from system on to first game-related screen is under a minute.
Legacy game concerns are also less of an issue. Video and audio output are via RCA connectors, which have been standardized for decades. If you've got an old game and an old console, there's a good chance you can still play the game.
I'm just surprised that PC gamers are so willing to put up with long install processes, driver patches, and complex user interfaces. I wonder if games that just autorun when inserted and load data directly off the disc would do better.
(Of course, some games just have to be run on a PC, particularly those that need a high resolution display and a mouse. My current favorite is Strange Adventures in Infinite Space from www.digital-eel.com. It installs in seconds, launches in seconds, and each game session is under 15 minutes.)
James
I know that what you want is a C-based UI toolkit that can render widgets in OpenGL. I recently had to research this, and my impression is that you're stuck. As others have suggested, you might consider switching to a C++ compiler and just linking in your C code. You'll be hard pressed to find an advanced UI toolkit that isn't based in C++. Object orientation just matches user interface coding too well.
i tepapers.html
Here's the results of my search. This was for an application which had a very large number of Windows-like UI elements, but had to be able to render a 3D world using OpenGL.
FLTK -- Unsuitable. LGPL. Can open GL windows. Uses direct calls to OS line-drawing routines, so could be adapted to render directly to GL. Reasonable number of widgets, but ugly. No skin support. Development slow (two check-ins in last month).
wxWidgets(aka wxWindows) -- Good. LGPL. Can open GL windows.Used by Mitch Kapor's Chandler PIM project. Would require separate UI thread not to block. Requires awkward preprocessor macros in UI classes. Third-party graphical widget layout tools.
GLOW -- Unsuitable. Renders to GL. Not actively maintained. Uses advanced C++ (STL, RTTI). Clean code. No access to OS features, based on GLUT. Very simple, ugly widgets. Small library of widgets
Qt -- Very good. Commercial license. Can open GL windows. Included graphical UI layout tools. XML-based UI files, but compiled into code rather than loaded at runtime.
GLUI -- Unsuitable. LGPL. Renders to GL. Not actively maintained. Simplistic C++ code. No access to OS features, based on GLUT. Very simple, ugly widgets. Small library of widgets.
XPToolkit(aka Mozilla/XUL) -- Unsuitable. Tri-license MPL/LGPL/GPL. No GL support. Would need to ship Mozilla or Firefox as part of app. Excellent ideas for XML-based UI layout, though.
Full-custom with XML library -- Good. Renders to GL. Easiest for migration. Could do in-game UI editing, both for default skin, user skins, and script UI controls. Probably more work for you.
Also, if you're new to UI library development, I strongly suggest you read the Qt whitepapers. Their concept of signals and slots seems quite powerful (though I have not used it myself).
Qt 3.3 whitepaper:
http://www.trolltech.com/products/wh
James
As a long-time player of Strange Adventures in Infinite Space, I have this to say about Weird Worlds:
It rocks!
It has smooth, OpenGL-based 3D graphics. The universe is bigger. The images are sharper. But it still retains the quirky, simple gameplay that made the original so great.
Strong work, Digital Eel!
James
To quote Bruce Perens, if security really matters, you should base it on three things:
* Something you know (password or PIN)
* Something you have (badge or bank card)
* Something you are (thumbprint, hand scan, voice check)
This is how CounterPane security locks up its own colo facility. (Of course, they also tape everybody coming in, and there's a live guard who knows your face.)
Each of these components can be relatively weak, but in combination they are quite strong. For instance, you could probably let people choose any password they wanted as long as you required, say, their badge and a thumbprint to log on.
For backwards compatibility, write a macro that generates random strings of characters the maximum length accepted by the legacy system to which you must log on. Encrypt the list of passwords, and use the method above to decrypt the password archive as needed.
James
According to the Wikipedia entry for Half-Life it's based on a "heavily modified version of the Quake engine".
The entry for Quake states that Half-Life "Primarily includes QuakeWorld source code, but contains portions of Quake 2 source as well".
I would have sent this via e-mail, but your Slashdot profile doesn't list one.
James
Admittedly, this is because Valve and the mod team have kept updating it, but under the hood, CounterStrike is still the Quake II engine.
I believe the poster was looking for games that got BETTER with new hardware, not just stayed fun due to good gameplay.
I've played CounterStrike on and off for about four years. Every patch or new version (Condition Zero) has brought improved texture resolution, better sounds, and more eye candy to keep the graphics card humming. It's now possible to play 1600x1200 with all sorts of graphics options cranked to the maximum. And since the gameplay mechanics haven't changed much, it's still fun.
James
I remember reading somewhere a proposal that IPv6 had a sufficiently large address space that you could allocate yourself an address to use just during the duration of a single connection, then throw it away when you were done. Depending on how this is done, it could add some anonymity to the connection process. Does anyone have a link to this information?
On the other hand, some of the docs I've read say the IPv6 address is based on your MAC. Doesn't that limit actual address space to the number of available MAC addresses (2^48?), rather than 2^128?
When I got my medical license, I was all excited -- yeah, it's dumb, but I was an intern. So when my California Department of Motor Vehicles renewal came up, I asked for "MD" to be added to the end of my name. I was hoping it might help with future encounters with police.
:-)
Don't do this.
It turns out the California DMV computers don't have a suffix field, so they made my last name "Cook MD". Later they made some web tools available. But the tools don't work right for me, because my actual last name "Cook" doesn't match the DMV's "Cook MD".
On my most recent renewal, I got rid of the "MD" part. Besides, it's useful sometimes to just be a regular human being -- that way the folks at the bank don't ask me about their arthritis.
Hackers: Heroes of the Computer Revolution was published by Steven Levy in 1984. It's a well-told history of personal computers, starting with the Tech Model Railroad and the early timeshare work at MIT, moving to the Stanford west-coast era and finally to the early personal computer era with Bill Gates and the two Steves. All the side-projects are included: Spacewar, blue boxing, pinball, etc. Levy went on to become Newsweek's technology columnist, and his prose is much less eloquent these days, but in the 80s, it was pure magic.
I read this book when I was twelve or thirteen, and the descriptions of the glories of solving technical challenges inspired me to study computer science.
Doctor-turned-engineer here. I have no personal experience with being sued for medical malpractice. My impression is that lawsuits are not triggered by the actual bad event, but by personality differences between doctors and patients.
Sick people often get sicker, and sometimes die. Many (not all) lawsuits seem to me to be caused by the fact that something bad happened, and the doctor and family didn't communicate well. What's frustrating as a doctor is that the "something bad" isn't always due to something the doctor did wrong, or could have done differently.
It seems like being a smooth talker is more important than practicing effective medicine. But I guess witch doctors have known that all along -- they don't ever seem to get sued.
Anyway, two abstracts from the New England Journal of Medicine. At least the profession monitors itself occasionally.
Volume 335:1963-1967
December 26, 1996
Relation between Negligent Adverse Events and the Outcomes of Medical-Malpractice Litigation
Troyen A. Brennan, M.D., J.D., M.P.H., Colin M. Sox, B.A., and Helen R. Burstin, M.D., M.P.H.
Background We have previously shown that in New York State the initiation of malpractice suits correlates poorly with the actual occurrence of adverse events (injuries resulting from medical treatment) and negligence. There is little information on the outcome of such lawsuits, however. To assess the ability of malpractice litigation to make accurate determinations, we studied 51 malpractice suits to identify factors that predict payment to plaintiffs.
Methods Among malpractice claims that we reviewed independently in an earlier study, we identified 51 litigated claims and followed them over a 10-year period to determine whether the malpractice insurer had closed the case. We obtained detailed summaries of the cases from the insurers and reviewed the litigation files if the outcome of a case differed from the outcome predicted in our original review.
Results Of the 51 malpractice cases, 46 had been closed as of December 31, 1995. Among these cases, 10 of 24 that we originally identified as involving no adverse event were settled for the plaintiffs (mean payment, $28,760), as were 6 of 13 cases classified as involving adverse events but no negligence (mean payment, $98,192) and 5 of 9 cases in which adverse events due to negligence were found in our assessment (mean payment, $66,944). Seven of eight claims involving permanent disability were settled for the plaintiffs (mean payment, $201,250). In a multivariate analysis, disability (permanent vs. temporary or none) was the only significant predictor of payment (P = 0.03). There was no association between the occurrence of an adverse event due to negligence (P = 0.32) or an adverse event of any type (P = 0.79) and payment.
Conclusions Among the malpractice claims we studied, the severity of the patient's disability, not the occurrence of an adverse event or an adverse event due to negligence, was predictive of payment to the plaintiff.
July 25, 1991
Relation between malpractice claims and adverse events due to negligence. Results of the Harvard Medical Practice Study III
BACKGROUND AND METHODS. By matching the medical records of a random sample of 31,429 patients hospitalized in New York State in 1984 with statewide data on medical-malpractice claims, we identified patients who had filed claims against physicians and hospitals. These results were then compared with our findings, based on a review of the same medical records, regarding the incidence of injuries to patients caused by medical management (adverse events). RESULTS. We identified 47 malpractice claims among 30,195 patients' records located on our initial visits to the hospitals, and 4 claims among 580 additional records located during follow-up visits. The overall rate of claims per discharge (weighted) was 0.13 percent (95 percent confidence interval, 0.076 to 0.18 percent). Of the 280 patients who had adverse events caused by medical negligence
As a programmer, I have to wonder a little bit about Jon. Maybe he's just more l33t than me. Check out the VideoLAN source respository. The core DRM decryption file is 1014 lines of uncommented C, excluding the GPL comment at the top. Including exciting recursive preprocessor macros. *shudder*
drms.c
How the heck did he write 1000 lines of nasty bit-twiddling code without a single comment to remind himself of what he was doing? Is it the output of a disassembler cobbled back together into C? Did he intentionally strip the comments before checking it in? Why do that?
Any ideas?
Jakob Nielsen wrote a nice article about why advertising doesn't work on the web in September of 1997. It's still true. The web isn't TV. People aren't passively watching the screen. They are actively reading and searching for information (or amusement). Anything that slows that process down will be at least ignored, if not actively blocked. As evidence, take a look at long term ad banner click through rates. They fall by a factor of 2 about every 18 months.
I personally use the Adblock plug-in for Mozilla and Mozilla Firebird. Before Adblock I used to leave Flash uninstalled so I wouldn't be distracted by blinking flashing ads. Now I just don't see them, and in fact, don't even download them.
James
There are a few web pages with live satellite imagery of the fire area. This one shows the entire state of California, including both current fires and old burns. You can see the activity around San Diego quite clearly.
3 00 _0700.jpg
http://activefiremaps.fs.fed.us/archive/cgb2003
From the site: "MODIS Active Fire Mapping Program
Welcome to the USDA Forest Service Remote Sensing Applications Center's (RSAC) MODIS Active Fire Mapping web site. Here you will find information on current large fires, active fire maps, and fire imagery as seen by the MODIS instrument on board NASA's EOS satellites, Terra & Aqua."
Also, the San Diego Union Tribune has a lot of good information at http://www.signonsandiego.com/ I think checking the web site of the local newspaper is probably the best way to keep up to date. They has links to lists of evacuated areas that are cleared for people to return.
James
Perhaps. In 1997 fredlabs (www.fredlabs.com) demonstrated VirtualMac, which enabled System 7 applications to run in a compatibility layer. I played with it several times, running then-crash-notorious Microsoft Word, Excel and the like without difficulty. It was written, I believe, by two guys named Fred, one of whom was an ex-Apple employee who worked on their 68k emulation engine for PowerPC.
With this technology (and a fair amount of compatibility testing) Apple could have had many Mac applications up and running on the date of purchase. With NeXT they had to write the compatibility layer themselves from scratch. This put Mac developers in limbo while it was written. With Be, the current crop of MacOS applications would have continued to run while developers explored the new API.
While Be did not have a complete QuickTime implementation, without access to source they were able to cobble together enough codec support to play movies. With source they probably could have done much better. And in 1997 all the bells and whistles of QuickTime were less important than just playing audio and video.
Java eventually came to BeOS as part of the several browser projects.
AppleScript would undoubtably have been replaced outside of a compatibility environment. Be supported copy/paste, drag-and-drop, and interapplication communication (all really the same thing if designed properly) with BeMessages, multi-part, typed, intra- and inter-application message packets. These could be generated from any scripting system, or from the command line. (Remember 'tell'? As in, 'tell terminal BeQuit'?) I believe someone wrote or was working on a system to transport these across a network. But basically, you could inject messages into any application's message processing queue, which made most applications scriptable for free.
I ran BeOS starting with the early developer release, through PR1 and 2, up through Person Edition 5. BeOS convinced me to buy a Power Mac clone, and once they transitioned to Intel, to buy Intel hardware.
One thing missing from the above discussion is one of Jean Louis Gassee's original design goals for the BeOS: symmetric multiprocessing. During the early BeOS days he would frequently repeat "one processor per person is not enough." That's what convinced them to build their early AT&T Hobbit-based multiprocessor machines, and eventually the BeBox, the dual PowerPC machine designed by Joe Palmer and beloved by many hackers. They did it because there was no cheap multiprocessor hardware available at that time. The goal, said JLG, was a multiprocessor machine that you could "lift with your credit card."
But JLG was wrong. He thought that people would have a never-ending desire for more processing speed, and that the right way to meet that need was to build computers with multiple CPUs at the price-performance sweet spot. And in 1990 that seemed true. But through the 90's CPU speeds increased to the point that word processing, e-mail, Internet access, and 2D graphics editing became fast enough for ordinary use on even the cheapest hardware. Suddenly there was little benefit to an intentionally-not-backwards-compatible OS.
Doing symmetric multiprocessing (SMP) well is difficult. To do it right requires a lot of thought about which parts of the system can be threaded and how to avoid threads locking on shared resources. Be's solution to this problem was to rewrite the whole system from scratch -- from the kernel to the filesystem to the GUI. And they didn't care about backwards compatibility; it always seemed like the POSIX layer was an afterthought (remember how many versions were released that didn't support select()? )
So once the performance benefit of BeOS (at least for most desktop users) vanished, what was left? Little hardware support, given their small development team and no vendor support. A not-particularly innovative GUI, since they decided to closely follow the predominant Windows/MacOS design. A beautifully designed API and highly modular system, but unfortunately not one that had any end user benefits.
It's ironic to think about what would have happened if Apple had purchased Be. True, they would have lost Steve Jobs, and perhaps the company. But a MacOS X-class OS would have shipped four years earlier, and had outstanding multiprocessor support in the core. Apple didn't bite, Be had nothing left, so they died. Sad.
In 1993 I was a graduate student in the Caltech asynchronous circuit design group. That year we had a prototype asynchronous microprocessor that implemented a subset of the MIPS instruction set.
:-)
The guys in the lab used to demo this by hooking up an oscilloscope to show the instruction rate. They would then get out a can of liquid nitrogen, and pour it on the CPU. The instruction rate would climb right up... This lead to many jokes about temporary cooling during heavy loads. "Hey, get the ice cubes... He's starting gcc!"
I believe our group used a different basic latch design than Sutherland describes. We handled all bits asynchronously using three wires, one that went high for 0, one that went high for 1, and a feedback wire for "got it". His design looks like it could latch a bus of wires simultaneously. Forgive me if I'm wrong... it's been almost a decade.
One of the nice features of these chips is that they are tolerant of manufacturing errors. Often impurities in the silicon will change the resistance or capacitance of a long wire. In asynchronous designs, this just means operations that need that wire will be a little slower. In the synchronous world, either the whole chip fails or you have to underclock it.
A group of ex-Caltech graduate students started a company to sell these asynchronous processors. Details at Fulcrum Microsystems.
(For those at Caltech: Yes, that's me on the asynch VLSI people page. And yes, I wrote prlint. What an awful piece of software that was.)
What can you do with a computer in the Third World?
Use text-to-speech to teach people how to read.
Store reference texts in a very dense manner -- most medical reference books will fit in less than 4 megs on RAM on PalmPilots.
E-mail to nearby villages for trade.
Web-based markets for farming goods.
Web-based road and travel conditions.
E-mail announcements of mobile health-care services coming to nearby regions.
Tolerance of poor phone lines -- make the computer retry every one hour until download succeeds.
I think the fact that it runs off on standard batteries is very powerful. The TRS-80 Model 100 did this, which proved very useful when traveling to regions without reliable power grids. The TRS-80 also had solar-panel power sources available for it... It would be nice if that worked here.
I take offense at this author's description of usability as a "feature." It does a great disservice to the champions of usable software systems to encourage the belief that usability can be added in the same way that reverse-alphabetical file listings can be added.
Usability is a fundamental issue that permeates a system's design. It's just as important to consider what the system will try NOT to do as it is to plan what it will do. I don't want my thermostat turning my lights on and off, even if it does contain a convenient timing circuit. It is very very difficult to take an existing system and "make it usable".
Creating something usable involves repeated evaluations by end users, and a willingness to pay attention to what your usability studies show. Developers are not valid users for this purpose. I'm really glad to see companies like Eazel that purport to be doing end user testing. Until the open source community starts paying attention to feedback from people other than developers, it will create software that only developers can use. And wasn't part of the idea to create better sofware for everyone ?
This is a rehash of arguments more elegantly stated at http://www.useit.com, which discusses usability issues.