Or just read the paper in question (first column, Acrobat page 63, page number 51: "Further, the process of transformation, even if it brings revolutionary change, is likely to be a long one, absent some catastrophic and catalyzing event - like a
new Pearl Harbor.").
And, conversely, few scientific applications wouldn't run as well on OSX--which presumably can compile most ANSI C and, if I'm not mistaken, has POSIX compliant libraries and so forth
Think of it as Yet Another BSD - it's a UNIX-flavored OS, just as are the other BSDs and Linux. (There are ways in which it differs from other UNIX-flavored OSes, but if there weren't at least one way in which it differs from other UNIX-flavored OSes, it wouldn't be UNIX-flavored.:-))
Ah, the benefits of a free market. When your access is partially or fully government subsidized, it can be plenty cheaper. We aren't getting screwed necessarily; we are paying for choice (even if it doesn't exist in your area).
So in what locales do people have the government-subsidized, no choice broadband to which you're referring? (Please supply references to back up any assertions that broadband in those locales is subsidized.)
SCO seems to be suggesting here that distribution under GPL automatically violates U.S. export restrictions.
No, SCO seems to be suggesting that exporting "the Software Products covered by this Agreement to any country that is currently prohibited from receiving supercomputing technology" violates U.S. export restrictions. "This Agreement" is the licensing agreement between SCO and the UNIX licensee to whom the letter was sent, and "the Software Products" are "the base System V release licensed by you", and "the UNIX software release based on UNIX System V prepared by your UNIX vendor" and "modifications to, or derivative works based on, any UNIX product made by you", to quote the letter.
So they're suggesting that exporting SV or derivatives thereof must not be exported to the countries in question, if it's done "through a distribution under the General Public License for Linux" or otherwise.
I.e., merely distributing stuff under GPL is, from their letter, not sufficient (that only applies to "any part of the Software Products covered by this Agreement", so you'd better not ship SV's cat or ls to any countries "currently prohibited from receiving supercomputing technology" as they might be using it to produce Weapons of Mass Destruction(TM) and not necessary ("or otherwise").
If Darwin would have enforced policy, Apple may not have been able to rename/bin Application, or/lib "Libraries".
Apple didn't rename/bin "Application" and didn't rename/lib - or, rather,/usr/lib - "Libraries", or, rather, "/Library"./bin,/usr/bin,/usr/lib, etc. still exist, along with/Applications and/Libraries.
For that matter, Microsoft didn't rename C:\WINNT\System32....
The real question is what pieces really depend on the BSD layer being there, not what address space it runs in.
Everything that accesses files or sockets does; there are UNIX APIs at the bottom of that pile.
(Note that, for example, an NSFileHandle has a "fileDescriptor" message to get the underlying UNIX file descriptor; "initWithFileDescriptor" can, for example, be used on the return from "socket()", so when they say "file descriptor" they mean "UNIX file descriptor".)
Note that Mac OS X uses the term kernel somewhat differently than you might expect.
"A kernel, in traditional operating-system terminology, is a small nucleus of software that provides only the minimal facilities necessary for implementing additional operating-system services." -- from The Design and Implementation of the 4.4 BSD Operating System, McKusick, Bostic, Karels, and Quarterman, 1996.
Similarly, in traditional Mach-based operating systems, the kernel refers to the Mach microkernel and ignores additional low-level code without which Mach does very little.
In Mac OS X, however, the kernel environment contains much more than the Mach kernel itself. The Mac OS X kernel environment includes the Mach kernel, BSD, the I/O Kit, file systems, and networking components. These are often referred to collectively as the kernel. Each of these components is described briefly in the following sections. For further details, refer to the specific component chapters or to the reference material listed in the bibliography.
(emphasis mine, except for the boldfacing of "Important").
I.e., they're contrasting "traditional Mach-based operating systems" with Mac OS X.
Actually, the money would be spent on accountants, tax attourneys and lobbyists to avoid the tax.
Just out of curiosity, how is (was) the money spent in Finland, France, Iceland, Luxembourg, Norway, Spain, Sweden, or Switzerland, which had a wealth tax as of 1999? (See The Wealth Tax and Economic Growth, by Asa Hansson of the Lund University Department of Economics.)
An OS X PDF renderer in Safari would be better than the Acrobat plug-in.
In some ways, yes. At least for me, however, it'd be worse than just showing the document in Preview - and, in the area about which I complained, namely the space taken up by the browser and PDF view toolbars not being available to show me the page I'm viewing, no better than the Acrobat plugin. (Yes, I know Cocoa uses PDF natively. That's presumably how Preview displays it.)
I'm *really* hoping that they figure out a way to integrate Preview's PDF-rendering abilities into Safari, so that we can finally have a decent plugin to view PDF's inside the browser on OS X!
And I'm really hoping that if they do, they also offer a way to tell Safari not to render PDFs inside the browser - I went through some effort to keep the Acrobat Reader plugin from working on Windows, because, for many PDFs, if it's big enough for me to read, it's too big to fit in a browser window and show the entire page, given all the browser *and* Acrobat Reader toolbars.
The reason why not much is given back (if thats even the situation) would be due to the fact that the OSes are completely different in design. A monolithic kernel as opposed to a microkernel... c'mon, these are totally different.
No, not completely different. Take a look at the Darwin kernel; rather a lot of the code under the "bsd" directory is not all that different from the versions in other BSDs. xnu isn't a small kernel plus a pile of servers (but then neither is NT, really - the Win32 subsystem does do a fair amount of stuff, but file system stuff and networking stuff, for example, is all done in kernel mode in NT; "NT" here includes NT 5.0, 5.1, and 5.2, i.e. W2K, WXP, and W2K3 Server).
In all honesty, I don't think FreeBSD has much interest in Mac OS X code unless its aqua or quartz.
It's not case-insensitive, it's case-preserving. There is a difference. Saying it's case-insensitive is just as wrong as saying it's case-sensitive.
OK, so what are the correct descriptions of:
a file system that allows "FOO" and "foo" to be separate files;
a file system that doesn't allow "FOO" and "foo" to be separate files, does file name lookups that ignore the case of letters, but preserves the case on a create;
a file system that doesn't allow "FOO" and "foo" to be separate files, does file name lookups that ignore the case of letters, and forces the case on create to all upper-case (or all lower-case).
The first and second of those are both "case-preserving", in the sense that the case of letters in a file name is the case that was supplied in the name when the file was created; the first of those is the behavior of most UNIX file systems, and the second of those is the behavior of HFS+, VFAT, and NTFS (when NTFS is accessed via Win32). Saying HFS+ is "case-preserving" in that sense is correct - but it doesn't distinguish it from UFS, which is also "case-preserving" in that sense.
So do you use "case-preserving" to refer only to file systems where lookups ignore case and creates preserve case, reserving "case-insensitive" for file systems (e.g., 8.3 FAT) where lookups ignore case and creates don't preserve case?
If so, you may find that others don't; they might use "case-sensitive" vs. "case-insensitive" to describe the behavior on lookups and "case-preserving" vs. "non-case-preserving" (or whatever) to describe the behavior on creates, so that the first file system type is "case-sensitive" (and "case-preserving"), the second file system type is "case-insensitive and case-preserving", and the third file system type is "case-insensitive and non-case-preserving".
Actually, case-sensitivity vs. case-insensitivity is often a file system issue, not an OS issue. OS X has file systems that are case-sensitive (e.g., UFS), file systems that are case-insensitive (e.g., HFS+), and file systems where the case sensitivity depends on the server's behavior (e.g., NFS and smbfs).
As has automounting, so I hear. But NOT &*%&*$%$ SAMBA!!!!!!!!
Samba's an SMB server, which is what OS X uses to provide SMB service to clients using SMB; are you saying it has problems with disconnecting from clients?
Or are you saying OS X's SMB client (not Samba-derived, but FreeBSD-derived) doesn't have improved disconnection support in Panther?
Authentication/Network Layer/Filesystem/transports should all be seperate things, IMO.
They are, at least for the latter 3 in your list. SMB runs atop various implementations of NetBIOS services, which, in turn, run atop TCP and UDP running in turn atop IP, as well as atop the NetBEUI frame layer running atop 802.2 running atop 802.3 and 802.5 and probably other link layers, as well as atop various other transports.
Authentication is somewhat tied into SMB, although Microsoft are using their mutant version of Kerberos now as well as various NTLM versions.
Samba is rock-solid, so there is no reason it could not be made to work well within the OSX gui environment if the effort were made by Apple.
You realize, of course, that the SMB *client* VFS code in Mac OS X is *not* from Samba, right? (The Linux SMB client VFS code isn't from Samba, either. Samba is *NOT* the be-all and end-all of SMB support on UNIX-flavored OSes; it's the most common SMB *server* for those OSes, but it's not the source of the VFS SMB clients in FreeBSD and Linux.)
1) The init system has small concessions to being a services framework rather than just a "boot-up-tool", but it really only provides the ability to start/stop/restart services. We need a system that is both more featureful and and more robust, esp. for desktop integration, but its nice all around. For an example of robustness, if a service can't start (or if it crashes at some point!)... the interface needs to get an "exception" with an error code and a message. For an example of a feature: we need integration with xinetd so you can flip a checkbox to switch a service between "run on demand" (xinetd) or "run always" (daemon).
which addresses an issue that might also apply to non-desktop systems, i.e. starting/stopping/restarting services after system startup. (Note that the System V rc scheme, Mac OS X scheme, and rc.d/rcNG scheme have a similar notion, i.e. in those schemes you have scripts to start/stop/restart services, and one time that they happen to be run is at startup time, from init, but they can also be run once the system has started.)
As someone else noted (in an article with a link done as text, not as an , and with an extra blank in it), Mac OS X has a possibly-interesting scheme for starting and stopping system services. Here's the section on System Initialization in the Mac OS X online documentation; in particular, look at the Startup Items stuff.
Note also that Boring Old Init isn't itself changed;/etc/rc runs SystemStarter as its last act, and that starts up the system services. SystemStarter can also be used as a command to start, stop, or restart services, so this isn't just a system startup mechanism.
(Note that all of those systems have a BSD-style init, and thus don't have run levels.)
Those schemes don't address one of Seth's complaints, however - according to his description in his blog, he doesn't like having shell script wrappers doing the configuration, he wants it done in the service's process itself:
In other news, reshaped SystemServices around the futile, idealistic goal of having daemons contribute the servicesinstead of silly little shell script wrappers in the future. Ever poked through RH's/etc/init.d/ scripts? Its absurd... they do so much stuff in there that should be included in the bloomin' C code. If you need a check for something, just have the program itself do it.... But of course, these programs were designed to be run with lots of magic brittle flags rather than running and situating themselves intelligently.
(I express no opinion on this one way or the other; if you like or don't like the idea, send bouquets or brickbats to him, not me.)
Note also that it appears that he is not designing something just for desktops - in particular, he says:
The boot process: So first the kernel loads itself, and calls ServiceManager (instead of "init"). The ServiceManager starts the DBus service manually,
and checks to see if it should be doing a graphical bootup. If it should be, it starts the GraphicalLogin service (which of course may have dependencies to start first).
Now, whether the kernel should start ServiceManager directly, or whether it should continue to run init and have ServiceManager started from an rc file, is another issue; I'm not sure that there's a compelling argument to eliminate init other than to discourage people from continuing to use the current rc script scheme (which might be Seth's motivation for running ServiceManager as process 1 - he might want to discourage rc script tweaking).
Perhaps one of the reasons why people thought of ServiceManager as being purely for desktop systems is that they thought that, as D-BUS is somewhat associated with freedesktop.
Re:There's more to it than 64-bit instructions
on
Is Prescott 64-bit?
·
· Score: 1
Actually, userspace code can access 36 bits of memory. It just has to span multiple protection domains in order to do it.
...or use mmap(). (I'd say "...mmap() or MapViewOfFile(), but I'm not sure any version of Windows treats memory above 4GB the same way it treats the first 4GB. There might be non-UNIXy OSes that support it as well, so maybe there are other APIs that can be used.)
(I note that Jim Carrey also shows up in that list....)
However, as you've also given us Neil Young, I'm willing to let the rest of them slide. (Huevos Rancheros gets you extra credit. I'd list others, but I'm not about to spend tons of time plowing through that site....)
Slashdot Mirror
Or just read the paper in question (first column, Acrobat page 63, page number 51: "Further, the process of transformation, even if it brings revolutionary change, is likely to be a long one, absent some catastrophic and catalyzing event - like a new Pearl Harbor.").
Think of it as Yet Another BSD - it's a UNIX-flavored OS, just as are the other BSDs and Linux. (There are ways in which it differs from other UNIX-flavored OSes, but if there weren't at least one way in which it differs from other UNIX-flavored OSes, it wouldn't be UNIX-flavored. :-))
Are you certain that N10 wasn't the Intel code name for the i860?
So in what locales do people have the government-subsidized, no choice broadband to which you're referring? (Please supply references to back up any assertions that broadband in those locales is subsidized.)
No, SCO seems to be suggesting that exporting "the Software Products covered by this Agreement to any country that is currently prohibited from receiving supercomputing technology" violates U.S. export restrictions. "This Agreement" is the licensing agreement between SCO and the UNIX licensee to whom the letter was sent, and "the Software Products" are "the base System V release licensed by you", and "the UNIX software release based on UNIX System V prepared by your UNIX vendor" and "modifications to, or derivative works based on, any UNIX product made by you", to quote the letter.
So they're suggesting that exporting SV or derivatives thereof must not be exported to the countries in question, if it's done "through a distribution under the General Public License for Linux" or otherwise.
I.e., merely distributing stuff under GPL is, from their letter, not sufficient (that only applies to "any part of the Software Products covered by this Agreement", so you'd better not ship SV's cat or ls to any countries "currently prohibited from receiving supercomputing technology" as they might be using it to produce Weapons of Mass Destruction(TM) and not necessary ("or otherwise").
Apple didn't rename /bin "Application" and didn't rename /lib - or, rather, /usr/lib - "Libraries", or, rather, "/Library". /bin, /usr/bin, /usr/lib, etc. still exist, along with /Applications and /Libraries.
For that matter, Microsoft didn't rename C:\WINNT\System32....
Are you referring to this work at Harvard Medical School?
Everything that accesses files or sockets does; there are UNIX APIs at the bottom of that pile.
(Note that, for example, an NSFileHandle has a "fileDescriptor" message to get the underlying UNIX file descriptor; "initWithFileDescriptor" can, for example, be used on the return from "socket()", so when they say "file descriptor" they mean "UNIX file descriptor".)
No - this page from the Kernel Architecture Overview says:
(emphasis mine, except for the boldfacing of "Important").
I.e., they're contrasting "traditional Mach-based operating systems" with Mac OS X.
Just out of curiosity, how is (was) the money spent in Finland, France, Iceland, Luxembourg, Norway, Spain, Sweden, or Switzerland, which had a wealth tax as of 1999? (See The Wealth Tax and Economic Growth, by Asa Hansson of the Lund University Department of Economics.)
...as its SMB server, but not as its SMB client.
For one thing, Samba is an SMB server; the client that comes with it is a command-line program similar to ftp, not a VFS.
For another thing, the Panther SMB client is derived from the FreeBSD one; see man mount_smbfs (Boris Popov wrote the FreeBSD SMB client).
In some ways, yes. At least for me, however, it'd be worse than just showing the document in Preview - and, in the area about which I complained, namely the space taken up by the browser and PDF view toolbars not being available to show me the page I'm viewing, no better than the Acrobat plugin. (Yes, I know Cocoa uses PDF natively. That's presumably how Preview displays it.)
And I'm really hoping that if they do, they also offer a way to tell Safari not to render PDFs inside the browser - I went through some effort to keep the Acrobat Reader plugin from working on Windows, because, for many PDFs, if it's big enough for me to read, it's too big to fit in a browser window and show the entire page, given all the browser *and* Acrobat Reader toolbars.
Nope:
It's always case-insensitive (unless you've constructed a case-sensitive HFS+) - there's no BSD shell vs. Finder difference.
No, not completely different. Take a look at the Darwin kernel; rather a lot of the code under the "bsd" directory is not all that different from the versions in other BSDs. xnu isn't a small kernel plus a pile of servers (but then neither is NT, really - the Win32 subsystem does do a fair amount of stuff, but file system stuff and networking stuff, for example, is all done in kernel mode in NT; "NT" here includes NT 5.0, 5.1, and 5.2, i.e. W2K, WXP, and W2K3 Server).
See the "Merge of Darwin msdosfs, other fixes" item in the FreeBSD 5.2 Open Issues list.
They're called "trials".
OK, so what are the correct descriptions of:
The first and second of those are both "case-preserving", in the sense that the case of letters in a file name is the case that was supplied in the name when the file was created; the first of those is the behavior of most UNIX file systems, and the second of those is the behavior of HFS+, VFAT, and NTFS (when NTFS is accessed via Win32). Saying HFS+ is "case-preserving" in that sense is correct - but it doesn't distinguish it from UFS, which is also "case-preserving" in that sense.
So do you use "case-preserving" to refer only to file systems where lookups ignore case and creates preserve case, reserving "case-insensitive" for file systems (e.g., 8.3 FAT) where lookups ignore case and creates don't preserve case?
If so, you may find that others don't; they might use "case-sensitive" vs. "case-insensitive" to describe the behavior on lookups and "case-preserving" vs. "non-case-preserving" (or whatever) to describe the behavior on creates, so that the first file system type is "case-sensitive" (and "case-preserving"), the second file system type is "case-insensitive and case-preserving", and the third file system type is "case-insensitive and non-case-preserving".
Actually, case-sensitivity vs. case-insensitivity is often a file system issue, not an OS issue. OS X has file systems that are case-sensitive (e.g., UFS), file systems that are case-insensitive (e.g., HFS+), and file systems where the case sensitivity depends on the server's behavior (e.g., NFS and smbfs).
Samba's an SMB server, which is what OS X uses to provide SMB service to clients using SMB; are you saying it has problems with disconnecting from clients?
Or are you saying OS X's SMB client (not Samba-derived, but FreeBSD-derived) doesn't have improved disconnection support in Panther?
They are, at least for the latter 3 in your list. SMB runs atop various implementations of NetBIOS services, which, in turn, run atop TCP and UDP running in turn atop IP, as well as atop the NetBEUI frame layer running atop 802.2 running atop 802.3 and 802.5 and probably other link layers, as well as atop various other transports.
Authentication is somewhat tied into SMB, although Microsoft are using their mutant version of Kerberos now as well as various NTLM versions.
You realize, of course, that the SMB *client* VFS code in Mac OS X is *not* from Samba, right? (The Linux SMB client VFS code isn't from Samba, either. Samba is *NOT* the be-all and end-all of SMB support on UNIX-flavored OSes; it's the most common SMB *server* for those OSes, but it's not the source of the VFS SMB clients in FreeBSD and Linux.)
In addition, in the OSnews article on SystemServices, Seth says
which addresses an issue that might also apply to non-desktop systems, i.e. starting/stopping/restarting services after system startup. (Note that the System V rc scheme, Mac OS X scheme, and rc.d/rcNG scheme have a similar notion, i.e. in those schemes you have scripts to start/stop/restart services, and one time that they happen to be run is at startup time, from init, but they can also be run once the system has started.)
As someone else noted (in an article with a link done as text, not as an , and with an extra blank in it), Mac OS X has a possibly-interesting scheme for starting and stopping system services. Here's the section on System Initialization in the Mac OS X online documentation; in particular, look at the Startup Items stuff.
It's a dependency-based scheme, like at least some of the other proposed system services mechanisms; see the section on adding your own startup items.
Note also that Boring Old Init isn't itself changed; /etc/rc runs SystemStarter as its last act, and that starts up the system services. SystemStarter can also be used as a command to start, stop, or restart services, so this isn't just a system startup mechanism.
NetBSD 1.5 and later have a new rc-based system for controlling services; it's also dependency-based. FreeBSD 5.x has rcNG, which is derived from the NetBSD scheme.
(Note that all of those systems have a BSD-style init, and thus don't have run levels.)
Those schemes don't address one of Seth's complaints, however - according to his description in his blog, he doesn't like having shell script wrappers doing the configuration, he wants it done in the service's process itself:
(I express no opinion on this one way or the other; if you like or don't like the idea, send bouquets or brickbats to him, not me.)
Note also that it appears that he is not designing something just for desktops - in particular, he says:
Now, whether the kernel should start ServiceManager directly, or whether it should continue to run init and have ServiceManager started from an rc file, is another issue; I'm not sure that there's a compelling argument to eliminate init other than to discourage people from continuing to use the current rc script scheme (which might be Seth's motivation for running ServiceManager as process 1 - he might want to discourage rc script tweaking).
Perhaps one of the reasons why people thought of ServiceManager as being purely for desktop systems is that they thought that, as D-BUS is somewhat associated with freedesktop.
...or use mmap(). (I'd say "...mmap() or MapViewOfFile(), but I'm not sure any version of Windows treats memory above 4GB the same way it treats the first 4GB. There might be non-UNIXy OSes that support it as well, so maybe there are other APIs that can be used.)
An apology for William Shatner.
(I note that Jim Carrey also shows up in that list....)
However, as you've also given us Neil Young, I'm willing to let the rest of them slide. (Huevos Rancheros gets you extra credit. I'd list others, but I'm not about to spend tons of time plowing through that site....)