Cookies don't work, they'd have to be set for each site. IP address doesn't work, they change and are shared. And what exactly is it people are worried about in the first place? That's what I don't get here... how is your privacy being violated if they don't know who you are?
If this is limited to advertising to people who are customers... that is, people who have some kind of relationship that would allow them to be identified... that would work. But it doesn't sound like that's what people are concerned about...
How is this different from the Microsoft Windows tax imposed on all OEMs even if they ship Linux?
1. You have to pay the Windows Tax even if you're not buying a device made by Microsoft (such as an XBox). 2. You don't have to pay the Mac Tax unless you're buying a device made by Apple (such as a Macintosh). 3. If you're not interested in running OS X, why the hell are you buying Apple's grotty kit?
I'm the first to argue that Apple's hardware isn't as overpriced as everyone claims, but this is one notable exception.
I'm sure someone could come up with a feature list that would make an XServe look competitive to a straw man "equivalent" box. Let's see, dual dual-core woodcrest plus *3* drive bays? Most 1U servers only have 2 bays, so that'll narrow things down... and don't forget, when you're comparing Mac and PC you don't worry if the PC is overspecced: you gotta have every feature of the Mac solution in the "equivalent" PC but the Mac never has to match up.
Apple's hardware has nice big margins, and PC hardware has razor-thin ones. That's reflected in the price.
The Mac Tax is the price you pay to get OS X. It's been worth the price for me, so far, but that doesn't mean it's not there.
QNX and BeOS are not UNIX. They certainly have some unix-like characteristics, but they aren't by a long shot.
QNX is based on POSIX, which is a UNIX API.
BeOS depends on the UNIX API to run: the shell is the UNIX shell, the utilities are UNIX utilities, the UNIX API is as native as the C++ one. You can treat a BeOS system as a UNIX system, run unmodified portable UNIX code on it, and it just works.
Plan 9's primary language is Aleph, but the Plan 9 C compiler came first and all the core UNIX API calls are there.
Windows has Posix compatibility (Posix.1) out of the box
The Windows POSIX subsystem is, as I already noted, not actually useful. I've also already mentioned Interix, but it's not shipped as part of the system... you can't write code for Interix and expect it to run on just any random Windows system... the UNIX API is not a Windows API. Even depending on UNIX semantics from main(ac, av) is fraught with peril, as the recent URI exploits on Windows demonstrate.
You also didn't say "general purpose OS", you said "no operating system in the world".
The context of the discussion is document formats, compatibility between applications, and what API to write new applications for. Why on earth do you expect me to be talking about embedded and legacy environments?
The bottom line is there are two effective platforms out there. One controlled by a single company that has a history of creating barriers and setting up boobytraps, the other that's completely out of any single company's control and that has proven itself secure from barratry and other legalistic shenanigans.
They REALLY need to have to option to give the guest account a password.
I wouldn't mind telling people that my guest account password is "satire", but I wouldn't want to leave my Mac in a state where anyone can walk up and log in without a password.
Hopefully Apple will think of these. This could be implemented regardless of the file system, without wating for ZFS, and would solve the two biggest problems:
1. Compression. Compress the files stored in Time Machine, in place, behind the scenes, with a header (or metadata, if you insist) indicating the original name and how it's compressed.
2. Deltas. Compare multiple versions of the file and store a compressed diff of the *older* one against the newest permanent version. Why the older one? Because it's the one that's going to be deleted first when the disk fills up.
Historically, Unix has only allowed hard links to files. In Leopard, Apple has included the ability to make hard links to directories.
Historically, hard links to directories were allowed in all versions of UNIX up until the mid-80s. Symlinks didn't show up until then and hard links to directories were removed after that. I have always thought that restricting hard links to files was a mistake... it doesn't cause any problems for file lookup (namei), but only for file enumeration (ftw). That happens in userland and maintaining two words (device and inode) for each directory in the path during a tree walk is not a great burden.
The kernel doesn't keep track of "whose" event(s) are being dropped.
Ah, so if it drops events, it doesn't drop the wrong events, but applications don't know that they haven't lost any events. That could be solved by an API to ask when the most recent dropped event happened. If you were already up to date, you wouldn't need to do any rescanning to figure out if you'd lost anything.
If it had to drop any, it sends a generic FSE_EVENTS_DROPPED notification to all registered processes.
That's a pretty standard UNIX model. That's how all process wakeups used to happen. If you can efficiently tell if you need to do anything, it's actually quicker to wake up all processes and have them check than to maintain queues. In a VM environment, of course, you don't want to wake up ALL processes but ones that are already doing real-time work? Sure.
I think they made the wrong decision here. Following the UNIX design would have been much more efficient than creating a new complex queue.
What the Leopard Finder no longer even attempts to do, however, is remember the view style for each folder (e.g., list view, icon view) unless explicitly asked to do so by the user.[...]In other words, while window size and position remain attributes of individual folders, view style is now a global attribute of the Finder application itself (optionally overridden by a per-folder setting that must be manually applied as described above).
First, this has nothing to do with "browser" versus "spacial" views. You can have per-folder view styles in browsers... even using his Safari analogy: changing something on a web page doesn't make all other web pages change. The Windows file manager is unrepentantly a browser, but it manages to keep per-folder changes.
Second, the lack of a per-folder view is what made me switch back to Finder from PathFinder. Even two generations of Finder ago, that by itself was enough to make me abandon the otherwise superior tool. Now Finder's losing it?
Hopefully this can be fixed with Applescripting or Automation, or at least a Haxie.
Just option-click on one of the circular "+" widgets to create a new nested clause.
Metakeys are evil. They are not discoverable, there's nothing that looking at the window will tell me that a metakey is available, and you can't explore them because you don't know what they do. They are useful as accelerators, perhaps, but requiring them to access any functionality is just plain wrong.
This is the biggest user-interface screwup on the Mac (and given what I think of the menu bar that's saying something) and it's one that's been there forever.
He's getting Apple's developer releases and he's spending a lot of time digging around in them. I don't always agree with everything he writes, but I can't fault his skill and diligence.
In the end, it still all comes down to trust. Either you trust software from Acme Inc., or you don't.
I don't. I trust that the particular program I downloaded is what I downloaded, and that's as far as it goes. I don't enable automatic updates. I don't run Software Update. I approve of being asked to update my keychain.
That's up to you to decide. Signed applications are just as capable of erasing your hard drive and stealing your passwords as unsigned applications.
Indeed. So they shouldn't be granted any more rights by default, including access to my keychain. If someone gets hold of Acme's key, I don't want to let them write a signed trojan that doesn't even need to install a keystroke logger to get my Acme password.
But unlike unsigned code, a signed application cannot be tampered with after installation. If an application from Acme Inc. does something malicious, you can be sure that it's not because it's been hijacked by some other bit of malware. Put another way, well-behaved code will continue to be well-behaved. Any attempt to modify it will stop it from running entirely.
I routinely go in and modify applications, fixing UI errors, replacing ugly bitmaps with better ones. And the debugger API means that applications can be modified without changing the signature on their code at all.
Signatures, like all crypto, are useful tools. But they're not a panacea, and like all crypto they can get in the way of other tools.
Apple is still recovering from the results of their decision to store critical metadata outside the visible file, in the resource fork, and even a single bit of critical metadata... the UNIX execute bit... has caused problems with older programs that don't preserve it. OS X doesn't live in the same kind of walled compound that Apple tried to keep Mac OS, so you can't expect programs to be written using Apple's frameworks. It's absolutely critical that all file system metadata be accessible through the same API as regular files, and on OS X that's open/read/write/close... I hope that Apple doesn't neglect this.
The kernel buffers are a fixed size, and if they fill up because of a slow client, events get dropped. This means that one badly behaved client can ruin it for everyone.
That doesn't follow. If the oldest events are dropped when the buffers fill up then only the slow client will miss events. Needs more explanation of this point.
AmigaOS was dead by 1997 QNX and BeOS are UNIX MacOS was a lame duck as of 1997... that's when Apple announced Yellow Box and Blue Box Plan9 is UNIX Netware is not a general purpose OS, even by the most relaxed standards The list goes on and on... UNIX or on life support.
I don't think that the lack of 64-bit Carbon support is as big a deal as he makes out, since a lot of Apple's own legacy code is still chock full of toasty Carbon flakes: Finder, iTunes, Safari... Apple's not going to do anything that makes things hard for these programs.
I think that, basically, his original statement about the unimportance of 64-bit is still true. 64-bit is STILL not an issue for all but a tiny fraction of programs. If iTunes and Finder and Safari *never* go 64-bit, who will notice? Not I.
If the performance difference of i386 and amd64 modes gets severe, they'll just compile 32-bit code in amd64 mode. That's how DEC solved 32-bit compatibility problems on the Alpha... you really can compile code that operates entirely as if it was 32-bit code on a 64-bit machine, and get all the extra registers. But given that they're going with Intel and not AMD, I think it's going to be a while before they have to care about that.
Unlike Windows, OSX does not run with services enabled unless you explicitly enable them.
It sounds like if you don't enable a service, it doesn't enable the firewall rules for that service. If you do enable the service, then it turns on the firewall rules for that service. This is not a problem unless you install a third-party program that provides the same network service, *and* you want to restrict access to it.
The argument in the article that the firewall would prevent a trojan from opening a listener on a low port is bogus, because any program that can open a listener on a low port can also remove the corresponding firewall rule... you have to be root to do either.
The fact that Samba processes were still running after sharing was turned off, however, is a concern. That absolutely should not happen, and Apple needs to fix it.
The workaround is to make sure that after you disable a service, you reboot to make sure it is really disabled. If you don't enable any services that should not be an issue.
I disagree. The fact that two of the top five US airlines still depend on OS2200 to fly (UAL with UNIMATIC, and NWA with WorldFLight, Cardinal, MSG, etc.), and that almost all of the rest worldwide would have serious issues if the OS2200 support infrastructure on which they depend were to go under (including several systems maintained and operated by my own employer) made the OS2200 platform somewhat more than a lame duck, IMO.
Again, I'm in the same boat, there's lots of legacy real time control systems that are very important. That doesn't mean the operating system they run on has a future outside existing installations.
Solaris is a desolate wasteland without third-party shells, editors, and other utilities as well.
Except it's not. I'd take Xenix-286 over Exec, let alone Solaris. In fact I did.
I figure that a given platform that is at least somewhat relevant if I can still make my living writing software for it.
I make my living writing and supporting control systems software. Until recently there wasn't even the option of using anything resembling UNIX in many embedded environments. But I'm not fooling myself that things like tight real-time executives in Forth are relevant to general purpose operating systems.
My point, in any case, is not that there's something wrong with legacy systems. The fact that Mentec, for example, is still actively supporting and maintaining RSX-11 is great.
The point that I was getting at is that there's two main platforms, now: UNIX, and Windows. UNIX has become so pervasive that systems that aren't part of the family by culture, inheritance, or marriage have almost vanished... and it got that way by being open. Windows got where it is by leveraging existing market share step by step from the original anointing of Microsoft by IBM... not by cooperating, interoperating, or otherwise playing nice.
That's how UNIX got where it is... to where people have to pull up systems that are as obscure as Forth or MUMPS to most people to come up with a system that's not affiliated with it... by playing nice. Open source needs to be very careful about shacking up with abusive spouses like Microsoft instead.
Incompatibility is not a valid form of activism when providing a consumer product.
I am not promoting incompatibility. I am not following in the path of the people who said "don't support MS-DOS file systems".
I am promoting the use of *native* formats that are not under the control of a company that has proven itself hostile to open source and has a history of using dirty tricks. I'm saying "don't depend on MS-DOS file systems".
The products in question are as compatible with the binary Office formats as they are with OOXML... that is the reason for the alleged support of OOXML, they can make their existing compatibility code work with OOXML just fine.
How is it a pity that Microsoft got involved in the OS?
They didn't do a very good job at designing their own operating systems. They did an excellent job at support and maintenance of Xenix, and for some years Xenix was the top small business computer system out there... primarily on the Radio Shack Model 6000. MS-DOS was a straight clone of CP/M, not even developed by them, and the Windows APIs has more fundamental design flaws than a wild dog has fleas.
They set the pace for the rest of the world.
I'm reminded of an old political cartoon, where a woman in a Model T is trying to pass some very fat men who are saying "madam, we're not standing in your way, we're setting your pace".
Microsoft set the pace all right. Conventional Wisdom in the mid '80s was that window systems were toys, because Microsoft didn't do them. Then concurrent multitasking was unsafe because Microsoft and Apple didn't do it. If they had actually been good at it, or someone who was good at it had been picked by IBM, we'd have had better operating systems sooner.
Microsoft won the technical war, and that's that.
Microsoft was late coming to the table, technically, in every case. They abandoned their attempts at multitasking MS-DOS years after MP/M was shipping. They didn't get into graphical user interfaces until Bill Gates saw the Mac under development... and rushed out to advertise "Windows" before line one of code was down on paper.
The personal computing revolution was a capitalist, consumerized venture- the idea of putting computers in every household is otherwise non-beneficial to the free software market, and frankly uneconomical.
The personal computer revolution was created by hobbyists in the '70s, not by big computer companies. The free software movement was born in that community, too, and created by the same people. They weren't two separate communities, there was one... and it was thriving long before Richard Stallman came along and tried to hijack it... perhaps if the capitalists in the free software movement hadn't been there things might have gone the way you're envisioning, but they were there long before the socialists, and if I didn't know that the mistaken impression you have of it had been so widely promoted I might take offense that you think I'm talking about the GNU brigade. Sheesh.
I feel Apple is quite right to close the security hole this represents.
The functionality that Apple restricted in Leopard is not anything that APE uses, nor is it anything that is required for APE to run... if it was, there wouldn't be a "blue screen" problem: APE simply wouldn't have loaded.
Input Managers are a completely separate issue from APE.
Input Managers are not a "security hole". The security hole is Apple's desire to allow people to install software directly from Safari, from Safari treating installers and plugins as "safe files" to the whole "Internet Enabled" disk image scheme. Adding more warning dialogs and trying to scare people away from using Input Managers isn't going to solve the problem. Keeping a strong distinction between private resources and public ones is the only way to keep the system secure.
I in fact did not describe DRM. I don't know how you see that, I described copy protection.
Copy protection is a form of DRM. In fact, copy protection is the form of DRM (whether labeled as such, or not) that is responsible for making DRM a "bad word".
What commercial software have you installed, by the way?
Microsoft and Apple started the PC revolution [...]
Digital Research and Radio Shack and Commodore and Atari had at least as much to do with it as Apple, though I'll grant that Microsoft Basic was pretty important. It's really a pity Microsoft didn't build off their strengths in compilers and interpreters instead of getting into the OS business.
The free software movement started back then, in the Software Tools group, in the pages of Doctor Dobbs' Journal and Byte magazine, in user groups all over the country. And what brought it together and made it effective was the increasing availability of this incredible new API that Bell Labs was publicising. AT&T and Bell Labs couldn't get into the computer business because of regulations and settlements that restricted them to the phone business, so they really did give their crown jewels away, irrevocably... as the two big two court cases since have amply demonstrated.
Compatibility with an open platform is what made it possible for us to be talking about what the free software movement "should" be doing now. If they'd all jumped on compatibility with CP/M and MS-DOS, where would we be now? Microsoft has a history of engulfing "compatible" systems... who uses OS/2 or DR-DOS now?
Rather than trying to be compatible with what Microsoft is doing, the main thing should be to be compatible with something that's not under Microsoft's control. Pushing OOXML over ODF, no matter what short term benefits it gets you, is just setting yourself up the bomb.
Slashdot Mirror
Cookies don't work, they'd have to be set for each site. IP address doesn't work, they change and are shared. And what exactly is it people are worried about in the first place? That's what I don't get here... how is your privacy being violated if they don't know who you are?
If this is limited to advertising to people who are customers... that is, people who have some kind of relationship that would allow them to be identified... that would work. But it doesn't sound like that's what people are concerned about...
How is this different from the Microsoft Windows tax imposed on all OEMs even if they ship Linux?
1. You have to pay the Windows Tax even if you're not buying a device made by Microsoft (such as an XBox).
2. You don't have to pay the Mac Tax unless you're buying a device made by Apple (such as a Macintosh).
3. If you're not interested in running OS X, why the hell are you buying Apple's grotty kit?
I'm the first to argue that Apple's hardware isn't as overpriced as everyone claims, but this is one notable exception.
I'm sure someone could come up with a feature list that would make an XServe look competitive to a straw man "equivalent" box. Let's see, dual dual-core woodcrest plus *3* drive bays? Most 1U servers only have 2 bays, so that'll narrow things down... and don't forget, when you're comparing Mac and PC you don't worry if the PC is overspecced: you gotta have every feature of the Mac solution in the "equivalent" PC but the Mac never has to match up.
Apple's hardware has nice big margins, and PC hardware has razor-thin ones. That's reflected in the price.
The Mac Tax is the price you pay to get OS X. It's been worth the price for me, so far, but that doesn't mean it's not there.
Without hardware OpenGL you wouldn't get the performance, and with pass-through OpenGL they'd have to support all the video drivers anyway.
QNX and BeOS are not UNIX. They certainly have some unix-like characteristics, but they aren't by a long shot.
QNX is based on POSIX, which is a UNIX API.
BeOS depends on the UNIX API to run: the shell is the UNIX shell, the utilities are UNIX utilities, the UNIX API is as native as the C++ one. You can treat a BeOS system as a UNIX system, run unmodified portable UNIX code on it, and it just works.
Plan 9's primary language is Aleph, but the Plan 9 C compiler came first and all the core UNIX API calls are there.
Windows has Posix compatibility (Posix.1) out of the box
The Windows POSIX subsystem is, as I already noted, not actually useful. I've also already mentioned Interix, but it's not shipped as part of the system... you can't write code for Interix and expect it to run on just any random Windows system... the UNIX API is not a Windows API. Even depending on UNIX semantics from main(ac, av) is fraught with peril, as the recent URI exploits on Windows demonstrate.
You also didn't say "general purpose OS", you said "no operating system in the world".
The context of the discussion is document formats, compatibility between applications, and what API to write new applications for. Why on earth do you expect me to be talking about embedded and legacy environments?
The bottom line is there are two effective platforms out there. One controlled by a single company that has a history of creating barriers and setting up boobytraps, the other that's completely out of any single company's control and that has proven itself secure from barratry and other legalistic shenanigans.
They REALLY need to have to option to give the guest account a password.
I wouldn't mind telling people that my guest account password is "satire", but I wouldn't want to leave my Mac in a state where anyone can walk up and log in without a password.
Hopefully Apple will think of these. This could be implemented regardless of the file system, without wating for ZFS, and would solve the two biggest problems:
1. Compression. Compress the files stored in Time Machine, in place, behind the scenes, with a header (or metadata, if you insist) indicating the original name and how it's compressed.
2. Deltas. Compare multiple versions of the file and store a compressed diff of the *older* one against the newest permanent version. Why the older one? Because it's the one that's going to be deleted first when the disk fills up.
Historically, Unix has only allowed hard links to files. In Leopard, Apple has included the ability to make hard links to directories.
Historically, hard links to directories were allowed in all versions of UNIX up until the mid-80s. Symlinks didn't show up until then and hard links to directories were removed after that. I have always thought that restricting hard links to files was a mistake... it doesn't cause any problems for file lookup (namei), but only for file enumeration (ftw). That happens in userland and maintaining two words (device and inode) for each directory in the path during a tree walk is not a great burden.
The kernel doesn't keep track of "whose" event(s) are being dropped.
Ah, so if it drops events, it doesn't drop the wrong events, but applications don't know that they haven't lost any events. That could be solved by an API to ask when the most recent dropped event happened. If you were already up to date, you wouldn't need to do any rescanning to figure out if you'd lost anything.
If it had to drop any, it sends a generic FSE_EVENTS_DROPPED notification to all registered processes.
That's a pretty standard UNIX model. That's how all process wakeups used to happen. If you can efficiently tell if you need to do anything, it's actually quicker to wake up all processes and have them check than to maintain queues. In a VM environment, of course, you don't want to wake up ALL processes but ones that are already doing real-time work? Sure.
I think they made the wrong decision here. Following the UNIX design would have been much more efficient than creating a new complex queue.
What the Leopard Finder no longer even attempts to do, however, is remember the view style for each folder (e.g., list view, icon view) unless explicitly asked to do so by the user.[...]In other words, while window size and position remain attributes of individual folders, view style is now a global attribute of the Finder application itself (optionally overridden by a per-folder setting that must be manually applied as described above).
First, this has nothing to do with "browser" versus "spacial" views. You can have per-folder view styles in browsers... even using his Safari analogy: changing something on a web page doesn't make all other web pages change. The Windows file manager is unrepentantly a browser, but it manages to keep per-folder changes.
Second, the lack of a per-folder view is what made me switch back to Finder from PathFinder. Even two generations of Finder ago, that by itself was enough to make me abandon the otherwise superior tool. Now Finder's losing it?
Hopefully this can be fixed with Applescripting or Automation, or at least a Haxie.
Just option-click on one of the circular "+" widgets to create a new nested clause.
Metakeys are evil. They are not discoverable, there's nothing that looking at the window will tell me that a metakey is available, and you can't explore them because you don't know what they do. They are useful as accelerators, perhaps, but requiring them to access any functionality is just plain wrong.
This is the biggest user-interface screwup on the Mac (and given what I think of the menu bar that's saying something) and it's one that's been there forever.
Talent and hard work.
He's getting Apple's developer releases and he's spending a lot of time digging around in them. I don't always agree with everything he writes, but I can't fault his skill and diligence.
In the end, it still all comes down to trust. Either you trust software from Acme Inc., or you don't.
I don't. I trust that the particular program I downloaded is what I downloaded, and that's as far as it goes. I don't enable automatic updates. I don't run Software Update. I approve of being asked to update my keychain.
That's up to you to decide. Signed applications are just as capable of erasing your hard drive and stealing your passwords as unsigned applications.
Indeed. So they shouldn't be granted any more rights by default, including access to my keychain. If someone gets hold of Acme's key, I don't want to let them write a signed trojan that doesn't even need to install a keystroke logger to get my Acme password.
But unlike unsigned code, a signed application cannot be tampered with after installation. If an application from Acme Inc. does something malicious, you can be sure that it's not because it's been hijacked by some other bit of malware. Put another way, well-behaved code will continue to be well-behaved. Any attempt to modify it will stop it from running entirely.
I routinely go in and modify applications, fixing UI errors, replacing ugly bitmaps with better ones. And the debugger API means that applications can be modified without changing the signature on their code at all.
Signatures, like all crypto, are useful tools. But they're not a panacea, and like all crypto they can get in the way of other tools.
Over two years later, Tiger has reached version 10.4.11
10.4.10, friend. Just because you have a seed of 10.4.11 doesn't mean it's out there for the rest of us.
Apple is still recovering from the results of their decision to store critical metadata outside the visible file, in the resource fork, and even a single bit of critical metadata... the UNIX execute bit... has caused problems with older programs that don't preserve it. OS X doesn't live in the same kind of walled compound that Apple tried to keep Mac OS, so you can't expect programs to be written using Apple's frameworks. It's absolutely critical that all file system metadata be accessible through the same API as regular files, and on OS X that's open/read/write/close... I hope that Apple doesn't neglect this.
The kernel buffers are a fixed size, and if they fill up because of a slow client, events get dropped. This means that one badly behaved client can ruin it for everyone.
That doesn't follow. If the oldest events are dropped when the buffers fill up then only the slow client will miss events. Needs more explanation of this point.
AmigaOS was dead by 1997
QNX and BeOS are UNIX
MacOS was a lame duck as of 1997... that's when Apple announced Yellow Box and Blue Box
Plan9 is UNIX
Netware is not a general purpose OS, even by the most relaxed standards
The list goes on and on... UNIX or on life support.
I don't think that the lack of 64-bit Carbon support is as big a deal as he makes out, since a lot of Apple's own legacy code is still chock full of toasty Carbon flakes: Finder, iTunes, Safari... Apple's not going to do anything that makes things hard for these programs.
I think that, basically, his original statement about the unimportance of 64-bit is still true. 64-bit is STILL not an issue for all but a tiny fraction of programs. If iTunes and Finder and Safari *never* go 64-bit, who will notice? Not I.
If the performance difference of i386 and amd64 modes gets severe, they'll just compile 32-bit code in amd64 mode. That's how DEC solved 32-bit compatibility problems on the Alpha... you really can compile code that operates entirely as if it was 32-bit code on a 64-bit machine, and get all the extra registers. But given that they're going with Intel and not AMD, I think it's going to be a while before they have to care about that.
Unlike Windows, OSX does not run with services enabled unless you explicitly enable them.
It sounds like if you don't enable a service, it doesn't enable the firewall rules for that service. If you do enable the service, then it turns on the firewall rules for that service. This is not a problem unless you install a third-party program that provides the same network service, *and* you want to restrict access to it.
The argument in the article that the firewall would prevent a trojan from opening a listener on a low port is bogus, because any program that can open a listener on a low port can also remove the corresponding firewall rule... you have to be root to do either.
The fact that Samba processes were still running after sharing was turned off, however, is a concern. That absolutely should not happen, and Apple needs to fix it.
The workaround is to make sure that after you disable a service, you reboot to make sure it is really disabled. If you don't enable any services that should not be an issue.
I disagree. The fact that two of the top five US airlines still depend on OS2200 to fly (UAL with UNIMATIC, and NWA with WorldFLight, Cardinal, MSG, etc.), and that almost all of the rest worldwide would have serious issues if the OS2200 support infrastructure on which they depend were to go under (including several systems maintained and operated by my own employer) made the OS2200 platform somewhat more than a lame duck, IMO.
Again, I'm in the same boat, there's lots of legacy real time control systems that are very important. That doesn't mean the operating system they run on has a future outside existing installations.
Solaris is a desolate wasteland without third-party shells, editors, and other utilities as well.
Except it's not. I'd take Xenix-286 over Exec, let alone Solaris. In fact I did.
I figure that a given platform that is at least somewhat relevant if I can still make my living writing software for it.
I make my living writing and supporting control systems software. Until recently there wasn't even the option of using anything resembling UNIX in many embedded environments. But I'm not fooling myself that things like tight real-time executives in Forth are relevant to general purpose operating systems.
My point, in any case, is not that there's something wrong with legacy systems. The fact that Mentec, for example, is still actively supporting and maintaining RSX-11 is great.
The point that I was getting at is that there's two main platforms, now: UNIX, and Windows. UNIX has become so pervasive that systems that aren't part of the family by culture, inheritance, or marriage have almost vanished... and it got that way by being open. Windows got where it is by leveraging existing market share step by step from the original anointing of Microsoft by IBM... not by cooperating, interoperating, or otherwise playing nice.
That's how UNIX got where it is... to where people have to pull up systems that are as obscure as Forth or MUMPS to most people to come up with a system that's not affiliated with it... by playing nice. Open source needs to be very careful about shacking up with abusive spouses like Microsoft instead.
Incompatibility is not a valid form of activism when providing a consumer product.
I am not promoting incompatibility. I am not following in the path of the people who said "don't support MS-DOS file systems".
I am promoting the use of *native* formats that are not under the control of a company that has proven itself hostile to open source and has a history of using dirty tricks. I'm saying "don't depend on MS-DOS file systems".
The products in question are as compatible with the binary Office formats as they are with OOXML... that is the reason for the alleged support of OOXML, they can make their existing compatibility code work with OOXML just fine.
How is it a pity that Microsoft got involved in the OS?
They didn't do a very good job at designing their own operating systems. They did an excellent job at support and maintenance of Xenix, and for some years Xenix was the top small business computer system out there... primarily on the Radio Shack Model 6000. MS-DOS was a straight clone of CP/M, not even developed by them, and the Windows APIs has more fundamental design flaws than a wild dog has fleas.
They set the pace for the rest of the world.
I'm reminded of an old political cartoon, where a woman in a Model T is trying to pass some very fat men who are saying "madam, we're not standing in your way, we're setting your pace".
Microsoft set the pace all right. Conventional Wisdom in the mid '80s was that window systems were toys, because Microsoft didn't do them. Then concurrent multitasking was unsafe because Microsoft and Apple didn't do it. If they had actually been good at it, or someone who was good at it had been picked by IBM, we'd have had better operating systems sooner.
Microsoft won the technical war, and that's that.
Microsoft was late coming to the table, technically, in every case. They abandoned their attempts at multitasking MS-DOS years after MP/M was shipping. They didn't get into graphical user interfaces until Bill Gates saw the Mac under development... and rushed out to advertise "Windows" before line one of code was down on paper.
The personal computing revolution was a capitalist, consumerized venture- the idea of putting computers in every household is otherwise non-beneficial to the free software market, and frankly uneconomical.
The personal computer revolution was created by hobbyists in the '70s, not by big computer companies. The free software movement was born in that community, too, and created by the same people. They weren't two separate communities, there was one... and it was thriving long before Richard Stallman came along and tried to hijack it... perhaps if the capitalists in the free software movement hadn't been there things might have gone the way you're envisioning, but they were there long before the socialists, and if I didn't know that the mistaken impression you have of it had been so widely promoted I might take offense that you think I'm talking about the GNU brigade. Sheesh.
I feel Apple is quite right to close the security hole this represents.
The functionality that Apple restricted in Leopard is not anything that APE uses, nor is it anything that is required for APE to run... if it was, there wouldn't be a "blue screen" problem: APE simply wouldn't have loaded.
Input Managers are a completely separate issue from APE.
Input Managers are not a "security hole". The security hole is Apple's desire to allow people to install software directly from Safari, from Safari treating installers and plugins as "safe files" to the whole "Internet Enabled" disk image scheme. Adding more warning dialogs and trying to scare people away from using Input Managers isn't going to solve the problem. Keeping a strong distinction between private resources and public ones is the only way to keep the system secure.
I in fact did not describe DRM. I don't know how you see that, I described copy protection.
Copy protection is a form of DRM. In fact, copy protection is the form of DRM (whether labeled as such, or not) that is responsible for making DRM a "bad word".
What commercial software have you installed, by the way?
Microsoft and Apple started the PC revolution [...]
Digital Research and Radio Shack and Commodore and Atari had at least as much to do with it as Apple, though I'll grant that Microsoft Basic was pretty important. It's really a pity Microsoft didn't build off their strengths in compilers and interpreters instead of getting into the OS business.
The free software movement started back then, in the Software Tools group, in the pages of Doctor Dobbs' Journal and Byte magazine, in user groups all over the country. And what brought it together and made it effective was the increasing availability of this incredible new API that Bell Labs was publicising. AT&T and Bell Labs couldn't get into the computer business because of regulations and settlements that restricted them to the phone business, so they really did give their crown jewels away, irrevocably... as the two big two court cases since have amply demonstrated.
Compatibility with an open platform is what made it possible for us to be talking about what the free software movement "should" be doing now. If they'd all jumped on compatibility with CP/M and MS-DOS, where would we be now? Microsoft has a history of engulfing "compatible" systems... who uses OS/2 or DR-DOS now?
Rather than trying to be compatible with what Microsoft is doing, the main thing should be to be compatible with something that's not under Microsoft's control. Pushing OOXML over ODF, no matter what short term benefits it gets you, is just setting yourself up the bomb.