Also, It is also believed that NSA programmers have contributed to the linux kernel.
Was "believed" put in there because somebody wants it to sound Really Scary(TM) because it's "believed" rather than "publicly known", or was it put in there because somebody was unaware of SELinux?
Machines called 'toasters' (by the faithful) already based upon NetBSD
...if by "based on NetBSD" you mean "including, in the low-level support code for Alpha-based machines, some code from NetBSD".
Data ONTAP is NOT "based on NetBSD" in the sense of being a modified version of NetBSD, or even of having a kernel that's a derivative of NetBSD. (Note that there aren't any Alpha-based machines currently being made by NetApp, so none of the current toasters are NetBSD-based.) There is a significant chunk of BSD-based code in ONTAP, mainly the networking stack and networking commands (the latter being modified to run in the kernel, without demand paging, and with all processes running in the same address space), but that's mainly 4.4BSD-based, with some FreeBSD stuff.
(Yes, I do speak with authority on this matter, having been, among other things, one of the people who worked on the initial Alpha port of ONTAP.)
When switchign between applications (such as forked processes), you need to do a full task switch- registers, stack, memory, cache invalidate, etc. Very expensive. When switching between threads you only need to swap out the registers, stack, and program counter.
I'm not sure what you mean by "memory" in the full task switch list. I suspect you mean "address space"; swapping that could be expensive if, for example, you have to invalidate a TLB and re-populate it.
If by "cache invalidate" you mean invalidate the caches that sit between the CPU and main memory, that might not be necessary if, for example, the cache is physically indexed and tagged - and possibly not even if it's virtually indexed if, for example, it's physically tagged.
So, while there is a cost to process switching if it involves address-space switching, it's not necessarily as large as you might think.
I read somewhere about this. Basically, in addition to symlinks and hard links (as other Unixes), OS X has a 3rd link type called alias that allows this move.
I'm not an expert and I am not sure how it is actually implemented however.
% ls -li ~/Desktop/CRONIN.pdf 2065484 -rw-r--r-- 1 {me} staff 1937893 24 Feb 2000/Users/gharris/Desktop/CRONIN.pdf % file ~/Desktop/CRONIN.pdf /Users/gharris/Desktop/CRONI N.pdf: PDF document, version 1.3 % ls -li/.vol/234881029/2065484 2065484 -rw-r--r-- 1 {me} staff 1937893 24 Feb 2000/.vol/234881029/2065484 % file/.vol/234881029/2065484 /.vol/234881029/2065484: PDF document, version 1.3
Ignore the blank in the pathname in the output of the first "file" command, that's Slashdot's friendly anti-widening stuff in action.
Note the caveats on the Apple page in question. Volfs is not guaranteed to work the same way forever, so your application should not rely on it continuing to work that way.)
It's already available for AIX, so the instruction set can't be a problem.
When porting from one OS to another, the instruction set is probably rarely the main problem. (Not "never a problem", although I suspect the main instruction-set-related problems are
byte-order issues (software not taking byte order into account and working only on little-endian or only on big-endian platforms);
alignment requirement issues (software assuming that unaligned pointers can be dereferenced safely and not working on, for example, SPARC processors, where an unaligned dereference, unless the compiler is generating "safe" code, will get an alignment fault).)
If ClearCase still uses an installable file system in the OS kernel, that'd probably be the biggest issue for a port to a new OS - different UN*Xes have different VFS layers. Beyond that, there might be issues with deficiencies in the new target OS's implementation of particular APIs, or the lack of particular APIs in the new target OS, for example.
Cunningly, the 8641D can not only appear to the host OS as two processors, but is capable of running a separate operating systems on each core.
So when the dual core G4s do come out I could run 2 separate operating systems simultaneously?
Not necessarily. Freescale's Web site speaks of them as a vendor of embedded microprocessors; perhaps that feature is intended for use in embedded systems, where the OS can be tweaked as necessary to handle two processors sharing an I/O bus and peripherals, so that doesn't necessarily imply that the dual-core processor magically turns any system into which it's plugged into two separate systems that can boot separately and communicate separately with peripherals on the system.
(BTW, when I tried Googling for "8641D freescale" and "MPC8641D freescale" to see if I could find anything giving details about that feature - nothing turned up - Google asked whether I wanted "firesale" instead of "freescale". Is Google expressing its opinion of Motorola's spinning off Freescale?)
(No, don't bother explaining to me how that Google feature works; I'm already aware of it. "It's a joke, son....")
In that case, though, the restriction was that a single segment could be no larger than a megabyte (18-bit segment offset, word addressing, 4 9-bit bytes per word), not a limit on the size of the entire address space (12 bits of segment number, as I remember, gives a total address space of 4GB, although some of that was taken up by the kernel^H^H^H^H^H^Hhardcore supervisor and various bits of code you'd probably have mapped into the address space of your process ("process",singular - one per login session, typically).
In fact, care to find anything other than the StrongARM
You misspelled "XScale".:-)
anywhere at all???
Yes, I'd care to, although many of them aren't systems for which most people you might think of as "IT workers" would write software - a lot of them are embedded systems.
I don't know how many of them are XScales and how many are other ARM instruction-set processors.
You can't access the disk and RAM the same way because 32 bits aren't enough; just ask the HURD people with their 2 GB (maximum) partitions.
That didn't stop Multics - you didn't assign every single segment in the system its own virtual address range, a process had to initiate a segment to get it mapped into the process' address space. Initiating a segment is, in UN*Xy terms, sort of like opening the file, mmapping it into your address, and then closing the descriptor - you can only access it by using the pointer you get back from the initiate operation. (The equivalents of read and write worked by copying from or to the mapped region.)
While I was graduate student in the 1980's there were a bunch of the most powerful Cray supercomputers at Los Alamos running this OS.
No. They were running the Cray Time Sharing System, as mentioned in this article:
The Center acquired a Cray 1 in 1978 and soon became known as an innovator in the management and operation of supercomputers. We converted our 7600 operating system, utilities, and libraries to the new machine, creating the Cray Time Sharing System (CTSS) -- the first timesharing system for a Cray -- and demonstrating that the machine could be used interactively. CTSS was subsequently adopted by nine other computer centers.
Different CTSS - "Cray", not "Compatible".
I think there was even a variant, LTSS that was run at Livermore.
That appears orignally to have been an OS for Control Data machines, according to this article, although it says it was moved to the Cray-1 as well:
LLL has a long history of pushing the state of the art in high speed scientific processing to satisfy the prodigious raw processing requirements of the many physics simulation codes run at the laboratory. The high speed, often few of a kind computing engines (For example, Univac-1, 1953, Larc, Remington Rand, 1960, Stretch, IBM, 1961, 6600, CDC, 1964, Star-100, CDC, 1974, Cray-1, Cray Research, 1978) utilized at LLL are usually purchased before mature operating system software is available for them [22]. The very early operating systems implemented at LLL were quite simple and were usually coded in assembly language. By the time of the CDC 6600 (1965), however, they were becoming more comp1ex timesharing systems. By 1966 it was decided to write the operating system for the 6600 in a higher level language. This decision made it easier to transfer that system (dubbed LTSS, Livermore Time Sharing System) to new machines as they arrived: CDC 7600, CDC Star-100, and the Cray-l.
- lukemftpd: Corrects the path to the configuration directory
- Safari (10.3.5 only): The Safari version number is changed to provide compatibility with web sites that use an old version-checking mechanism
Does anyone know why it has inexplicably re-appeared?
So that people who installed the 1.0 version get offered the 1.1 version, and can get their FTP server and their ability to go to sites that think that a browser version string containing "Netscape" and "4." means the browser is Netscape 4.
This update apparently "secures" the FTP daemon in quite an original way, by rendering it completely inoperable.
A subsequent reissue of the Security Update fixes this (and the Safari problem with sites using OpenCube's menu stuff). (That page refers to the 10.3.4 client version of OS X, but it later says "Security Update 2004-09-07 v1.1 is available for Mac OS X v10.2.8, Mac OS X v10.3.4, Mac OS X v10.3.5, Mac OS X Server v10.2.8, Mac OS X Server v10.3.4, and Mac OS X Server v10.3.5".)
Looks like that Safari is not correctly rendering some sites that use OpenCube's Visual QuickMenu...
A subsequent reissue of the Security Update fixes this (and the FTP daemon problem). (That page refers to the 10.3.4 client version of OS X, but it later says "Security Update 2004-09-07 v1.1 is available for Mac OS X v10.2.8, Mac OS X v10.3.4, Mac OS X v10.3.5, Mac OS X Server v10.2.8, Mac OS X Server v10.3.4, and Mac OS X Server v10.3.5".)
OS X also has the GUI filesystem layed out right. There is no reason for the gui file manager (finder) to show the root of the hard drive.
You might want to tell Apple that - take a look at the sidebar in a Finder window (at least in Panther), and click, for example, an icon for one of your hard drive partitions, or just click on one of the hard drive icons on the desktop.
It's unnecessary (especially if you've ever explained to someone why they keep getting dll errors after deleting a directory in windows less than one day after reinstalling the system, thanks mom).
It might not show "mach_kernel" in there, but it *does* show Applications, Libraries, and System, and their contents....
Most of the problems I've encountered are with Safari. The following sites all have similar problems and are entirely unusable with Safari after applying the patch:
...and if those sites update the version of OpenCube's QuickMenu Pro that they're using, to fix the browser type/version check, they'll probably be usable again. See the 9/8/04 item on this site and a 9/8/04 item on this site.
I saw it in a "complete family tree of UNIX", which I'm furiously trying to locate.
This one? If so, note that the OS X Server releases starting with the one labeled "Mac OS X Server 10.0.3" have arrows from the OS X client line. The earlier OS X Server releases didn't have an Aqua GUI - they had a more Mac-like GUI (more Rhapsody-derived).
I also found http://www.macintouch.com/mxs.html which near the very top is talking about how the interface is heavily NeXT and not like traditional Mac OS, granted it's quite old information
Exactly. It's talking about one of the old OS X server 1.x releases that came out before the client OS X 10.0.
but that tends to confirm what I gathered informally from other sources.
Perhaps those other sources think OS X Server is still more like the older 1.x releases, without all the stuff added on the client side since then, including the Aqua GUI (or are old source from when it was one of the older 1.x releases).
but it seems (again, from informal observation) that the consumer version is much more FreeBSDish and the server version is much more Machish
The Mach stuff that's generally visible is mainly the object file format; that stuff is present in both client and server, as is the Mach+BSD kernel (/mach_kernel) and Mach-related user-mode servers such as mach_init. What stuff have you observed that shows the client being "more FreeBSDish" and the server ("server" meaning "server with the same version as the client", e.g. if your client is 10.3[.x], the server should be another 10.3 version, not one of the really old servers) being "more Machish"?
In that case, at least, the ACLU is not defending "legalizing the molestation of young boys", they're defending NAMBLA against the charge that they incited somebody to murder and torture a young boy.
I'll point you to their statement on defending the free speech of unpopular organizations, in which they say that the Massachusetts affiliate of the ACLU "does not advocate sexual relationships between adults and children" (and does not advocate trading arms for hostages, either, even though they defended Oliver North's right to refuse to testify during the Iran-Contra investigations).
Slashdot Mirror
There's more to OS X than Darwin, and the "more" isn't open-source, so the question should be rewritten as "how come Apple haven't written...".
Was "believed" put in there because somebody wants it to sound Really Scary(TM) because it's "believed" rather than "publicly known", or was it put in there because somebody was unaware of SELinux?
...if by "based on NetBSD" you mean "including, in the low-level support code for Alpha-based machines, some code from NetBSD".
Data ONTAP is NOT "based on NetBSD" in the sense of being a modified version of NetBSD, or even of having a kernel that's a derivative of NetBSD. (Note that there aren't any Alpha-based machines currently being made by NetApp, so none of the current toasters are NetBSD-based.) There is a significant chunk of BSD-based code in ONTAP, mainly the networking stack and networking commands (the latter being modified to run in the kernel, without demand paging, and with all processes running in the same address space), but that's mainly 4.4BSD-based, with some FreeBSD stuff.
(Yes, I do speak with authority on this matter, having been, among other things, one of the people who worked on the initial Alpha port of ONTAP.)
I'm not sure what you mean by "memory" in the full task switch list. I suspect you mean "address space"; swapping that could be expensive if, for example, you have to invalidate a TLB and re-populate it.
If by "cache invalidate" you mean invalidate the caches that sit between the CPU and main memory, that might not be necessary if, for example, the cache is physically indexed and tagged - and possibly not even if it's virtually indexed if, for example, it's physically tagged.
So, while there is a cost to process switching if it involves address-space switching, it's not necessarily as large as you might think.
With volfs. See this note on the Apple developer Web site. (For volfs, think "open by i-number", at least for some file systems:
Ignore the blank in the pathname in the output of the first "file" command, that's Slashdot's friendly anti-widening stuff in action.
Note the caveats on the Apple page in question. Volfs is not guaranteed to work the same way forever, so your application should not rely on it continuing to work that way.)
When porting from one OS to another, the instruction set is probably rarely the main problem. (Not "never a problem", although I suspect the main instruction-set-related problems are
If ClearCase still uses an installable file system in the OS kernel, that'd probably be the biggest issue for a port to a new OS - different UN*Xes have different VFS layers. Beyond that, there might be issues with deficiencies in the new target OS's implementation of particular APIs, or the lack of particular APIs in the new target OS, for example.
Not necessarily. Freescale's Web site speaks of them as a vendor of embedded microprocessors; perhaps that feature is intended for use in embedded systems, where the OS can be tweaked as necessary to handle two processors sharing an I/O bus and peripherals, so that doesn't necessarily imply that the dual-core processor magically turns any system into which it's plugged into two separate systems that can boot separately and communicate separately with peripherals on the system.
(BTW, when I tried Googling for "8641D freescale" and "MPC8641D freescale" to see if I could find anything giving details about that feature - nothing turned up - Google asked whether I wanted "firesale" instead of "freescale". Is Google expressing its opinion of Motorola's spinning off Freescale?)
(No, don't bother explaining to me how that Google feature works; I'm already aware of it. "It's a joke, son....")
Not exactly - that's why multisegment files were implemented.
In that case, though, the restriction was that a single segment could be no larger than a megabyte (18-bit segment offset, word addressing, 4 9-bit bytes per word), not a limit on the size of the entire address space (12 bits of segment number, as I remember, gives a total address space of 4GB, although some of that was taken up by the kernel^H^H^H^H^H^Hhardcore supervisor and various bits of code you'd probably have mapped into the address space of your process ("process",singular - one per login session, typically).
The MIT 6180, in 1973, had 15 150MB disks, according to the page on the MIT Multics systems in the Multics site history, for a grand total of 2.25GB. (Main memory was 384K 36-bit works, or about 1.5MB.)
You misspelled "XScale". :-)
Yes, I'd care to, although many of them aren't systems for which most people you might think of as "IT workers" would write software - a lot of them are embedded systems.
I don't know how many of them are XScales and how many are other ARM instruction-set processors.
That didn't stop Multics - you didn't assign every single segment in the system its own virtual address range, a process had to initiate a segment to get it mapped into the process' address space. Initiating a segment is, in UN*Xy terms, sort of like opening the file, mmapping it into your address, and then closing the descriptor - you can only access it by using the pointer you get back from the initiate operation. (The equivalents of read and write worked by copying from or to the mapped region.)
That mentions "TSS", as in "TSS/370", as in "Time Sharing System/370", as in "System/370", not "CTSS", which ran on a modified IBM 7094.
No. They were running the Cray Time Sharing System, as mentioned in this article:
Different CTSS - "Cray", not "Compatible".
That appears orignally to have been an OS for Control Data machines, according to this article, although it says it was moved to the Cray-1 as well:
In an Apple page on the 1.1 version of the Security Update, they explicitly note that the 1.1 version "fixes the following issues in Security Update 2004-09-07 v1.0:"
So that people who installed the 1.0 version get offered the 1.1 version, and can get their FTP server and their ability to go to sites that think that a browser version string containing "Netscape" and "4." means the browser is Netscape 4.
Yeah, there's a lot of that going around.
A subsequent reissue of the Security Update fixes this (and the Safari problem with sites using OpenCube's menu stuff). (That page refers to the 10.3.4 client version of OS X, but it later says "Security Update 2004-09-07 v1.1 is available for Mac OS X v10.2.8, Mac OS X v10.3.4, Mac OS X v10.3.5, Mac OS X Server v10.2.8, Mac OS X Server v10.3.4, and Mac OS X Server v10.3.5".)
A subsequent reissue of the Security Update fixes this (and the FTP daemon problem). (That page refers to the 10.3.4 client version of OS X, but it later says "Security Update 2004-09-07 v1.1 is available for Mac OS X v10.2.8, Mac OS X v10.3.4, Mac OS X v10.3.5, Mac OS X Server v10.2.8, Mac OS X Server v10.3.4, and Mac OS X Server v10.3.5".)
Does the CIA know that? Apparently not, as they seem to think it's more like 1/9th (293,027,571 for the US, 32,507,874 for Canada).
You might want to tell Apple that - take a look at the sidebar in a Finder window (at least in Panther), and click, for example, an icon for one of your hard drive partitions, or just click on one of the hard drive icons on the desktop.
It might not show "mach_kernel" in there, but it *does* show Applications, Libraries, and System, and their contents....
...and if those sites update the version of OpenCube's QuickMenu Pro that they're using, to fix the browser type/version check, they'll probably be usable again. See the 9/8/04 item on this site and a 9/8/04 item on this site.
This one? If so, note that the OS X Server releases starting with the one labeled "Mac OS X Server 10.0.3" have arrows from the OS X client line. The earlier OS X Server releases didn't have an Aqua GUI - they had a more Mac-like GUI (more Rhapsody-derived).
Exactly. It's talking about one of the old OS X server 1.x releases that came out before the client OS X 10.0.
Perhaps those other sources think OS X Server is still more like the older 1.x releases, without all the stuff added on the client side since then, including the Aqua GUI (or are old source from when it was one of the older 1.x releases).
The Mach stuff that's generally visible is mainly the object file format; that stuff is present in both client and server, as is the Mach+BSD kernel (/mach_kernel) and Mach-related user-mode servers such as mach_init. What stuff have you observed that shows the client being "more FreeBSDish" and the server ("server" meaning "server with the same version as the client", e.g. if your client is 10.3[.x], the server should be another 10.3 version, not one of the really old servers) being "more Machish"?
Indeed? From whom did you hear this, and what details did they give? For example, in what sense is OS X server "more NeXTish"?
And other stations.
To be precise, in at least one case what the ACLU did was to defend it against a lawsuit asserting that "[b]y its publications, meetings and website NAMBLA encourages its members to rape male children (paragraph 18), that all defendants, including each of the individual defendants and the Internet Service provider, acting intentionally, negligently, carelessly and recklessly, "promoted, advocated, conspired and urged the general public to rape young male children and provided information to assist the general public in obtaining child pornography and pedophile related material. (paragraph 26), and that this induced Charles Jaynes to become a homosexual pedophile and to murder and mutilate a 10-year-old boy.
In that case, at least, the ACLU is not defending "legalizing the molestation of young boys", they're defending NAMBLA against the charge that they incited somebody to murder and torture a young boy.
I'll point you to their statement on defending the free speech of unpopular organizations, in which they say that the Massachusetts affiliate of the ACLU "does not advocate sexual relationships between adults and children" (and does not advocate trading arms for hostages, either, even though they defended Oliver North's right to refuse to testify during the Iran-Contra investigations).
Okay, does suing a public park authority to prevent them from prohibiting baptisms in the park count? How about suing a city to prevent them from requiring a Muslim woman to wear a bathing suit in order to accompany her children at a municipal swimming pool? Or appealing to the Michigan Supreme Court to reverse a conviction of a Catholic man punished for not completing a Pentecostal drug rehabilitation program that didn't allow him to keep his rosary and Holy Communion prayer book, without allowing him to choose a program that would allow him to remain a Catholic?
Check out the religious discrimination and religious freedom sections of the ACLU Web site.
I hadn't heard about that one. I had heard of the bombing of a Greenpeace ship in a New Zealand harbor.
I assume it's Digital Video Broadcasting, i.e. digital TV.