You are mistakenly thinking that windowing and GUIs have something to with system APIs. They don't. And they shouldn't. Instead, userland libraries supply this functionality. The windows gui is quite a hack, api-wise. And it has many, many security problems because of it's being put into the kernel as a system api.
I suspect what we have here are two different meanings for the phrase "system API".
The original poster probably means "all APIs that come with the system", where by "the system" he/she probably meant more than just "the kernel" - i.e., a Linux distribution, not a Linux kernel. By that definition, GUI APIs are system APIs.
It sounds as if you're referring only to system calls.
BTW, as far as I know, the only part of the GUI that's in the kernel on Windows NT (including the 5.x versions, even though Microsoft doesn't call them "Windows NT" any more) is low-level drawing stuff (some or all of GDI - think "Xlib"). The toolkit stuff is in user32.dll and assorted other libraries, running in userland.
Heck, prior to NT 4.0, the low-level drawing stuff was in the Win32 subsystem process - to draw stuff, the libraries would send messages to that process. Sounds a bit like X....
The big difference is that, in UNIX+X, there isn't a GUI toolkit, there are multiple toolkits. On the other hand, given that GTK+ and Qt work on Windows, you could say the same about Windows, except that the native Windows toolkit is, as far as I know more dominant on Windows than any of the UNIX+X toolkits are on their platform.
If the goddammed yankees (and the comment is the same - although a bit mitigated - for the limeys) didn't have their fucking heads so far up their arses, they'd see that not everyone else in the world is as brain-fuckedly-dead as they are, see there are ***ACTUALLY*** cases where State-Owned entreprises can vastly outperform private industry.
What about Canada, where, err, umm, (Canadian) private industry (except for, say, SaskTel) is outperforming (US) private industry?
Korea Telecom, however, was a state-owned company until 2002, and outperformed both. NTT was "incorporated as a private company" in 1985, but "Government and Public bodies" own 46.06% of the shares as of March 31, 2003.
The BPF doesn't even fit in with the STREAMS architecture
The term "BPF" is used to refer to more than one thing.
It's used to refer to the entire packet-tap mechanism in some UNIXes. That doesn't *directly* fit into a STREAMS architecture; however, nothing prevents a system using, for example, STREAMS+DLPI from providing a BPF infrastructure as well and allowing link-layer drivers from calling the BPF tapping routines.
It's also used to refer to the interpreter for packet filter programs that's part of that tap mechanism - that's the "F" part of "BPF".
One could write, for example, a "bpfmod" STREAMS module, which functions similar to Sun's "pfmod" STREAMS module, except that it interprets BPF programs rather than the CMU/Stanford "stack machine" programs that "pfmod" interprets.
The disputed code appears to be part of the BPF interpreter; if SCO are whining about it, presumably they've picked up somebody's BPF interpreter and incorporated it into one of their UNIXes.
If they did so, one hopes that they didn't, err, umm, "[strip] copyright attributions from copyrighted [BSD] code", and that they're giving proper credit to UCB (unless they picked the code up from BSD after the Regents of UCB switched to the new copyright notice).
A BSD network stack (adopted by linux) is a totally different animal.
Actually, Linux's networking stack has different interfaces - and the only way in which it uses BPF is that it has an independently-written implementation of the BPF interpreter, used for the "socket filter" option. There aren't "/dev/bpf" devices on Linux, there are PF_PACKET sockets; libpcap uses different code on systems with the full BPF mechanism (with "/dev/bpf") and on Linux.
n order to create a packet filter in STREAMS, you'll need to simply write a STREAMS module that plops in between the data link layer and network layer. The BPF doesn't even fit in with the STREAMS architecture, unless one were to somehow write wrapper code around it so that it conforms to the DLPI and NPI interfaces...and I think this would be highly inefficient.
If by "packet filter" you mean something to filter out packets based on an expression evaluated on the contents of the packet, no, all you need is a STREAMS module to push atop an opened DLPI device. That's how snoop does it on Solaris, for example.
And even if by "packet filter" you mean something to let you capture packets, you don't need any new STREAMS modules, at least not on Solaris or HP-UX - take a look at libpcap's pcap-dlpi.c to see how it's done. If there were a "bpfmod" STREAMS module, it could push that module and hand it a filter program.
Interesting. Support for M68K, M88K, HP-PA, Sparc, PPC, i386, I860, M88110...
Just what else do you want? Apple have OSX ready for FAR more than just the PPC boxes they're shooting with now.
There's a difference between "there's a list of strings in the kernel that bears a startling resemblance to the list of processors that NeXT and Apple have ever ported to" and "Apple has Mac OS X ready for that list of processors".
(Yes, I know, that posting, especially with the "Apple have OSX ready for FAR more than just the PPC boxes they're shooting with now." statement - right, Apple's got Mac OS X ready to run on shiny new Motorola 88K workstations - is so silly it was probably a troll, and I bit. Oh, well....)
How does a chlorofluorocarbon molecule, which is heavier than air, affect the Earth's upper atmosphere at the poles?
Responses with detailed analyses are appreciated. Please limit your responses to 500 words.
Actually, by suggesting that the mass of a neutron is the sum of the masses of an electron and a proton, you're dodging one of the really fun little divergences in subatomic physics. There's actually a really tiny difference between M(n) and M(p) + M(e).
...just as there's a difference between the mass of a hydrogen atom and the masses of the electron and nucleus - equal to the energy it requires to ionize the atom, I think. Conservation of energy and all that.... The same applies to the mass of, say, a deuterium nucleus and the masses of the proton and neutron in the nucleus - equal to the energy it'd take to split that nucleus.
There are anti-neutrons - the parameter that changes is spin, IIRC.
No - neutrons have a half unit of spin, and the spin of a neutron can be "up" or "down", just as with other half-spin particles such as electrons and protons. The same is true of anti-neutrons, so a neutron and an anti-neutron can have the same spin (both "up" or both "down") or can have opposite spins (one "up", one "down").
It's other charge-like quantum numbers, such as baryon number and isospin (unrelated to spin), that change in the neutron. (They also change in any other particle, e.g. both anti-protons and anti-neutrons have a baryon number of -1, rather than the +1 that the proton and neutron have.)
As the other reply to your poster noted, the maximum addressable physical memory on a machine with 32-bit virtual addresses can be >4GB, and is, in fact, >4GB on several processors, including the PowerPC's he mentioned, as well as Pentium Pro and later x86's from Intel (and probably some 32-bit x86's from AMD as well).
Only 4GB of it can be accessed at any time, however, as linear virtual addresses are 32 bits. If you're trying to use more than 4GB of physical memory, you have to map it in and out of that 4GB window. (The segmentation hardware on x86's doesn't help, as it translates 48-bit segmented addresses into 32-bit linear virtual addresses; you'd have to mark segments that don't fit into that address space "not present", and map the pages of those segments into and out of the 4GB window in response to "segment not present" faults.)
That could be done directly by privileged code, and could be done with system calls such as mmap in non-privileged code.
...unless you have an application that doesn't handle ETIMEDOUT from a read or write call. If you do, you might only be fixing hang troubles by replacing them with data corruption troubles....
Unfortunately, "handle", at minimum, means "check for the error and let the user know it occurred", and might mean "don't throw anything away unless and until the write succeeded". (Of course, unless you make sure you never run out of disk space, that might be a good idea even on local disks....)
Not really. Bear in mind that this was in the late 1970's, and 64KB wasn't a really tiny memory footprint. All I'd done was get it to run in 32KB less than what was, as I remember, the stated minimum memory requirement for V6 - 96KB. If you had a 96KB PDP-11, you had enough memory to run V6 and compile stuff.
...if you're using a 2MB UNIX. I ran "Sixth Edition" UNIX ages ago on a PDP-11 with 64kB (it was a tight fit, and I had to do a little hackery with an assembly-language stub version of the pipe code in order to get a kernel small enough to let me recompile a regular kernel small enough to fit, but it did work).
Motorola Host Processors, Integrated Host Processors and Microcontrollers based on the PowerPC RISC architecture can power your notebook or desktop PC, workstation, or server, as well as high-end networking and telecommunications embedded applications.
...although you don't need files >4GB to manipulate more than 4GB of data within a given process - you could have multiple files smaller than 4GB. It's ugly, but then so is mapping pieces of a single >4GB file in and out of the address space; the latter is just less ugly....
Are off_t & size_t 64bit now? Without those, you'd have a hard time mmap()'ing anything larger than 4Gb, would you not?
off_tis 64 bits on all modern BSD platforms (and there's support under development in FreeBSD, at least, for memory >4GB on x86).
It's still 32 bits, as far as I know, on Linux and Solaris x86; you'd need mmap64() to handle files >4GB, but I think recent Linux kernels and glibcs might have it, as might Solaris x86.
You do not need a 64-bit size_t to mmap() or mmap64() part of a larger-than-4GB file. You obviously can't map all of such a file on a platform with a 32-bit virtual address space; as I believe I indicated in my original message, you would have to use mmap()/mmap64() and munmap() to move a window into that file around.
but on IA32 (well, on any architecture, but the current problem only really applies to cheap-and-popular IA32),
...or an apple XServe (unless they go to, say, a PowerPC 970 in future models).
can only use up to the addressable limit.
...at any given time. An application could use a memory-mapping API such as mmap() to map pieces of a >4GB object into the address space as needed. Yes, that's rather ugly, but people have done it before, e.g. on PDP-11s back in the old days.
Another thing you can use lots of memory for is a disk cache; I know of one series of x86 machines that supports more than 4GB of memory, most of which is used for disk caching (given that all those machines do is file service).
64gb ram is actually more than the arch allows. The arch allows 4gb.
The IA-32 architecture (32-bit x86) allows 4gb of linear virtual address space. (It allows a larger segmented address space, but those segmented addresses get mapped into the 4gb linear space.)
Versions of the x86 architecture implemented by the Pentium Pro and beyond allow more than 4gb of physical address space, and thus allow (with the appropriate chipset and OS support) machines with more than 4gb of RAM; you just can't have more than 4gb of that memory mapped into the virtual address space at any given time (those presumably being the "paging tricks" to which you refer; mmap() and other memory-mapping APIs, and multi-tasking, are your friends here).
This is one reason why NTFS is case aware, but not necessarily case sensitive.
Eh? What does case-sensitivity (NTFS is case-preserving, in that if an application makes a call to create a file named "FooBar", it'll be named "FooBar", not "foobar" or "FOOBAR", but not case-sensitive, as an application could try to open "foobar" or "FooBar" or "FoOBaR" or "FOOBAR" and all of those would match "FooBar") have to do with multiple data streams (the pathname syntax for which, in Win32 APIs, is "{filename}:{streamname}")?
However, referring to that part of the Internet that's the World-Wide Web, while books might end quickly or have chapters where you can stop reading, some books also have references sections, and you might then want to chase down the references.
One difference between that and the Web is that you usually can't instantly "follow a link" from a book or magazine article - you might have to go to the library or a bookstore to get the "linked-to" item, or even if you're at the library or the bookstore you'd have to go looking for it. It might also not be available instantly.
In some cases, the fact that links often work immediately is a feature; in others, it could be considered a bug, as per your "five more minutes" syndrome.
and from what I hear (that is to say, what Will Irwin has said on LKML) PAE is fairly slow compared to regular memory
What exactly did Will Irwin say? (Do you have a link to his LKML message?) It's not as if there's "PAE memory" and "regular memory" - if PAE is enabled, it's all regular memory, you can just use more of it.
What he may have meant is that, with PAE extended, there are some things that are slower. With PAE enabled, you have a 3-level page table rather than a 2-level page table, and page table entries are larger, so page table walks done on a TLB miss might be more expensive. It might be that the VM code is slower as well, because physical addresses and page table entries are larger.
See, SPARC doesn't have that silly 4GB addressing limitation that IA-32 does.
Well, SPARC V9 doesn't, but the older 32-bit versions of SPARC did. SPARC V8 plus the SPARC Reference MMU supported >4GB of memory in the same way PAE does, and Sun supported that on their Sun-4d machines, I think.
Slashdot Mirror
I suspect what we have here are two different meanings for the phrase "system API".
The original poster probably means "all APIs that come with the system", where by "the system" he/she probably meant more than just "the kernel" - i.e., a Linux distribution, not a Linux kernel. By that definition, GUI APIs are system APIs.
It sounds as if you're referring only to system calls.
BTW, as far as I know, the only part of the GUI that's in the kernel on Windows NT (including the 5.x versions, even though Microsoft doesn't call them "Windows NT" any more) is low-level drawing stuff (some or all of GDI - think "Xlib"). The toolkit stuff is in user32.dll and assorted other libraries, running in userland.
Heck, prior to NT 4.0, the low-level drawing stuff was in the Win32 subsystem process - to draw stuff, the libraries would send messages to that process. Sounds a bit like X....
The big difference is that, in UNIX+X, there isn't a GUI toolkit, there are multiple toolkits. On the other hand, given that GTK+ and Qt work on Windows, you could say the same about Windows, except that the native Windows toolkit is, as far as I know more dominant on Windows than any of the UNIX+X toolkits are on their platform.
What about Canada, where, err, umm, (Canadian) private industry (except for, say, SaskTel) is outperforming (US) private industry?
Korea Telecom, however, was a state-owned company until 2002, and outperformed both. NTT was "incorporated as a private company" in 1985, but "Government and Public bodies" own 46.06% of the shares as of March 31, 2003.
One fictitious president for another - sounds like a good trade to me....
Your Canada includes Colorado and Texas? (If it includes Texas, do we at least get to blame you for Dubya?)
The term "BPF" is used to refer to more than one thing.
It's used to refer to the entire packet-tap mechanism in some UNIXes. That doesn't *directly* fit into a STREAMS architecture; however, nothing prevents a system using, for example, STREAMS+DLPI from providing a BPF infrastructure as well and allowing link-layer drivers from calling the BPF tapping routines.
It's also used to refer to the interpreter for packet filter programs that's part of that tap mechanism - that's the "F" part of "BPF".
One could write, for example, a "bpfmod" STREAMS module, which functions similar to Sun's "pfmod" STREAMS module, except that it interprets BPF programs rather than the CMU/Stanford "stack machine" programs that "pfmod" interprets.
In fact, Rick Jones did implement such a module.
The disputed code appears to be part of the BPF interpreter; if SCO are whining about it, presumably they've picked up somebody's BPF interpreter and incorporated it into one of their UNIXes.
If they did so, one hopes that they didn't, err, umm, "[strip] copyright attributions from copyrighted [BSD] code", and that they're giving proper credit to UCB (unless they picked the code up from BSD after the Regents of UCB switched to the new copyright notice).
Actually, Linux's networking stack has different interfaces - and the only way in which it uses BPF is that it has an independently-written implementation of the BPF interpreter, used for the "socket filter" option. There aren't "/dev/bpf" devices on Linux, there are PF_PACKET sockets; libpcap uses different code on systems with the full BPF mechanism (with "/dev/bpf") and on Linux.
If by "packet filter" you mean something to filter out packets based on an expression evaluated on the contents of the packet, no, all you need is a STREAMS module to push atop an opened DLPI device. That's how snoop does it on Solaris, for example.
And even if by "packet filter" you mean something to let you capture packets, you don't need any new STREAMS modules, at least not on Solaris or HP-UX - take a look at libpcap's pcap-dlpi.c to see how it's done. If there were a "bpfmod" STREAMS module, it could push that module and hand it a filter program.
There's a difference between "there's a list of strings in the kernel that bears a startling resemblance to the list of processors that NeXT and Apple have ever ported to" and "Apple has Mac OS X ready for that list of processors".
Let's look at the list:
The only surprise to me in that list is i860.
(Yes, I know, that posting, especially with the "Apple have OSX ready for FAR more than just the PPC boxes they're shooting with now." statement - right, Apple's got Mac OS X ready to run on shiny new Motorola 88K workstations - is so silly it was probably a troll, and I bit. Oh, well....)
OK, how about one URL (to a page whose word count I'm not going to bother computing) for a page entitled How Can Chlorofluorocarbons (CFCs) Get to the Stratosphere If They're Heavier than Air?.
...just as there's a difference between the mass of a hydrogen atom and the masses of the electron and nucleus - equal to the energy it requires to ionize the atom, I think. Conservation of energy and all that.... The same applies to the mass of, say, a deuterium nucleus and the masses of the proton and neutron in the nucleus - equal to the energy it'd take to split that nucleus.
No - neutrons have a half unit of spin, and the spin of a neutron can be "up" or "down", just as with other half-spin particles such as electrons and protons. The same is true of anti-neutrons, so a neutron and an anti-neutron can have the same spin (both "up" or both "down") or can have opposite spins (one "up", one "down").
It's other charge-like quantum numbers, such as baryon number and isospin (unrelated to spin), that change in the neutron. (They also change in any other particle, e.g. both anti-protons and anti-neutrons have a baryon number of -1, rather than the +1 that the proton and neutron have.)
As the other reply to your poster noted, the maximum addressable physical memory on a machine with 32-bit virtual addresses can be >4GB, and is, in fact, >4GB on several processors, including the PowerPC's he mentioned, as well as Pentium Pro and later x86's from Intel (and probably some 32-bit x86's from AMD as well).
Only 4GB of it can be accessed at any time, however, as linear virtual addresses are 32 bits. If you're trying to use more than 4GB of physical memory, you have to map it in and out of that 4GB window. (The segmentation hardware on x86's doesn't help, as it translates 48-bit segmented addresses into 32-bit linear virtual addresses; you'd have to mark segments that don't fit into that address space "not present", and map the pages of those segments into and out of the 4GB window in response to "segment not present" faults.)
That could be done directly by privileged code, and could be done with system calls such as mmap in non-privileged code.
...unless you have an application that doesn't handle ETIMEDOUT from a read or write call. If you do, you might only be fixing hang troubles by replacing them with data corruption troubles....
Unfortunately, "handle", at minimum, means "check for the error and let the user know it occurred", and might mean "don't throw anything away unless and until the write succeeded". (Of course, unless you make sure you never run out of disk space, that might be a good idea even on local disks....)
Not really. Bear in mind that this was in the late 1970's, and 64KB wasn't a really tiny memory footprint. All I'd done was get it to run in 32KB less than what was, as I remember, the stated minimum memory requirement for V6 - 96KB. If you had a 96KB PDP-11, you had enough memory to run V6 and compile stuff.
...if you're using a 2MB UNIX. I ran "Sixth Edition" UNIX ages ago on a PDP-11 with 64kB (it was a tight fit, and I had to do a little hackery with an assembly-language stub version of the pipe code in order to get a kernel small enough to let me recompile a regular kernel small enough to fit, but it did work).
Yes, and it's called a "gluon".
Yes. How big do you want your bytes to be (in the range 1 <= number_of_bits <= 36)?
On 99 44/100% or more of current computers, a byte is 8 bits, but that hasn't always been the case.
They may not be interested, but they still mention it on the parent of the page you cite:
...although you don't need files >4GB to manipulate more than 4GB of data within a given process - you could have multiple files smaller than 4GB. It's ugly, but then so is mapping pieces of a single >4GB file in and out of the address space; the latter is just less ugly....
off_t is 64 bits on all modern BSD platforms (and there's support under development in FreeBSD, at least, for memory >4GB on x86).
It's still 32 bits, as far as I know, on Linux and Solaris x86; you'd need mmap64() to handle files >4GB, but I think recent Linux kernels and glibcs might have it, as might Solaris x86.
You do not need a 64-bit size_t to mmap() or mmap64() part of a larger-than-4GB file. You obviously can't map all of such a file on a platform with a 32-bit virtual address space; as I believe I indicated in my original message, you would have to use mmap()/mmap64() and munmap() to move a window into that file around.
...or an apple XServe (unless they go to, say, a PowerPC 970 in future models).
...at any given time. An application could use a memory-mapping API such as mmap() to map pieces of a >4GB object into the address space as needed. Yes, that's rather ugly, but people have done it before, e.g. on PDP-11s back in the old days.
Another thing you can use lots of memory for is a disk cache; I know of one series of x86 machines that supports more than 4GB of memory, most of which is used for disk caching (given that all those machines do is file service).
The IA-32 architecture (32-bit x86) allows 4gb of linear virtual address space. (It allows a larger segmented address space, but those segmented addresses get mapped into the 4gb linear space.)
Versions of the x86 architecture implemented by the Pentium Pro and beyond allow more than 4gb of physical address space, and thus allow (with the appropriate chipset and OS support) machines with more than 4gb of RAM; you just can't have more than 4gb of that memory mapped into the virtual address space at any given time (those presumably being the "paging tricks" to which you refer; mmap() and other memory-mapping APIs, and multi-tasking, are your friends here).
Eh? What does case-sensitivity (NTFS is case-preserving, in that if an application makes a call to create a file named "FooBar", it'll be named "FooBar", not "foobar" or "FOOBAR", but not case-sensitive, as an application could try to open "foobar" or "FooBar" or "FoOBaR" or "FOOBAR" and all of those would match "FooBar") have to do with multiple data streams (the pathname syntax for which, in Win32 APIs, is "{filename}:{streamname}")?
Not true.
However, referring to that part of the Internet that's the World-Wide Web, while books might end quickly or have chapters where you can stop reading, some books also have references sections, and you might then want to chase down the references.
One difference between that and the Web is that you usually can't instantly "follow a link" from a book or magazine article - you might have to go to the library or a bookstore to get the "linked-to" item, or even if you're at the library or the bookstore you'd have to go looking for it. It might also not be available instantly.
In some cases, the fact that links often work immediately is a feature; in others, it could be considered a bug, as per your "five more minutes" syndrome.
What exactly did Will Irwin say? (Do you have a link to his LKML message?) It's not as if there's "PAE memory" and "regular memory" - if PAE is enabled, it's all regular memory, you can just use more of it.
What he may have meant is that, with PAE extended, there are some things that are slower. With PAE enabled, you have a 3-level page table rather than a 2-level page table, and page table entries are larger, so page table walks done on a TLB miss might be more expensive. It might be that the VM code is slower as well, because physical addresses and page table entries are larger.
Well, SPARC V9 doesn't, but the older 32-bit versions of SPARC did. SPARC V8 plus the SPARC Reference MMU supported >4GB of memory in the same way PAE does, and Sun supported that on their Sun-4d machines, I think.