A great example is component embedding. OpenOffice has a whitepaper up discussing the component models available on Unix systems.
Turns out you have:
+ The Gnome model (still in beta?)
+ The KDE model (different in KDE1 and KDE2 ?)
+ The Mozilla model
+ And now, the StarOffice model.
Meanwhile on Windows, you've got a single model, COM.
Now, tell me why a platform with maybe at best a 2% desktop marketshare needs 4 different ways of component embedding and a platform with 90% marketshare can get away with one.
And sure, there's always a good reason that you don't want to someone else's widget set. But, now, we are talking about fundemental interoperability issues. It's been possible to insert (say) a Excel chart into a WordPerfect document on Windows for nearly 7 years now. Will this sort of thing ever be possible on the tower of babel of Unix desktops?
But, yeah, I know emacs and pipes rule and nobody needs that stuff. --
Ummm, there were very real hardware limitations that brought about the comprimise solutions of Windows 9x and MacOS. It wasn't just developer fuckups.
You do have a point that once everyone is running Windows 2K/XP, MacOS X, or some Unix, the distinction between "server" and "desktop" OS is primarily one of utility, not of design. --
If you are looking for a history lesson, I think he was sort of dancing around the point about the 286. Turns out this was a braindamaged processor, but was insanely popular in the PC AT (1984) and IBM and their subcontractor Microsoft committed to shipping a next gen OS for it. This move politically kiboshed Microsoft's original plan which was to replace DOS with UNIX/XENIX.
This OS was OS/2 1.0, which shipped in 1987 as a 16-bit 286-specific OS to an enormous amount of hype, but unfortunately was already obsolete because i386 machines were already on the market from Compaq and others. It also put the dampers on IBM's big PS/2 Microchannel rollout, because IBM wouldn't ship a i386 CPU, and this led to the impression that the market leader was falling behind and sigificantly tarnished the sell of MCA as an advanced solution.
Anyway, the dumping of XENIX for OS/2, and the later (1990) IBM-Microsoft divorce (primarly over OS/2 development and marketing issues) set back the state of PC operating systems by a number of years. Meanwhile, Windows 3, which was always supposed to be a half-assed stopgap solution, got popular, and still to this day most PCs ship a direct decendant (WinME).
The fact that the Kerberos authors now say "oops, I guess we hadn't thought anybody would use that field" says nothing about standards compliance.
Actually, it's my understanding that The Open Group (you know, the guys who own the UNIX brandname) used that field for the exact same purpose as Microsoft (to hold authorization information) some years ago. --
True, but wasn't the RIAA founded specifically under an act of Congress that allowed this sort of thing? (mandatory copyright pooling and payment systems, that is). --
Note that the sybase fork happened 10 years ago (or more?) and was targetted for 16-bit OS/2 1.x. The product has been massively overhauled since, I'd bet that Microsoft is faster on NT.
You are correct that Sybase is probably the best way to port your stuff off of NT/MS-SQL to Unix. --
There's actually a good technical reason for this -- MS SQL is heavily optimised for the NT kernel (or so they say). According to Microsoft, this gives them a advantage on NT that other Unix-centric RDBMS vendors don't have (because they use a portability layer or a subset of Unix-like calls on NT).
Of course, this is at the cost of making MSSQL non portable, or forcing them to go through a similar compatibility layer, but that was a business decision. --
The PC* standards are primarily driven by Microsoft.
Of course they've been widely ignored before (for example, making parallel/serial "optional" before USB support shipped for NT). But they do serve to provide cover for OEMs to do certain things, such as get rid of ISA slots.
Nice theory, but the early OS/2 versions of 1-2-3 and WordPerfect sucked as much shit as the early Windows versions.
Microsoft had already been shipping Word and Excel on Windows 2.0 for a couple years, but more importantly, they had been shipping on the Mac for far longer and by 1991 they had a really good product to port over to Windows.
What killed Lotus and WordPerfect is that they never took GUI interfaces and the Mac seriously. --
This is beyond my expertise, but my understanding was that if your app runs on Cocoa or Carbon, you probably wouldn't be be directly using any Unix APIs at all (unlike your KDE/Gnome app which still makes Unix system calls).
How much Cocoa/Carbon actually depends on BSD versus straight Mach, I don't know.
Of course, it all boils down to kernel calls, but even in that respect, OS X's kernel isn't exactly the classic Unix model. --
Except that your ISP's TOS doesn't exactly allow you to become a "public carrier" (imagine if your neighbor was a spammer!).
Not to mention the real security problems that corporations face. The fact that you can stand in SF's financial district and get on some finance companies network is sorta scary from a security standpoint. (These guys are probably facist about analog phone jacks, but haven't clued into the fact that someone's iMac could be a huge security hole.) --
It's not the "general public" that Intel is worried about. It's all about risk-adverse IT managers who control large PC budgets. (And, yes, IT Managers are a huge marketing segment - watch the ads fly over Joe Sixpack's head during any TV sports event.) And it's worked in that corporate PC purchases are still primarily Intel, despite the clear price advantage of AMD.
Trying to market a component brandname to people who buy low-end consumer systems is no-go. These people don't know the difference between Microsoft and Compaq, much less some thing inside the box. --
To use the Windows term, the BSD layer is a "subsystem" in MacOS X. Since most users will never directly touch this susystem, nor run applications on it, it shouldn't really count.
It would be sorta like Microsoft saying that Windows 2000 was the best selling version of OS/2 ever, due to the fact that there's an OS/2 API layer hidden in there. --
The biggest traditional feature of MacOS has been the fact that it was tied very close to the hardware. (In fact for years, Apple didn't offically even admit that "The Macintosh" had an OS.)
Unfortunately, the designers took this to heart and didn't build enough abstraction layers into the operating system. Thus whenever they want to add support for new hardware, even just a new motherboard design, it by necessity meant a new code path. And guess what, the older path will eventually get dropped or forgotten.
Apple has been well aware of this problem since the era of clones and CHRP. However, the proposed fix was the Copland OS which never shipped. So hardware independance was just another goat sacraficed at the alter of Apple's R+D fuckups.
OS X should solve this problem of hardware abstraction and could potentially provide a lot more backcompatiblity in the future, if Apple wants it too. Note how it supposedly (unofficially) supports machines like the 8500, which I think were only officially supported during the Rhapsody beta period some years ago. --
and the people responsible for the Java push are no longer in decision-making positions. The Objective C lovers are running things again, and Objective C is the preferred development language for MacOS X.
Did someone tell marketing?* Apple is running "J2SE Development on Mac OS X" banner ads right now on Slashdot.
* This is Apple, so my guess is that the answer is No. --
The computation of the Pop Charts boggles the mind - it's supposedly based on singles sales (can you even buy singles anymore?) and radio airplay. Problem is that the classic 'top 40' format bases their airplay rotation on the pop charts. So we get a situation where it's easy to "make" a popular song just by seeding the system appropriately.
Every now and then, a "good" song will swirl up through luck and something-or-other. One example is Nirvana kicking Michael Jackson out of the #1 spot in the early 90s, with very little top 40 airplay and promotion. But it doesn't happen very often.
Another datapoint - Apparently whoever computes the charts excludes most rap singles sales (many of which are on indy labels in mom+pop record stores). If they were included, the Top 40 would be almost entirely rap. --
Right, however the IT department should be providing an encryption solution to users that they have proper backdoor access to.
If you are trying to hide something from management, the smart thing is to use your home computer with your home e-mail account and your home encryption key. Either that, or use Hushmail, but some outfits might bust you for that too. --
Notes does ask for your password (which in this case is also your passphrase) on start-up. This is used to decrypt your RSA private key (stored in your ID file). This is necessary because Notes uses strong encryption to authenticate you to the server and the server to you.
However, you can configure Notes to use a custom NT Gina to cache your NT password and use it to authenticate to Notes. This probably isn't as secure - particularlly because NT4 doesn't use a very strong hash to store passwords - but users hate having different passwords, so there you go.
If you encrypt or sign a message, it's automatically decrypted by other clients and verified. The sysadmin does not have direct access to the message, but likely has an archived copy of your ID with a known password, so he/she can impersonate you and get the message.
The sysadmin can also force all mail to be encrypted, or even force all RPC calls to the server to be encrypted (you can also force this for your client).
Notes encryption works very similarily to SMIME or PGP, uses strong RSA, and is generally considered to be good stuff. The problem is that all the mechanisms are proprietary, so it doesn't integrate well with other systems (such as Internet mail). This is mainly due to the fact that their infrastructure was put in the 1980s, so it predates things like SMIME by than 10 years or more.
Note that the huge deployed base of Notes in large corporations would make any government key recovery or storage plan a little problematic...
Alan Cox has admitted that he doesn't always publish security fixes in the change lists, and instead obscures the entry so that you have to be in the know to figure out that it's a security fix.
So, exactly how many security holes have been found in the Linux kernel is probably only known by Alan Cox and Linus. --
Well, if you are considering the Linux Admin culture, it's not just facination with the development process driving people.
Unix culture traditionally has been all that focused on security, as is evidenced by their coding styles and the fact that commercial vendors like Sun would ship ancient versions of key demons like Sendmail. This inattention to security created an opposed subculture dedicated to hacking Unix, which then has forced Unix admins to be very, very security conscious (particularlly because the vendors weren't). If you *know* that there's a 99% chance that you will be hacked, you *will* apply the patches.
Microsoft has always had lots of the same security issues, but until recently there hasn't been a dedicated effort to ferrit this stuff out. A couple years ago, there weren't that many known hacks for IIS, but any particular version of RedHat had rootscripts the day it came out. (Somebody posted a story here once where his Linux box got owned 5 minutes after installation.)
Now, the docs and the scripts are out there for NT, and the opportunity to get hacked has shot through the roof. The admins are slowly catching up to the extent that they have the smarts to do so. But, as with the Unix people, they're probably going to have to learn the hard way (by getting cracked). --
Whenever I read "Service Pack Foo broke alot of stuff", I have to write it down to one of those NT sysadmin anecdotes that are based more myth and fear than real facts. I know sites that are on NT4 SP4 because of "SP5 breaks lots of stuff". What stuff? Did you bother to check if it's your stuff?
The prime dunderhead Service Pack problem is backup software. Nine times out of ten, the sysadmin slapped the SP on a production server on the first day without giving the backup deamons a second thought. Well, no wonder it crashed, and no wonder he's permanently scared of new service packs for life.
And sure, there are real problems, such as SP3 having a massively overhauled kernel which introduced tons of bugs and memory hogging, SP5 changing the "LMCompatibility" level to remove cleartext passwords from the network (good thing, but who can bother reading the docs...), and of course the high port Lotus Notes/FoxPro thing in SP6. And there's been a few times when MS released a service pack, and then re-released it with the same number a week later. But all in all, with a little double-checking, service packs are ususally not that much of a problem. --
Not to mention Microsoft pushing the floor of the MCSE program so low that people who have never even used NT can pass the tests. (Guy at my friends company claimed to be an MCSE and then was befuddled by the mysterious Ctrl+Alt+Del prompt...)
And while we're on the topic, their documentation about security sucks ass. Well it's better than 2 years ago when it just plain didn't exist, but now it's nothing more than business user pap about 'planning' and with the word "firewall" thrown in here and there. You'd think the first thing in the manual and the MCSE class would be BLOCK PORT 139 (and 445 and 88 and...), but just try to get this information from Microsoft... --
Slashdot Mirror
A great example is component embedding. OpenOffice has a whitepaper up discussing the component models available on Unix systems.
Turns out you have:
+ The Gnome model (still in beta?)
+ The KDE model (different in KDE1 and KDE2 ?)
+ The Mozilla model
+ And now, the StarOffice model.
Meanwhile on Windows, you've got a single model, COM.
Now, tell me why a platform with maybe at best a 2% desktop marketshare needs 4 different ways of component embedding and a platform with 90% marketshare can get away with one.
And sure, there's always a good reason that you don't want to someone else's widget set. But, now, we are talking about fundemental interoperability issues. It's been possible to insert (say) a Excel chart into a WordPerfect document on Windows for nearly 7 years now. Will this sort of thing ever be possible on the tower of babel of Unix desktops?
But, yeah, I know emacs and pipes rule and nobody needs that stuff.
--
Ummm, there were very real hardware limitations that brought about the comprimise solutions of Windows 9x and MacOS. It wasn't just developer fuckups.
You do have a point that once everyone is running Windows 2K/XP, MacOS X, or some Unix, the distinction between "server" and "desktop" OS is primarily one of utility, not of design.
--
If you are looking for a history lesson, I think he was sort of dancing around the point about the 286. Turns out this was a braindamaged processor, but was insanely popular in the PC AT (1984) and IBM and their subcontractor Microsoft committed to shipping a next gen OS for it. This move politically kiboshed Microsoft's original plan which was to replace DOS with UNIX/XENIX.
This OS was OS/2 1.0, which shipped in 1987 as a 16-bit 286-specific OS to an enormous amount of hype, but unfortunately was already obsolete because i386 machines were already on the market from Compaq and others. It also put the dampers on IBM's big PS/2 Microchannel rollout, because IBM wouldn't ship a i386 CPU, and this led to the impression that the market leader was falling behind and sigificantly tarnished the sell of MCA as an advanced solution.
Anyway, the dumping of XENIX for OS/2, and the later (1990) IBM-Microsoft divorce (primarly over OS/2 development and marketing issues) set back the state of PC operating systems by a number of years. Meanwhile, Windows 3, which was always supposed to be a half-assed stopgap solution, got popular, and still to this day most PCs ship a direct decendant (WinME).
--
The fact that the Kerberos authors now say "oops, I guess we hadn't thought anybody would use that field" says nothing about standards compliance.
Actually, it's my understanding that The Open Group (you know, the guys who own the UNIX brandname) used that field for the exact same purpose as Microsoft (to hold authorization information) some years ago.
--
True, but wasn't the RIAA founded specifically under an act of Congress that allowed this sort of thing? (mandatory copyright pooling and payment systems, that is).
--
Note that the sybase fork happened 10 years ago (or more?) and was targetted for 16-bit OS/2 1.x. The product has been massively overhauled since, I'd bet that Microsoft is faster on NT.
You are correct that Sybase is probably the best way to port your stuff off of NT/MS-SQL to Unix.
--
The answer will be NO, I'm afraid.
A better question is "Will Microsoft make your Interix Unix-compability layer part of the standard Windows XP install instead of a add-on product?"
Or
"Will Microsoft be adding Linux binary-compatibilty to Interix?"
--
Softway Systems made a UNIX-branded subsystem for NT, so he is probably running same version Unix version of ?vi? as quite a few of you are.
He got bought out by Microsoft, and the product is currently available as Microsoft Interix (http://www.microsoft.com/windows2000/interix/).
--
There's actually a good technical reason for this -- MS SQL is heavily optimised for the NT kernel (or so they say). According to Microsoft, this gives them a advantage on NT that other Unix-centric RDBMS vendors don't have (because they use a portability layer or a subset of Unix-like calls on NT).
Of course, this is at the cost of making MSSQL non portable, or forcing them to go through a similar compatibility layer, but that was a business decision.
--
The PC* standards are primarily driven by Microsoft.
Of course they've been widely ignored before (for example, making parallel/serial "optional" before USB support shipped for NT). But they do serve to provide cover for OEMs to do certain things, such as get rid of ISA slots.
--
Nice theory, but the early OS/2 versions of 1-2-3 and WordPerfect sucked as much shit as the early Windows versions.
Microsoft had already been shipping Word and Excel on Windows 2.0 for a couple years, but more importantly, they had been shipping on the Mac for far longer and by 1991 they had a really good product to port over to Windows.
What killed Lotus and WordPerfect is that they never took GUI interfaces and the Mac seriously.
--
This is beyond my expertise, but my understanding was that if your app runs on Cocoa or Carbon, you probably wouldn't be be directly using any Unix APIs at all (unlike your KDE/Gnome app which still makes Unix system calls).
How much Cocoa/Carbon actually depends on BSD versus straight Mach, I don't know.
Of course, it all boils down to kernel calls, but even in that respect, OS X's kernel isn't exactly the classic Unix model.
--
May I join you in your dreamworld sometime?
--
Except that your ISP's TOS doesn't exactly allow you to become a "public carrier" (imagine if your neighbor was a spammer!).
Not to mention the real security problems that corporations face. The fact that you can stand in SF's financial district and get on some finance companies network is sorta scary from a security standpoint. (These guys are probably facist about analog phone jacks, but haven't clued into the fact that someone's iMac could be a huge security hole.)
--
It's not the "general public" that Intel is worried about. It's all about risk-adverse IT managers who control large PC budgets. (And, yes, IT Managers are a huge marketing segment - watch the ads fly over Joe Sixpack's head during any TV sports event.) And it's worked in that corporate PC purchases are still primarily Intel, despite the clear price advantage of AMD.
Trying to market a component brandname to people who buy low-end consumer systems is no-go. These people don't know the difference between Microsoft and Compaq, much less some thing inside the box.
--
To use the Windows term, the BSD layer is a "subsystem" in MacOS X. Since most users will never directly touch this susystem, nor run applications on it, it shouldn't really count.
It would be sorta like Microsoft saying that Windows 2000 was the best selling version of OS/2 ever, due to the fact that there's an OS/2 API layer hidden in there.
--
The biggest traditional feature of MacOS has been the fact that it was tied very close to the hardware. (In fact for years, Apple didn't offically even admit that "The Macintosh" had an OS.)
Unfortunately, the designers took this to heart and didn't build enough abstraction layers into the operating system. Thus whenever they want to add support for new hardware, even just a new motherboard design, it by necessity meant a new code path. And guess what, the older path will eventually get dropped or forgotten.
Apple has been well aware of this problem since the era of clones and CHRP. However, the proposed fix was the Copland OS which never shipped. So hardware independance was just another goat sacraficed at the alter of Apple's R+D fuckups.
OS X should solve this problem of hardware abstraction and could potentially provide a lot more backcompatiblity in the future, if Apple wants it too. Note how it supposedly (unofficially) supports machines like the 8500, which I think were only officially supported during the Rhapsody beta period some years ago.
--
and the people responsible for the Java push are no longer in decision-making positions. The Objective C lovers are running things again, and Objective C is the preferred development language for MacOS X.
Did someone tell marketing?* Apple is running "J2SE Development on Mac OS X" banner ads right now on Slashdot.
* This is Apple, so my guess is that the answer is No.
--
The computation of the Pop Charts boggles the mind - it's supposedly based on singles sales (can you even buy singles anymore?) and radio airplay. Problem is that the classic 'top 40' format bases their airplay rotation on the pop charts. So we get a situation where it's easy to "make" a popular song just by seeding the system appropriately.
Every now and then, a "good" song will swirl up through luck and something-or-other. One example is Nirvana kicking Michael Jackson out of the #1 spot in the early 90s, with very little top 40 airplay and promotion. But it doesn't happen very often.
Another datapoint - Apparently whoever computes the charts excludes most rap singles sales (many of which are on indy labels in mom+pop record stores). If they were included, the Top 40 would be almost entirely rap.
--
Right, however the IT department should be providing an encryption solution to users that they have proper backdoor access to.
If you are trying to hide something from management, the smart thing is to use your home computer with your home e-mail account and your home encryption key. Either that, or use Hushmail, but some outfits might bust you for that too.
--
Notes does ask for your password (which in this case is also your passphrase) on start-up. This is used to decrypt your RSA private key (stored in your ID file). This is necessary because Notes uses strong encryption to authenticate you to the server and the server to you.
However, you can configure Notes to use a custom NT Gina to cache your NT password and use it to authenticate to Notes. This probably isn't as secure - particularlly because NT4 doesn't use a very strong hash to store passwords - but users hate having different passwords, so there you go.
If you encrypt or sign a message, it's automatically decrypted by other clients and verified. The sysadmin does not have direct access to the message, but likely has an archived copy of your ID with a known password, so he/she can impersonate you and get the message.
The sysadmin can also force all mail to be encrypted, or even force all RPC calls to the server to be encrypted (you can also force this for your client).
Notes encryption works very similarily to SMIME or PGP, uses strong RSA, and is generally considered to be good stuff. The problem is that all the mechanisms are proprietary, so it doesn't integrate well with other systems (such as Internet mail). This is mainly due to the fact that their infrastructure was put in the 1980s, so it predates things like SMIME by than 10 years or more.
Note that the huge deployed base of Notes in large corporations would make any government key recovery or storage plan a little problematic...
--
Alan Cox has admitted that he doesn't always publish security fixes in the change lists, and instead obscures the entry so that you have to be in the know to figure out that it's a security fix.
So, exactly how many security holes have been found in the Linux kernel is probably only known by Alan Cox and Linus.
--
Well, if you are considering the Linux Admin culture, it's not just facination with the development process driving people.
Unix culture traditionally has been all that focused on security, as is evidenced by their coding styles and the fact that commercial vendors like Sun would ship ancient versions of key demons like Sendmail. This inattention to security created an opposed subculture dedicated to hacking Unix, which then has forced Unix admins to be very, very security conscious (particularlly because the vendors weren't). If you *know* that there's a 99% chance that you will be hacked, you *will* apply the patches.
Microsoft has always had lots of the same security issues, but until recently there hasn't been a dedicated effort to ferrit this stuff out. A couple years ago, there weren't that many known hacks for IIS, but any particular version of RedHat had rootscripts the day it came out. (Somebody posted a story here once where his Linux box got owned 5 minutes after installation.)
Now, the docs and the scripts are out there for NT, and the opportunity to get hacked has shot through the roof. The admins are slowly catching up to the extent that they have the smarts to do so. But, as with the Unix people, they're probably going to have to learn the hard way (by getting cracked).
--
Whenever I read "Service Pack Foo broke alot of stuff", I have to write it down to one of those NT sysadmin anecdotes that are based more myth and fear than real facts. I know sites that are on NT4 SP4 because of "SP5 breaks lots of stuff". What stuff? Did you bother to check if it's your stuff?
The prime dunderhead Service Pack problem is backup software. Nine times out of ten, the sysadmin slapped the SP on a production server on the first day without giving the backup deamons a second thought. Well, no wonder it crashed, and no wonder he's permanently scared of new service packs for life.
And sure, there are real problems, such as SP3 having a massively overhauled kernel which introduced tons of bugs and memory hogging, SP5 changing the "LMCompatibility" level to remove cleartext passwords from the network (good thing, but who can bother reading the docs...), and of course the high port Lotus Notes/FoxPro thing in SP6. And there's been a few times when MS released a service pack, and then re-released it with the same number a week later. But all in all, with a little double-checking, service packs are ususally not that much of a problem.
--
Not to mention Microsoft pushing the floor of the MCSE program so low that people who have never even used NT can pass the tests. (Guy at my friends company claimed to be an MCSE and then was befuddled by the mysterious Ctrl+Alt+Del prompt...)
...), but just try to get this information from Microsoft...
And while we're on the topic, their documentation about security sucks ass. Well it's better than 2 years ago when it just plain didn't exist, but now it's nothing more than business user pap about 'planning' and with the word "firewall" thrown in here and there. You'd think the first thing in the manual and the MCSE class would be BLOCK PORT 139 (and 445 and 88 and
--