Re:Linux rehashs 70s era OS.. wow, special.
on
A Praise To Unix
·
· Score: 1
I agree, as an Apple fan, for me, as a somebody who appreciates a good user interface and wants access to tools for development web-based software, the future of Unix does look like MacOS X. I am not impressed, so far, with most Linux GUIs, which seem to be about either aping Windows or being able to use themes. If a project like Eazel really can address the core usability and maintainance issues, maybe I will change my mind.
That said, the most promising avenues for Linux are in the server and embedded markets -- the second one isn't even really a promise but a fact. As for the server market, one disadvantage is the more freewheeling development and configuration model, as compared to a commercial Unix or the BSDs. On the other hand, vendors like IBM and SGI are putting significant resources and code behind Linux, and that's nothing to sneeze at.
NT Posix isn't a "thread," it's a subsystem -- basically, it's own little "world" that implements Posix to the letter but interact with the rest of the system pretty much only through the console, streams, files, sockets, and named pipes. (So you can pipe the output of a Posix program to a Win32 console program.) One example of NT's "to the letter" compliance is that NTFS has way to discriminate file names in a case-sensitive manner: Win32 programs don't use this feature, but Posix programs do.
When most folks port Posix programs to Win32 these days, they tend to use Posix libraries so that can still get at the Win32 API when they need it.
I think the idea is that if you're implementing a listener list from an event source, you should use weak references to the listener so that the listening object can still go away if it forgets to remove itself from the event source.
OS-level sandboxing (inside one process space) of a crude sort might also be possible on NT -- security privileges are maintained on a per-thread basis, and COM (upon which ActiveX is built) calls can be marshalled between threads. So in theory you could disable certain capabilities on a thread, the create the COM object on that thread. But it's pretty likely that ActiveXs excpect to the created on the message thread of their container, oh well...
I read bits of that thread, and having dealt with (meaning, actually wrote production code around) OLE, ActiveX, Notes, and a real office suite (Lotus Smartsuite), I submit the opinion that nobody in that thread who takes the MozOffice idea seriously has the slightest idea of what they're talking about or up against, should they even come upon with a coherent spec to implement. And the site is not even convincing as a vapor-project !
What they seem to want it some kind of magical context -sensitive universal container/editor -- fine, just redesign OpenDoc and OLE and make it work on a finer-grained level than anybody has ever attempted before. Piece of cake !
OLE 2 (which is really what is comparable to OpenDoc) on the Mac had already been working for a while before OpenDoc even got into beta.
At one point, Microsoft actually endorsed OpenDoc as an "OLE development tool," but Novell and IBM dropped the ball on the Windows implementation, and on not synching up with Apple on all the APIs.
But how to do you know you know the length of the final result (I think "target" is not the right word) string ? Unless there is some way to prove it, the destination buffer could, in theory, overflow. For example, even if one of the formatting arguments is a char[LENGTH], where LENGTH is a constant, it could be missing a null terminator ! snprintf will guard against that case.
Other languages considered integer overflow to be an exception. Once C took over the world, there was no reason for new (post-VAX) architectures to support this. As a result, it's more inefficient to do safe arithmetic on modern architectures now, even though we have cycles and cycles enough to spare.
Some companies (like the one I work for) use AIM for instant communication (especially between offices) -- it's cheaper and more reliable than using thep phone. We are starting to run into problems with AIM, such as:
The buddy list is stored locally on the client, so if you have more than one computer, you have to copy the list around. (Also, I beleive that the AOL.blt file format is or was not compatible between the MacOS and Windows clients). MSN and Yahoo keep your list on their servers.
There is a definite limit to how many buddies you can have.
When an employee joins, they need to get an ID (themselves) if the don't have one.
Ideally, what our company (and a lot of others) would like to do run our own IM network with easy-to-install hub software -- so that we can have control over our own policies and buddy lists, but still talk to the rest of the world. For example, all employees could be buddies of each other. The IM IDs could be the same as our email IDs, so there's one less thing for people to remember. One could imagine IM hubs that integrate with other authentication and message-related servers such as Exchange, Notes, LDAP, or Kerberos. Doing all of this is "possible" but rather pointless if there is not a single standard that all clients and hubs can agree upon.
Richard Stallman maintained the MIT Lisp Machine sources after the split with Symbolics in the early 80s. The GNU project is a direct consequence of what he took away from this whole sorry episode, which effectively killed the sharing of a great technology that was way ahead of its time.
Because of RMS's correct priorities for promulgating his ideas on free software, he choose a Unix style because, as much as he innovated in non-Unix areas (including TECO, Emacs, and the fabulous ITS operating system), he realized that Unix-like systems would have the virus-like qualities that would carry the GNU philosophy around the world. Even a Unix-hater could perceive that (most of them know Unix better than the fanboyz themselves).
Mentioning NeXT is a little ironic because one of the main authors of the Unix-Haters handbook, Simson Garfinkle, wrote for NeXTWorld. While it is true that NeXTStep was built on a Unix base, the NeXT APIs and UI design are pretty much non-Unix in philosophy, having more to do with Smalltalk, Lisp, and the Macintosh. A lot of Unix diehards really hated NeXTStep back in the day; my theory is that they were offended by a Unix variant that was more concerned with being compatible with people than being compatible with Unix design mistakes and seriously flawed Unix-associated software like X Windows.
Also, I beleive that whitehouse.org was running CL-HTTP, at least at first. Whoever said that there no http servers written in Lisp was making a losing bet -- it would probably be more difficult to make a list of computer languages and platforms for which web servers are not written !
Just one caveat: this is probably not the same product, but the VPN client that Nortel acquired from Bay Networks doesn't work with Windows 2000, and according to my IS guy, there is no ETA on a version that does. Grr !
Well, I guess I posted my note because I was under the perhaps naive impression that Mac OS X was not going to be a disaster. I admit that I haven't evaluated it yet, but I have a lot of experience with NeXTStep (as a user, at least) and have been following its progress on all the usual places on the net. Most of the negative comments I've seen on the net have to with the differences in the UI (as compared to Classic), not stability or performance.
If MacOS X is not a disaster, it will be the first credible, no excuses Unix-based OS for mortals. If it is, you will be vindicated and can reveal how smart you are.
Although the "other" book mentioned is probably not what I'm thinking of, I think ORA should do a MacOS X-oriented BSD book -- basically something that relates the command-line tools and the use of the filesytems (Macintosh HFS, BSD UFS) to the rest of MacOS X, and perhaps some material on how MacOS X's configuration design differs from traditional BSD.
Are these "official" screenshots in any way ? Because, if they are, then Eazel should at least teach their pimply-faced MP3-downloading wage slaves how to spell "Millenium."
But seriously, I am a little disappointed. Sure, it looks clunky, but Eazel isn't just about appearance, it's about making system maintenance easier. Unfortunately, either the screenshots can't show that, or there's no work to show yet.
While it's true that the Workspace object model is very nice, its visual polish and ease of use has fallen badly behind Windows and the Mac. I have gone nearly mad from navigating zillions of tabbed property pages, and the way the tabs themselves look and behave are pretty frustrating. In addition, either WM or PM doesn't enforce visual consistency, so you can tell when a feature or object emerged in OS/2 2, 3, or 4, depending on what it looks like. I haven't used Unix GUIs except for NeXTStep, so I don't know how they compare.
And while WM's SOM-based model is great, most users can get the same benefits from shell and OLE 2 integration under Win32 (coupled with the Windows Scripting Host), and host of APIs glued together with AppleScript on the Mac. As well are all too well aware, end user do not care about cleanliness of architecture. And sadly, OS/2 is basically the last refuge of SOM -- DSOM is dead, bascially, even though IBM should have pushed it as the best way to build CORBA objects, instead of using a rat's nest of specific language and ORB vendor CORBA bindings.
The most public uses of OS/2 these days are automated teller machines and cash registers. My local Stop & Stop's register's displays have that telltale PM "look," to them, and once I saw an ATM rebooting (after maintainance), and sure enough, it was running OS/2.
I expect that Linux, QNX, BSD, Windows CE (urg) will take over most of these roles, but probably not for a while.
I have programmed for the Win32 API since 1994 (yes, even Win32s on Windows 3.1) and this assertion is only about 5% true -- and even then, it's mostly driver writers who have to worry about such issues.
Compared to my experiences with Java AWT, OS/2, and what I've heard about shared C libraries under Linux, Win32 is consistent between all the various versions of Windows.
I'd like to know about the practical benefits of Darwin (i.e., not all the OS X stuff) *over* FreeBSD. There could be benefits from Mach, and perhaps Apple's new driver model is really part of Darwin as well. (In which case, could it be incorporated into Linux ?)
Some PCs can boot off the network. IBM supports or defines somemthing called the "Preboot Execution Environment" so that they can "netboot" a special version of OS/2. I suspect that this technique is IBM-specific and has nothing to do with standards such as Open Firmware.
Slashdot Mirror
That said, the most promising avenues for Linux are in the server and embedded markets -- the second one isn't even really a promise but a fact. As for the server market, one disadvantage is the more freewheeling development and configuration model, as compared to a commercial Unix or the BSDs. On the other hand, vendors like IBM and SGI are putting significant resources and code behind Linux, and that's nothing to sneeze at.
When most folks port Posix programs to Win32 these days, they tend to use Posix libraries so that can still get at the Win32 API when they need it.
I think the idea is that if you're implementing a listener list from an event source, you should use weak references to the listener so that the listening object can still go away if it forgets to remove itself from the event source.
OS-level sandboxing (inside one process space) of a crude sort might also be possible on NT -- security privileges are maintained on a per-thread basis, and COM (upon which ActiveX is built) calls can be marshalled between threads. So in theory you could disable certain capabilities on a thread, the create the COM object on that thread. But it's pretty likely that ActiveXs excpect to the created on the message thread of their container, oh well...
What they seem to want it some kind of magical context -sensitive universal container/editor -- fine, just redesign OpenDoc and OLE and make it work on a finer-grained level than anybody has ever attempted before. Piece of cake !
At one point, Microsoft actually endorsed OpenDoc as an "OLE development tool," but Novell and IBM dropped the ball on the Windows implementation, and on not synching up with Apple on all the APIs.
I don't use any commercial apps on Linux, but this brings up a good point -- if it works with 6.2, will it work in 7.0 without recompilation ?
So what does ESR have to say about this ?
But how to do you know you know the length of the final result (I think "target" is not the right word) string ? Unless there is some way to prove it, the destination buffer could, in theory, overflow. For example, even if one of the formatting arguments is a char[LENGTH], where LENGTH is a constant, it could be missing a null terminator ! snprintf will guard against that case.
Other languages considered integer overflow to be an exception. Once C took over the world, there was no reason for new (post-VAX) architectures to support this. As a result, it's more inefficient to do safe arithmetic on modern architectures now, even though we have cycles and cycles enough to spare.
An innocent question: what is the safe version of sprintf ?
Ideally, what our company (and a lot of others) would like to do run our own IM network with easy-to-install hub software -- so that we can have control over our own policies and buddy lists, but still talk to the rest of the world. For example, all employees could be buddies of each other. The IM IDs could be the same as our email IDs, so there's one less thing for people to remember. One could imagine IM hubs that integrate with other authentication and message-related servers such as Exchange, Notes, LDAP, or Kerberos. Doing all of this is "possible" but rather pointless if there is not a single standard that all clients and hubs can agree upon.
MSN Messenger already does it -- you can sign in as luser@hotmail.com, @passport.com, and so on.
Because of RMS's correct priorities for promulgating his ideas on free software, he choose a Unix style because, as much as he innovated in non-Unix areas (including TECO, Emacs, and the fabulous ITS operating system), he realized that Unix-like systems would have the virus-like qualities that would carry the GNU philosophy around the world. Even a Unix-hater could perceive that (most of them know Unix better than the fanboyz themselves).
Mentioning NeXT is a little ironic because one of the main authors of the Unix-Haters handbook, Simson Garfinkle, wrote for NeXTWorld. While it is true that NeXTStep was built on a Unix base, the NeXT APIs and UI design are pretty much non-Unix in philosophy, having more to do with Smalltalk, Lisp, and the Macintosh. A lot of Unix diehards really hated NeXTStep back in the day; my theory is that they were offended by a Unix variant that was more concerned with being compatible with people than being compatible with Unix design mistakes and seriously flawed Unix-associated software like X Windows.
Also, I beleive that whitehouse.org was running CL-HTTP, at least at first. Whoever said that there no http servers written in Lisp was making a losing bet -- it would probably be more difficult to make a list of computer languages and platforms for which web servers are not written !
Just one caveat: this is probably not the same product, but the VPN client that Nortel acquired from Bay Networks doesn't work with Windows 2000, and according to my IS guy, there is no ETA on a version that does. Grr !
If MacOS X is not a disaster, it will be the first credible, no excuses Unix-based OS for mortals. If it is, you will be vindicated and can reveal how smart you are.
Although the "other" book mentioned is probably not what I'm thinking of, I think ORA should do a MacOS X-oriented BSD book -- basically something that relates the command-line tools and the use of the filesytems (Macintosh HFS, BSD UFS) to the rest of MacOS X, and perhaps some material on how MacOS X's configuration design differs from traditional BSD.
But seriously, I am a little disappointed. Sure, it looks clunky, but Eazel isn't just about appearance, it's about making system maintenance easier. Unfortunately, either the screenshots can't show that, or there's no work to show yet.
While it's true that the Workspace object model is very nice, its visual polish and ease of use has fallen badly behind Windows and the Mac. I have gone nearly mad from navigating zillions of tabbed property pages, and the way the tabs themselves look and behave are pretty frustrating. In addition, either WM or PM doesn't enforce visual consistency, so you can tell when a feature or object emerged in OS/2 2, 3, or 4, depending on what it looks like. I haven't used Unix GUIs except for NeXTStep, so I don't know how they compare.
And while WM's SOM-based model is great, most users can get the same benefits from shell and OLE 2 integration under Win32 (coupled with the Windows Scripting Host), and host of APIs glued together with AppleScript on the Mac. As well are all too well aware, end user do not care about cleanliness of architecture. And sadly, OS/2 is basically the last refuge of SOM -- DSOM is dead, bascially, even though IBM should have pushed it as the best way to build CORBA objects, instead of using a rat's nest of specific language and ORB vendor CORBA bindings.
I expect that Linux, QNX, BSD, Windows CE (urg) will take over most of these roles, but probably not for a while.
Compared to my experiences with Java AWT, OS/2, and what I've heard about shared C libraries under Linux, Win32 is consistent between all the various versions of Windows.
MacOS X is more like NeXTStep than Classic; after all Cocoa is really what made NS NS, and it's still there. Not to mention Mach+BSD.
NeXTStep features even have popped up in MacOS 9. If you enter a bad password during login, the dialog box shakes back and forth, just like NeXTStep !
I'd like to know about the practical benefits of Darwin (i.e., not all the OS X stuff) *over* FreeBSD. There could be benefits from Mach, and perhaps Apple's new driver model is really part of Darwin as well. (In which case, could it be incorporated into Linux ?)
Some PCs can boot off the network. IBM supports or defines somemthing called the "Preboot Execution Environment" so that they can "netboot" a special version of OS/2. I suspect that this technique is IBM-specific and has nothing to do with standards such as Open Firmware.