Upfront disclaimer: I work for Apple iServices, and was only peripherally involved with this project which was shifted to a different contractor shortly after I joined. Nevertheless, there was a wealth of information that was floating around the office at that time in terms of lessons learned, architectural discussions, etc.
CHCS and its follow-on, CHCS II, are electronic medical records systems for the U.S. Department of Defense that are supposed to do basically what your organization wants. It's a monstrously complex endeavour, spanning all of the major arms of service, so that records can follow an injured serviceman as he is moved to different locations -- e.g. a Marine is injured in an exercise in Norway, evacuated to the Air Force base hospital in Ramstein, Germany, eventually sent home to Bethesda Naval Medical Hospital, then sent for follow-up physical therapy at Walter Reed Army Medical Center. While this is more dispersed geographically than most situations, it is more a matter of scale than anything else. A medical records system will encounter similar issues and challenges as a patient moves from an emergency hostpital close to the scene of an accident to a hospital close to home for recuperation to their doctor's office to a physical therapy out-patient clinic.
Four things that you will need to consider as you look into systems are:
1) Patient confidentiality - Who has ownership of the records? Who should be allowed to see them? Who should be allowed to see them for a short time, and then cut off?
2) Ease of use - We got bit on the ass big-time by this one. Many physicians see their time as extremely valuable, and hate anything that takes more time than the current system for them. (I get the feeling that this is one reason why their handwriting is so bad on average -- they're rushing through the writeup.) Most of them are slow typists, so entering data into a screen, especially free-form notes, is a slow process for them. There was a lot of resistance to using the system as a result of this.
3) Scalability - To be blunt, this is an enterprise-scale task at the high end of things, and Linux and the *BSD's have not yet proven themselves to be players at this level. The requirements for availability, uptime, backup, etc. are such that you really ought to be looking at high-end Sun, IBM, HP, or similar sorts of systems. Forget about using mySQL -- it doesn't do ACID; any system needs to be based on something like Postgres, or a high-end commercial database like Oracle or Informix or Sybase.
4) Integration with legacy systems - This is a major task, as I am willing to be serious money that there are existing systems that have records for different departments in your hospital system. Some of them will be on relational DB's, but some will be on other sorts of systems based on M/MUMPS.
In summary, this is a major undertaking at an enterprise scale. The direct cost of the OS and other software will be a relatively small fraction of the cost. The lion's share of the cost will be from the necessary customization and systems integration that needs to happen, followed by the cost of the necessary systems administration and aftercare. Although open source software may give you peace of mind and low upfront acquisition costs, the fact of the matter is that you get what you pay for in this arena.
There are darn few organizations that have the money to burn like the Department of Defense, to do an entirely new project. There are existing medical records packages that operate at this scale designed to run on mainframes and the like. Even a high-end multi-processor Intel-based systems is no match for the truly enterprise scale systems that were designed that way from the ground up.
It is useful to note that much of what C# provides actually originated in the context of NeXT, the Objective-C language, and the associated operating systems.
Inheritance and Interfaces
Another idea that was lifted directly off Java, and one which turned out to be very controversial is that of multiple inheritance. In what seemed like a step backwards, Java did not allow you to define classes that inherit from one than one class. Java did let you define "interfaces", which work like C++ abstract classes, but were semantically clearer: an interface is a functional contract that declares one or more methods.
Objective-C in the OpenStep/Mac OS X environment has single inheritance from a base class (NSObject), and protocols, which are precise counterparts to Java's interfaces. I have run into situations, however, where multiple inheritance is exactly what is required, and using interfaces meant that I had re-write the exact same code more than once, as I was implementing a group of specialized collection classes in Java. There were two axes of differentiation: mutability = (immutable, mutable), and ordering (partially ordered, ordered, strictly ordered). There was a lot of code that had to be duplicated that I should have been able to inherit from two abstract superclasses, one for mutability, and one for ordering. (*grumble*)
Garbage Collection and Memory Management
One new feature that I mentioned already was that of copy-by-value objects. This seemingly small improvement is a potentially huge performance saver! With C++, one is regularly tempted to describe the simplest constructs as classes, and in so doing make it safer and simpler to use them. For example, a phone directory program might define a phone record as a class, and would maintain one PhoneRecord object per actual record. In Java, each and every one of those objects would be garbage collected! Now, Java uses mark-and-sweep in order to garbage collect. The way that this is done is this: the JVM starts with the program's main object, and starts recursively descending through references to other objects. Every object that is traversed is marked as referenced. When this is done, all of the objects that aren't marked are destroyed. In the phone book program, especially if there are thousands and thousands of phone records, this can drastically increase the time that it takes the JVM to go through the marking phase. In C#, you'd be able to avoid all this by defining PhoneRecord as a struct instead of a class.
Objective-C provides a semi-automatic reference-counted garbage collection mechanism that is amenable to programmer intervention to increase efficiency, through a construct called an Autorelease Pool. Every object has a retain count, which can be incremented or decremented. The object's retain count starts at one, and when an object's retain count goes down to zero it is garbage collected. Note that this happens the instant that the retain count drops to zero, not during a mark/sweep. However, you may need to pass an object on to another part of your app, but your code does not need/want to retain it. What you do instead is tell the object to auto-release. It is then put into the autorelease pool, and later on during the system's garbage collection each object in the autorelease pool is sent a release message. Some objects that are entered in the autorelease pool still have a retain count (as they are being retained by other objects) and are simply removed from the autorelease pool; others have their retain counts drop to zero and are garbage collected.
You can fine-tune this mechanism to a high degree, by putting your own autorelease pool in the stack ahead of the system's primary autorelease pool. For instance, suppose you know that you will be allocating a whole bunch of objects for use in a part of your program, and after you exit you will never need them again. Well, you can put your own autorelease pool in for the system's autorelease pool at the start of that section of your code, write normal code, then remove and release your private autorelease pool and put back the system autorelease pool, which release all of the objects you created in your little section of code. Conversely, if you want an object to stick around, just don't ever release or autorelease it.
However, from a business standpoint, I find that the automated garbage collection and never having to worry about memory allocation issues is a strong point of Java. It allows me to code more complex applications and avoid memory debugging issues that invarable bedevil complex Objective-C and C++ programs. I can get a WebObjects application to a customer much more quickly using Java than using Objective-C, with quicker turnaround and more feedback cycles.
Events, Notifications, and Delegation
Personally, I found C# support of events to be a very exciting new feature! Whereas an object method operates the object in a certain way, object events let the object notify the outside world of particular changes in its state.. A Socket class, for instance, might define a ReadPossible event or a data object might release a DataChanged event. Other objects may then subscribe for such an event so that they'd be able to do some work when the event is released. Events may very well be considered to be "reverse- functions", in the sense that rather than operate the object, they allow the object to operate the outside world, and in my programming experience, events are almost as important as methods themselves.
The OpenStep and Mac OS X operating systems (viewed separately from the Objective-C language, as these features are available from Java as well) have long had notifications and delegates. There is a system-wide notification center, objects can define notifications that they will post in response to certain events, and objects can register to receive particular events or classes of events. This mechanism has been in place for a long time.
Delegation is a bit more tightly tied to Objective-C, as objects in Obj-C can pass messages (i.e. method calls) onto to other objects, and objects can "pose as" other objects. An object can register to be the delegate of another object (in Java, the delegator object needs to make special provision for this), and there are "informal protocols" or "informal interfaces" defined that indicate the possible messages a delegate might receive from its delegator. Again, this is not new, and its assembly into a single OS is not new.
Primitive Types
C# classes are also all eventual descendents of the object class, but unlike Java, primitives such as integers, booleans and floating-point types are considered to be regular classes.
This is one feature that I like very much, and wish that Java had. Objective-C, of course, will always have to support native types such as char's and int's, as it is defined as a superset of C. However, Java had the opportunity to remove this artificial distinction, and has caused lots of cursing from yours truly over the past couple of years.
Compiling to Native Code
It's not yet clear whether C# programs would need the equivalent of a Java Virtual Machine or whether they could be compiled directly into standalone executables, which might positively affect C#'s performance and possibly even set it as a viable successor to C++, at the very least on Windows.
I would point out here that compiling to native code may not result in the fastest execution. Review the HP Dynamo project, as written up on Ars Technica, for the reasons why JITC can actually exceed the speed of native code. The whole Transmeta Crusoe architecture is built around this theory of operation, and no one will claim that it's too slow.
Genericity
One thing that's sure to be missing from C#, and very sadly at that is any form of genericity.
Amen to this. The fact that genericity is missing from Java is a serious gripe of mine, and the fact that it is missing from C# is a serious omission. This business of casting objects coming out of arrays is a pain the in neck, and it is often tough to find out where an object of the wrong type went into an array, although on the cast coming out you get a ClassCastException. Far better to catch the problem when the object goes in, which often gives you a better idea of where your design is broken. One of these days I am really going to have to start using the stuff coming out of the GJ project.
Conclusions
Overall, I find that the "new" stuff in C# is really old stuff. Furthermore, this is not the first time that all of this has been pulled together in one place. Almost all of this has been in the NeXTStep/OpenStep/Mac OS X family for a long time, and the implementations there are quite mature. I suspect that the implementations in C# will require several revisions before they reach the levels that programmers can really use.
Just so everyone knows, I am a Consulting Engineer working for Apple iServices, a part of Apple Computer, specializing in WebObjects development. These opinions are my own, however, and not those of Apple.
As someone who has used Tenon's old implementation of Mach/BSD called MachTen (which runs on the old Mac OS 8/9), I don't think that this is the way it will work.
Tenon's X server always runs full-screen, as the performance penalty for having the X Windows graphics essentially re-rendered by the Mac OS's QuickDraw architecture is very high (according to Tenon's own FAQ). Other X Windows implementations for the classic Mac OS -- such as MacX -- do offer "interleaved" X and QuickDraw windows, but run more slowly. Given the clunkiness of X Windows on my old 3400, even with Tenon's take-over-the-whole-screen approach, I'd say they're probably right. However, from a user experience point of view it is preferable to have fully interleaved X and native windows on the screen, in keeping with the ideal of having a non-modal interface.
Mac OS X has a completely different graphics architecture. If you look at Apple's Mac OS X System Overview, on page 52 there is a diagram of the graphics architecture. It has a box called "Core Graphics Services (window server)" that underlies the graphics rendering libraries, such as Core Graphics Rendering -- a.k.a. Quartz, QuickDraw, QuickTime, and OpenGL. None of the higher level graphics environments does any rendering to the screen directly -- it all goes through the window server layer. Adding X Windows to the mix in this environment simply means adding another box on top of the window server. To quote from page 53:
The window server is a single system-wide process that coordinates low-level windowing behavior and enforces a fundamental uniformity in what appears on the screen. It is a lightwieght server in that it does not do any rendering itself, but instead communicates with the client graphics libraries layered on top of it. It is "agnostic" in terms of a drawing model.
This is a horse of a very different color compared to running X Windows under the classic Mac OS. In the Mac OS X environment, the X Windows libraries can communicate directly to the window server, making true interleaved windows not only feasible but as fast as native Quartz- or QuickDraw-based windows.
--Paul
Disclaimer: I am an Apple iServices Consulting Engineer specializing in WebObjects, but I am not directly involved with the development of Mac OS X. My involvement with Tenon is strictly as an end user of Machten. The opinion posted here is strictly my own and not Apple's.
Actually, the graphical tools already do that, as far back as Mac OS X Server 1.0. There is a little lock icon on the control/preferences panels that require super-user access to change things. Changes are only allowed if you click on the lock icon and enter the root password. If you are already logged in as root, the lock is automatically open.
The interesting question is: should the day come that Linux implements metadata, could/would the Apple team merge the same Unix API into the BSD layer of OS-X?
This is an excellent thought, but, I think the opposite should be considered -- Apple (building on the work done at NeXT) has come up with a design for application resource packaging that has been tested and tweaked through several generations at this point. Can the Linux team overcome its own "NIH" issues and look at adopting this as an api for Linux apps? Ditto the *BSD teams. Certainly the GNUStep teams are looking into this, but I think the core teams need to be looking into it as well.
As a WebObejcts developer, I can attest to the fact that having such a single app bundle structure can make your life a lot easier. For instance, when you go to deploy a large app on a server, some security regimes require that the actual servers should not have development tools such as a compiler available on them (to make life more difficult for crackers). As a result, you need to do your build on a staging machine and then copy over all of the bits and pieces to the production machine. This process is much easier if all you need to do is tar up one or two directories, ftp them over, and then untar them, rather than digging through the various places where stuff could end up and ftp'ing them over one by one, and trying to make sure you got them all, because there's a lot of stuff in the/usr/share tree of your develoment machine.
For more info, look at the Mac OS X System Overview, on page 71, where the bundle format is specified. There's a lot more to it than just the format of the directory structure; there's also default search paths, versioning (for frameworks), and more.
Just so you know, I'm a Consulting Engineer with Apple iServices, but the opinons here are my own, not Apple's.
JMS has it exactly right -- the whole point of this is for the defense to get the plaintiff's witness to establish what he does and does not know, and thus what he can and cannot testify about. Furthermore, notice the whole back and forth about Schumann's educational background and those of his partners on pages 20 and 60. This is part of the effort to undermine and disqualify the the witness as an expert, or at least limit what he can testify to.
For some more substantive tidbits, I actually read the whole thing (I have an advantage, I'm used to doing this sort of thing -- I used to be a consulting economist and I have read many of these puppies). Aside from the nice chunk pulled out by inquis, they cover:
Region-coding and fast-forwarding
Acutal piracy using DeCSS
Schumann's knowledge of decrypted movies
Linking to pages with DeCSS
To start, here's a good chunk from inside around pages 82 and 83.
22 Q. Does DeCSS also have the function of
23 permitting a consumer who has purchased a DVD to 24 evade the region coding? 25 A. No.
INTERIM COURT REPORTING
83 1 Schumann 2 Q. Does DeCSS permit a consumer who has 3 purchased a DVD to fast-forward through sections of 4 a DVD that the manufacturer has prevented from 5 being fast-forwarded? 6 A. DeCSS itself? 7 Q. That's my question. 8 A. No. 9 Q. Does DeCSS enable someone to use 10 with some other program, like a DVD player, to skip 11 the region code? 12 A. I think it is irrelevant to that 13 problem. 14 Q. You think DeCSS is irrelevant to 15 that problem? 16 A. To the problem of evading region 17 code? 18 Q. Yes. 19 A. Yes. 20 Q. You have reviewed some of the 21 declarations that the defendants have submitted? 22 A. Yes, I have. 23 Q. In a Declaration if there is a 24 statement that says that DeCSS permits you to evade 25 region coding, a region coding limitation, then
INTERIM COURT REPORTING
84 1 Schumann 2 that statement is incorrect? 3 MR. GOLD: I object to the form. 4 Q. You can answer the question. 5 A. In my professional opinion, DeCSS is 6 irrelevant to evading the region coding, in your 7 terminology.
To summarize, Schumann has stated for the record that DeCSS is not intended to evade region coding or fast-forward through copyright notices and the like.
From pages 106-109:
13 Q. So you have no knowledge of any DVD 14 that was burned, that was allegedly ripped off, 15 ever sold? 16 A. Burned on an individual writer? 17 Q. Yes. 18 A. Personal knowledge, no. 19 Q. Burned on any kind of writer? 20 A. No. 21 Q. Since you have been employed by 22 Proskauer, have you had any conversations with the 23 MPAA about how many DVDs they believe were seen by 24 anybody as a result of DeCSS? 25 A. No.
INTERIM COURT REPORTING
107 1 Schumann 2 Q. Have you had any conversation with 3 Universal concerning that? 4 A. No. 5 Q. Other than Time Warner, putting them 6 aside, have you had any conversations with the 7 other plaintiffs concerning that? 8 A. No. 9 Q. Have you ever seen any MPAA records 10 indicate that they know of a DeCSS being used to 11 gain access to a DVD, particular access? 12 A. Is this different than your earlier 13 question? 14 Q. Yes. Talking about records now 15 rather than people. 16 A. I believe before lunch I said that I 17 had no knowledge of any records of any shape from 18 the studios, relative to -- I guess pirated movies. 19 I don't remember the exact question, but I think we 20 have went over this. I apologize, but I don't want 21 to waste any of our time. 22 Q. Have you ever seen any records that 23 Proskauer has -- 24 A. I have not. 25 Q. -- concerning whether or not they
INTERIM COURT REPORTING
108 1 Schumann 2 know of any particular case of DeCSS being used 3 with respect to DVDs? 4 A. I have not. 5 Q. Do you know if Proskauer or any of 6 the plaintiffs or the MPAA has retained any firm or 7 any third person to see the application or to 8 understand the application of DeCSS to DVDs? 9 A. I have no knowledge. 10 MR. GARBUS: Can I hear the last 11 question, please. 12 (Record read.) 13 BY MR. GARBUS: 14 Q. Do you know whether either Proskauer 15 or any of the plaintiffs had ever seen the DVD that 16 had been decrypted by DeCSS? 17 A. I have no knowledge. 18 Q. Have you ever seen any reports from 19 Proskauer or the MPAA or any of the plaintiffs 20 indicating whether or not they had ever seen the 21 DVD after the application of DeCSS? 22 A. You were referring to pirated DVDs 23 when you clarified? 24 Q. Yes. 25 A. I have no knowledge. INTERIM COURT REPORTING 109 1 Schumann 2 Q. Do you have any knowledge whether 3 anybody at the MPAA claims that there ever was a 4 pirated copy of a DVD sold, a copy that had been 5 enabled by the use of DeCSS? 6 A. I have no knowledge. 7 Q. Would your answer be the same with 8 respect to Proskauer and the seven plaintiffs in 9 this case, excluding Time Warner? 10 A. I believe so, yes.
So Schumann has does not know about (even secondhand) any DVDs that have been pirated using DeCSS; nor do the plaintiffs, the MPAA, or their lawyers.
From pages 119 and 120:
24 Q. Have you ever tried to make a
25 determination as to the quality of a film that is
INTERIM COURT REPORTING
120 1 Schumann 2 shown from an original DVD that is now being shown 3 because DeCSS has "broken the code"? 4 MR. GOLD: You can answer that 5 "yes or "no." 6 A. No. 7 Q. Do you know if anyone at the MPAA 8 ever has? 9 MR. GOLD: You can answer. 10 A. I have no knowledge. 11 Q. Do you know if anyone at the seven 12 plaintiffs, other than Time Warner, have? 13 A. I have no knowledge. 14 Q. Have you ever seen any reports from 15 either the MPAA or any of the other seven 16 plaintiffs? 17 MR. GOLD: Yes or no. 18 A. I have no knowledge.
So Schumann can't say anything about the quality of a video file after it's passed through DeCSS -- he can't contradict the Toronto Star article. It does not matter whether or not the MPEG file plays properly or not; only that Schumann can't say anything about them. Folks reading here will know that the bits from the file are the same after such a symmetric encryption/decryption, anyhow.
On pages 134-136:
22 Q. With respect to the Disney site, do
23 you know whether the Disney site links to any DeCSS 24 postings? 25 A. I have no knowledge.
INTERIM COURT REPORTING
135 1 Schumann 2 Q. To your knowledge, has anyone at the 3 MPAA tried to determine whether the Disney site 4 links to specific DeCSS postings? 5 A. I have no knowledge. 6 Q. Do you know what strings are? 7 A. Strings? 8 Q. Yes. 9 A. In the computer sense? 10 Q. Yes. 11 A. I believe so, yes. 12 Q. Tell me what they are. 13 A. Strings is typically a term used to 14 define a sequence of text characters. 15 Q. Do you know whether the Disney 16 search engine, for example, will do a search if you 17 put in DeCSS? 18 A. If Disney has a search engine, which 19 I will believe is true, I would presume it would. 20 Q. And do you know how many sites then 21 come up under the Disney search? 22 A. I have no knowledge. 23 Q. Is your answer "no knowledge," would 24 that be true with respect to any of the other 25 plaintiffs in this case?
INTERIM COURT REPORTING
136 1 Schumann 2 A. Yes, that's correct. 3 Q. Do you know if the Disney search 4 engine will take you to CSS.auth? 5 A. I have no knowledge. 6 Q. CSS.cat? 7 A. I have no knowledge.
Schumann doesn't know about Infoseek (owned by Disney, one of the plaintiffs) having links via their search engine to DeCSS, CSS.auth, etc.
There's some more stuff, but it does get repetitive after a while. Hope this helps some of the folks who are less legal-oriented.
Apple's WebObjects with Java Client technology may be exactly what you are looking for. WebObjects has a cross-platform server, (Mac OS X Server, WinNT, Solaris, HP-UX -- pure Java including Linux in the next version) plus a technology called Java Client, which allows you to instantiate a thick-client Java applet or application that can run on any Java 1.1.x platform, including MacOS/MRJ, Windows (various flavors), Solaris, Linux, or anything else which has the Swing 1.1.1 package available.
To expand a bit on this, WebObjects incorporates a technology called Enterprise Objects Framework (EOF). This is an object model-based way of interacting with your database. Rows in the database become translated into Java or Objective-C objects, which you can then message. Joins between rows in different tables in the database become pointer references between different objects. As a programmer, you never have to write a single line of SQL code; all SQL interaction with the database is generated on the fly for you by EOF as you work with your object model. I can personally attest that this can be a huge win for maintainability.
The Java Client part of this comes into play by extending the reach of EOF into a Java application running on the client machine. The Java Client app can request Enterprise Objects from the WebObjects server, and work with them transparently. You can code business logic into the EO's either on the server or on the client, depending on your requirements for security and interactivity.
Just to make it clear, I am a Consulting Engineer for Apple iServices, and an employee of Apple. This technology is my livelihood, and I know it well. That being said, I have also done Web development in Microsoft Active Server Pages and Perl cgi's, and I firmly believe that the WebObjects is a vastly more capable development environment than either of the two.
Also, don't forget that Apple has just slashed the price of WebObjects from $50,000 to $699; it's now also quite affordable.
Just to set the record straight, PDF is an open standard. There is NO licensing fee necessary to utilize the file format. As Apple has written its own PDF display engine, called Quartz, Apple owes no licensing fees to Adobe for the use of PDF, although it did owe them for the use of Display PostScript. The original comment in this thread should be moderated down to -1 as it contains definitely incorrect information presented in an inflammatory manner.
I'd like to take issue with the statement that "While work on the BSD-based OS X is moving along, no machines at FOSE were demonstrating the new OS"
I am an Apple WebObjects Consulting Engineer, and I was there all three days showing WebObjects 4.5 running on Mac OS X Server 1.2 on a G4/450. While this is not Mac OS X, currently scheduled for release this summer, it is a Mach 2.5+ based system with a BSD Unix layer. Most apps which can be configured for BSD will compile with just a "./configure" and a "make install" (I know how easy it can be, I've done bash and samba personally). Any source package that will currently compile on MOSXS 1.2 should work just fine with MOSX. With the Darwin project, the lowest levels of the OS (including the Mach 3.0 kernel and BSD layers) are available to outside developers.
That being said, Kai Staats showing off Yellow Dog and Black Lab Linux at FOSE was kewl. He told me that TerraSoft's site was slashdotted yesterday, so he's doing something right. Besides which, he helped feed the whole booth crew with lots of organic, vegetarian munchies during the prolonged pack-up and load out process. Thanx Kai!
--Paul Paul L. Suh Senior Consulting Engineer WebObjects Apple Computer psuh@apple.com
>IIRC, one of those new G3's (and remember, a G3 >consumes *way* less power than any (native) x86 >chip) can barely manage an hour and a half.
Actually, Apple claims that the current PowerBook G3 can run up 5 hours on one battery. See Apple's spec page. Independent reviews of the PB G3 give a "real life" work time of about 3 hourswhile playing a DVD. (Emphasis mine. 3 hours comes from playing Austin Powers twice, which has a run time of 90 minutes.) A table of the G3 processor's power modes shows that its typical power consumption is not terribly high compared to the TransMeta chips, given the older technology of the G3 and the large number of additional functional units in the G4:
PPC750 (G3) @ 400 MHz --Typical 5.8 W --Maximum 8.0 W PPC7400 (G4) @ ? --Typical 5 W --Maximum 8 W
Another way to look at this is what percentage of the laptop's power consumption is taken up by the CPU. On a PowerBook G3, we know that one battery holds 50 Watt-hours and the average battery life is 3 hours, so the average power consumption rate is: 50 / 3 = 16.67 Watts. Thus, 5.8 Watts of the power consumed is used by the CPU, and the remaining 10.87 Watts are consumed by the rest of the machine; this is a lot higher than the 4 Watts of other system power on TransMeta's web page and still significantly higher than the assumption of 8 Watts of other system power for the multimedia laptop. Using the TM3120 figure of 2.9 Watts for consumption while playing a DVD, the total power consumption of a hypothetical TransMeta-based laptop is 10.87 + 2.9 = 13.77 Watts, leading to a battery life of 50 / 13.77 = 3.6 hours, only 36 minutes longer than the current PowerBook G3. That's not a revolutionary difference, IMHO.
FWIW, I think that the TransMeta approach has very strong similarities to the AMD Athlon (in its on-the-fly translation of x86 instructions to the RISC-type internal instructions) and also to the Apple 68K emulator for its PowerPC-based machines and Java JITs (caching of the translated instructions after initial execution to speed execution the second time through). The weakness that I see of the TM approach is that they really are losing a fair chunk of the possible performance all of the time by their code-morphing approach. I personally don't see a lot of difference these days between a post-RISC superscalar architecture with strong branch prediction and speculative execution and a VLIW architecture with a translation unit on the front end that takes x86 instructions and turns them into VLIW instructions whose sub-pieces may be executing out of order. Both keep the functional units going a high percentage of the time.
Another weak spot may be that the x86 registers are only shadowed once. If an x86 exception occurs, there is a rollback followed by and in-order execution to figure out where to break for the exception. In post-RISC architectures (both PPC and Athlon), there is a plethora of registers, enough to easily support multiple processor states, not just two. Rollbacks due to exceptions and speculative execution are much less costly in this architecture.
Anyway, enough babbling from me. As a note, I am an Apple WebObjects engineer, but these views are my own. I just couldn't let some Furby;-) get away with giving a PowerBook G3 only 1.5 hours of battery life.
Slashdot Mirror
Upfront disclaimer: I work for Apple iServices, and was only peripherally involved with this project which was shifted to a different contractor shortly after I joined. Nevertheless, there was a wealth of information that was floating around the office at that time in terms of lessons learned, architectural discussions, etc.
CHCS and its follow-on, CHCS II, are electronic medical records systems for the U.S. Department of Defense that are supposed to do basically what your organization wants. It's a monstrously complex endeavour, spanning all of the major arms of service, so that records can follow an injured serviceman as he is moved to different locations -- e.g. a Marine is injured in an exercise in Norway, evacuated to the Air Force base hospital in Ramstein, Germany, eventually sent home to Bethesda Naval Medical Hospital, then sent for follow-up physical therapy at Walter Reed Army Medical Center. While this is more dispersed geographically than most situations, it is more a matter of scale than anything else. A medical records system will encounter similar issues and challenges as a patient moves from an emergency hostpital close to the scene of an accident to a hospital close to home for recuperation to their doctor's office to a physical therapy out-patient clinic.
Four things that you will need to consider as you look into systems are:
1) Patient confidentiality - Who has ownership of the records? Who should be allowed to see them? Who should be allowed to see them for a short time, and then cut off?
2) Ease of use - We got bit on the ass big-time by this one. Many physicians see their time as extremely valuable, and hate anything that takes more time than the current system for them. (I get the feeling that this is one reason why their handwriting is so bad on average -- they're rushing through the writeup.) Most of them are slow typists, so entering data into a screen, especially free-form notes, is a slow process for them. There was a lot of resistance to using the system as a result of this.
3) Scalability - To be blunt, this is an enterprise-scale task at the high end of things, and Linux and the *BSD's have not yet proven themselves to be players at this level. The requirements for availability, uptime, backup, etc. are such that you really ought to be looking at high-end Sun, IBM, HP, or similar sorts of systems. Forget about using mySQL -- it doesn't do ACID; any system needs to be based on something like Postgres, or a high-end commercial database like Oracle or Informix or Sybase.
4) Integration with legacy systems - This is a major task, as I am willing to be serious money that there are existing systems that have records for different departments in your hospital system. Some of them will be on relational DB's, but some will be on other sorts of systems based on M/MUMPS.
In summary, this is a major undertaking at an enterprise scale. The direct cost of the OS and other software will be a relatively small fraction of the cost. The lion's share of the cost will be from the necessary customization and systems integration that needs to happen, followed by the cost of the necessary systems administration and aftercare. Although open source software may give you peace of mind and low upfront acquisition costs, the fact of the matter is that you get what you pay for in this arena.
There are darn few organizations that have the money to burn like the Department of Defense, to do an entirely new project. There are existing medical records packages that operate at this scale designed to run on mainframes and the like. Even a high-end multi-processor Intel-based systems is no match for the truly enterprise scale systems that were designed that way from the ground up.
--Paul
Inheritance and Interfaces
Objective-C in the OpenStep/Mac OS X environment has single inheritance from a base class (NSObject), and protocols, which are precise counterparts to Java's interfaces. I have run into situations, however, where multiple inheritance is exactly what is required, and using interfaces meant that I had re-write the exact same code more than once, as I was implementing a group of specialized collection classes in Java. There were two axes of differentiation: mutability = (immutable, mutable), and ordering (partially ordered, ordered, strictly ordered). There was a lot of code that had to be duplicated that I should have been able to inherit from two abstract superclasses, one for mutability, and one for ordering. (*grumble*)
Garbage Collection and Memory Management
Objective-C provides a semi-automatic reference-counted garbage collection mechanism that is amenable to programmer intervention to increase efficiency, through a construct called an Autorelease Pool. Every object has a retain count, which can be incremented or decremented. The object's retain count starts at one, and when an object's retain count goes down to zero it is garbage collected. Note that this happens the instant that the retain count drops to zero, not during a mark/sweep. However, you may need to pass an object on to another part of your app, but your code does not need/want to retain it. What you do instead is tell the object to auto-release. It is then put into the autorelease pool, and later on during the system's garbage collection each object in the autorelease pool is sent a release message. Some objects that are entered in the autorelease pool still have a retain count (as they are being retained by other objects) and are simply removed from the autorelease pool; others have their retain counts drop to zero and are garbage collected.
You can fine-tune this mechanism to a high degree, by putting your own autorelease pool in the stack ahead of the system's primary autorelease pool. For instance, suppose you know that you will be allocating a whole bunch of objects for use in a part of your program, and after you exit you will never need them again. Well, you can put your own autorelease pool in for the system's autorelease pool at the start of that section of your code, write normal code, then remove and release your private autorelease pool and put back the system autorelease pool, which release all of the objects you created in your little section of code. Conversely, if you want an object to stick around, just don't ever release or autorelease it.
However, from a business standpoint, I find that the automated garbage collection and never having to worry about memory allocation issues is a strong point of Java. It allows me to code more complex applications and avoid memory debugging issues that invarable bedevil complex Objective-C and C++ programs. I can get a WebObjects application to a customer much more quickly using Java than using Objective-C, with quicker turnaround and more feedback cycles.
Events, Notifications, and Delegation
The OpenStep and Mac OS X operating systems (viewed separately from the Objective-C language, as these features are available from Java as well) have long had notifications and delegates. There is a system-wide notification center, objects can define notifications that they will post in response to certain events, and objects can register to receive particular events or classes of events. This mechanism has been in place for a long time.
Delegation is a bit more tightly tied to Objective-C, as objects in Obj-C can pass messages (i.e. method calls) onto to other objects, and objects can "pose as" other objects. An object can register to be the delegate of another object (in Java, the delegator object needs to make special provision for this), and there are "informal protocols" or "informal interfaces" defined that indicate the possible messages a delegate might receive from its delegator. Again, this is not new, and its assembly into a single OS is not new.
Primitive Types
This is one feature that I like very much, and wish that Java had. Objective-C, of course, will always have to support native types such as char's and int's, as it is defined as a superset of C. However, Java had the opportunity to remove this artificial distinction, and has caused lots of cursing from yours truly over the past couple of years.
Compiling to Native Code
I would point out here that compiling to native code may not result in the fastest execution. Review the HP Dynamo project, as written up on Ars Technica, for the reasons why JITC can actually exceed the speed of native code. The whole Transmeta Crusoe architecture is built around this theory of operation, and no one will claim that it's too slow.
Genericity
Amen to this. The fact that genericity is missing from Java is a serious gripe of mine, and the fact that it is missing from C# is a serious omission. This business of casting objects coming out of arrays is a pain the in neck, and it is often tough to find out where an object of the wrong type went into an array, although on the cast coming out you get a ClassCastException. Far better to catch the problem when the object goes in, which often gives you a better idea of where your design is broken. One of these days I am really going to have to start using the stuff coming out of the GJ project.
Conclusions
Overall, I find that the "new" stuff in C# is really old stuff. Furthermore, this is not the first time that all of this has been pulled together in one place. Almost all of this has been in the NeXTStep/OpenStep/Mac OS X family for a long time, and the implementations there are quite mature. I suspect that the implementations in C# will require several revisions before they reach the levels that programmers can really use.
Just so everyone knows, I am a Consulting Engineer working for Apple iServices, a part of Apple Computer, specializing in WebObjects development. These opinions are my own, however, and not those of Apple.
--Paul
Tenon's X server always runs full-screen, as the performance penalty for having the X Windows graphics essentially re-rendered by the Mac OS's QuickDraw architecture is very high (according to Tenon's own FAQ). Other X Windows implementations for the classic Mac OS -- such as MacX -- do offer "interleaved" X and QuickDraw windows, but run more slowly. Given the clunkiness of X Windows on my old 3400, even with Tenon's take-over-the-whole-screen approach, I'd say they're probably right. However, from a user experience point of view it is preferable to have fully interleaved X and native windows on the screen, in keeping with the ideal of having a non-modal interface.
Mac OS X has a completely different graphics architecture. If you look at Apple's Mac OS X System Overview, on page 52 there is a diagram of the graphics architecture. It has a box called "Core Graphics Services (window server)" that underlies the graphics rendering libraries, such as Core Graphics Rendering -- a.k.a. Quartz, QuickDraw, QuickTime, and OpenGL. None of the higher level graphics environments does any rendering to the screen directly -- it all goes through the window server layer. Adding X Windows to the mix in this environment simply means adding another box on top of the window server. To quote from page 53:
This is a horse of a very different color compared to running X Windows under the classic Mac OS. In the Mac OS X environment, the X Windows libraries can communicate directly to the window server, making true interleaved windows not only feasible but as fast as native Quartz- or QuickDraw-based windows.
--Paul
Disclaimer: I am an Apple iServices Consulting Engineer specializing in WebObjects, but I am not directly involved with the development of Mac OS X. My involvement with Tenon is strictly as an end user of Machten. The opinion posted here is strictly my own and not Apple's.
Actually, the graphical tools already do that, as far back as Mac OS X Server 1.0. There is a little lock icon on the control/preferences panels that require super-user access to change things. Changes are only allowed if you click on the lock icon and enter the root password. If you are already logged in as root, the lock is automatically open.
--Paul
This is an excellent thought, but, I think the opposite should be considered -- Apple (building on the work done at NeXT) has come up with a design for application resource packaging that has been tested and tweaked through several generations at this point. Can the Linux team overcome its own "NIH" issues and look at adopting this as an api for Linux apps? Ditto the *BSD teams. Certainly the GNUStep teams are looking into this, but I think the core teams need to be looking into it as well.
As a WebObejcts developer, I can attest to the fact that having such a single app bundle structure can make your life a lot easier. For instance, when you go to deploy a large app on a server, some security regimes require that the actual servers should not have development tools such as a compiler available on them (to make life more difficult for crackers). As a result, you need to do your build on a staging machine and then copy over all of the bits and pieces to the production machine. This process is much easier if all you need to do is tar up one or two directories, ftp them over, and then untar them, rather than digging through the various places where stuff could end up and ftp'ing them over one by one, and trying to make sure you got them all, because there's a lot of stuff in the
For more info, look at the Mac OS X System Overview, on page 71, where the bundle format is specified. There's a lot more to it than just the format of the directory structure; there's also default search paths, versioning (for frameworks), and more.
Just so you know, I'm a Consulting Engineer with Apple iServices, but the opinons here are my own, not Apple's.
--Paul
For some more substantive tidbits, I actually read the whole thing (I have an advantage, I'm used to doing this sort of thing -- I used to be a consulting economist and I have read many of these puppies). Aside from the nice chunk pulled out by inquis, they cover:
To start, here's a good chunk from inside around pages 82 and 83.
To summarize, Schumann has stated for the record that DeCSS is not intended to evade region coding or fast-forward through copyright notices and the like.
From pages 106-109:
So Schumann has does not know about (even secondhand) any DVDs that have been pirated using DeCSS; nor do the plaintiffs, the MPAA, or their lawyers.
From pages 119 and 120:
So Schumann can't say anything about the quality of a video file after it's passed through DeCSS -- he can't contradict the Toronto Star article. It does not matter whether or not the MPEG file plays properly or not; only that Schumann can't say anything about them. Folks reading here will know that the bits from the file are the same after such a symmetric encryption/decryption, anyhow.
On pages 134-136:
Schumann doesn't know about Infoseek (owned by Disney, one of the plaintiffs) having links via their search engine to DeCSS, CSS.auth, etc.
There's some more stuff, but it does get repetitive after a while. Hope this helps some of the folks who are less legal-oriented.
--Paul
Apple's WebObjects with Java Client technology may be exactly what you are looking for. WebObjects has a cross-platform server, (Mac OS X Server, WinNT, Solaris, HP-UX -- pure Java including Linux in the next version) plus a technology called Java Client, which allows you to instantiate a thick-client Java applet or application that can run on any Java 1.1.x platform, including MacOS/MRJ, Windows (various flavors), Solaris, Linux, or anything else which has the Swing 1.1.1 package available.
To expand a bit on this, WebObjects incorporates a technology called Enterprise Objects Framework (EOF). This is an object model-based way of interacting with your database. Rows in the database become translated into Java or Objective-C objects, which you can then message. Joins between rows in different tables in the database become pointer references between different objects. As a programmer, you never have to write a single line of SQL code; all SQL interaction with the database is generated on the fly for you by EOF as you work with your object model. I can personally attest that this can be a huge win for maintainability.
The Java Client part of this comes into play by extending the reach of EOF into a Java application running on the client machine. The Java Client app can request Enterprise Objects from the WebObjects server, and work with them transparently. You can code business logic into the EO's either on the server or on the client, depending on your requirements for security and interactivity.
Just to make it clear, I am a Consulting Engineer for Apple iServices, and an employee of Apple. This technology is my livelihood, and I know it well. That being said, I have also done Web development in Microsoft Active Server Pages and Perl cgi's, and I firmly believe that the WebObjects is a vastly more capable development environment than either of the two.
Also, don't forget that Apple has just slashed the price of WebObjects from $50,000 to $699; it's now also quite affordable.
--Paul
Just to set the record straight, PDF is an open standard. There is NO licensing fee necessary to utilize the file format. As Apple has written its own PDF display engine, called Quartz, Apple owes no licensing fees to Adobe for the use of PDF, although it did owe them for the use of Display PostScript. The original comment in this thread should be moderated down to -1 as it contains definitely incorrect information presented in an inflammatory manner.
--Paul
I'd like to take issue with the statement that "While work on the BSD-based OS X is moving along, no machines at FOSE were demonstrating the new OS"
I am an Apple WebObjects Consulting Engineer, and I was there all three days showing WebObjects 4.5 running on Mac OS X Server 1.2 on a G4/450. While this is not Mac OS X, currently scheduled for release this summer, it is a Mach 2.5+ based system with a BSD Unix layer. Most apps which can be configured for BSD will compile with just a "./configure" and a "make install" (I know how easy it can be, I've done bash and samba personally). Any source package that will currently compile on MOSXS 1.2 should work just fine with MOSX. With the Darwin project, the lowest levels of the OS (including the Mach 3.0 kernel and BSD layers) are available to outside developers.
That being said, Kai Staats showing off Yellow Dog and Black Lab Linux at FOSE was kewl. He told me that TerraSoft's site was slashdotted yesterday, so he's doing something right. Besides which, he helped feed the whole booth crew with lots of organic, vegetarian munchies during the prolonged pack-up and load out process. Thanx Kai!
--Paul
Paul L. Suh
Senior Consulting Engineer
WebObjects
Apple Computer
psuh@apple.com
>IIRC, one of those new G3's (and remember, a G3
;-) get away with giving a PowerBook G3 only 1.5 hours of battery life.
>consumes *way* less power than any (native) x86
>chip) can barely manage an hour and a half.
Actually, Apple claims that the current PowerBook G3 can run up 5 hours on one battery. See Apple's spec page. Independent reviews of the PB G3 give a "real life" work time of about 3 hours while playing a DVD. (Emphasis mine. 3 hours comes from playing Austin Powers twice, which has a run time of 90 minutes.) A table of the G3 processor's power modes shows that its typical power consumption is not terribly high compared to the TransMeta chips, given the older technology of the G3 and the large number of additional functional units in the G4:
PPC750 (G3) @ 400 MHz
--Typical 5.8 W
--Maximum 8.0 W
PPC7400 (G4) @ ?
--Typical 5 W
--Maximum 8 W
(Quoted from Motorola's PPC 750 info page and PPC 7400 info page. There is no figure given for the MHz of the G4 on the page.)
Another way to look at this is what percentage of the laptop's power consumption is taken up by the CPU. On a PowerBook G3, we know that one battery holds 50 Watt-hours and the average battery life is 3 hours, so the average power consumption rate is: 50 / 3 = 16.67 Watts. Thus, 5.8 Watts of the power consumed is used by the CPU, and the remaining 10.87 Watts are consumed by the rest of the machine; this is a lot higher than the 4 Watts of other system power on TransMeta's web page and still significantly higher than the assumption of 8 Watts of other system power for the multimedia laptop. Using the TM3120 figure of 2.9 Watts for consumption while playing a DVD, the total power consumption of a hypothetical TransMeta-based laptop is 10.87 + 2.9 = 13.77 Watts, leading to a battery life of 50 / 13.77 = 3.6 hours, only 36 minutes longer than the current PowerBook G3. That's not a revolutionary difference, IMHO.
FWIW, I think that the TransMeta approach has very strong similarities to the AMD Athlon (in its on-the-fly translation of x86 instructions to the RISC-type internal instructions) and also to the Apple 68K emulator for its PowerPC-based machines and Java JITs (caching of the translated instructions after initial execution to speed execution the second time through). The weakness that I see of the TM approach is that they really are losing a fair chunk of the possible performance all of the time by their code-morphing approach. I personally don't see a lot of difference these days between a post-RISC superscalar architecture with strong branch prediction and speculative execution and a VLIW architecture with a translation unit on the front end that takes x86 instructions and turns them into VLIW instructions whose sub-pieces may be executing out of order. Both keep the functional units going a high percentage of the time.
Another weak spot may be that the x86 registers are only shadowed once. If an x86 exception occurs, there is a rollback followed by and in-order execution to figure out where to break for the exception. In post-RISC architectures (both PPC and Athlon), there is a plethora of registers, enough to easily support multiple processor states, not just two. Rollbacks due to exceptions and speculative execution are much less costly in this architecture.
Anyway, enough babbling from me. As a note, I am an Apple WebObjects engineer, but these views are my own. I just couldn't let some Furby