there are a number of properties, but they basically boil down to a priviledge model which allows you to run kernel mode code which thinks it's dealing with physical addresses in user mode with virtual addresses such that any priviledged
instructions can be trapped and emulated so that
the "guest" OS can't tell.
so, not only does "load page table base register" or "load gdt base" or "load ldt selector" have to trap, but so does "store page table base register" or "store gdt base" or "store ldt selector"..
.. and that bit about "bank switching".. umm. how 70's.
P6-family x86 processors have 32-bit virtual address, 36-bit physical address. if you turn on PAE, you move to 64-bit PTE's and 3-level page tables (instead of the 32-bit PTE and 2-level tables) and can map individual 4kb pages from 64gb of physical memory anywhere within your 4gb virtual address space.. of course, you need to rewrite your pmap or equivalent piece of the vm system to deal with the different page table format..
(Any individual virtual address space is limited to 4gb, which is a significant constraint, but no "bank switching" is needed)
I've been working in security/authentication/PKI related areas for close to 15 years. The paper is
entirely correct that a hierarchical PKI is doomed to failure because it implies a One True Root which everyone trusts.
I believe that what eventually will to evolve is a whole bunch of little problem-domain-specific public-key infrastructures, some of which will use x.509 certificate formats, some of which won't.
pgp, ssh, secure dns, etc, all "do their own thing" and provide a public key infrastructure to attempt to solve the piece of the problem they care about without getting tangled into the morass of hierarchical PKI which caused Privacy Enhanced Mail (PEM) to sink without a trace..
Read my original message again.
The problem comes not from dropped SYN/ACK, but
from a dropped ACK (the second client->server packet).
The client retransmits to recover from a dropped SYN/ACK or dropped SYN; the *server* has to retransmit to recover from a dropped ACK
(because you don't ever retransmit pure ACK's)
Because of the way the TCP protocol is designed,
you can't do this without breaking interoperability with existing clients.
Without going into exhaustive detail, every TCP connection starts with 3 packets:
SYN (client->server)
SYN/ACK (server->client)
ACK (client->server)
If the ACK packet gets dropped (occasional packet loss is a fact of life in the Internet), and the application protocol is such that the server speaks first (which is the case for many protocols including SMTP, FTP, and SSH), the connection hangs.. the client expects the server to say something, and the server never says anything because it doesn't have any connection state saved from the SYN!
The best thing you can do is to do a bunch of
research on prior art, and disclose that to the
patent lawyers as part of any paperwork you sign.
A former employer of mine started down the software patent
path for something I designed. I pointed out
vigorously that the "invention" was an obvious
combination of something I had implemented at a past job, and something which someone else had productized. Shortly thereafter, I was informed
that they had decided to suspend the patent process...
Having done some work on the periphery of the embedded networking space, there may be a few obstacles to the hardware vendor open-sourcing their code, or even releasing specs which would allow others to develop software for the box:
The vendor might not have the right to release specs for third-party chips on board (specs may only be available under non-disclosure)
The vendor might not be able to release all the code running on the box, since it may have been licensed from third parties.
They may no longer have the information at all. Chances are parts of the necessary information only existed in the heads of engineers that no longer work there..
NetBSD has a packages collection which is very similar to (and related to) the FreeBSD ports collection.
We use slightly different terminology -- a NetBSD "port" is a port of NetBSD to a particular platform, and we install into/usr/pkg by default instead of/usr/local, to leave/usr/local free for truly local software, but if you're familiar with the FreeBSD ports collection, it should look very familiar to you..
I've seen any number of bits of humor making the rounds (not just in email -- in the Real World, in such publications as Readers Digest) listing many of the cute mistakes made by kids in school..
I think someone's just a little bit hypersensitive here...
Ever try to port a source-only driver from one OS to another? I have. it's often not much fun.. a well-written driver can serve as hardware documentation. a poorly written one, well, raises more questions about how the device works than it answers..
Given how many buggy drivers i've seen coming from hardware vendors.. they're often experts at the hardware, but have no clue how to do non-windows drivers. don't tempt them to turn their windows drivers into bad unix drivers... ask for hardware docs only!
You didn't mention what software you're using for this mail server.
At least some POP servers are reputed to do stupid stuff like copying a user's whole mailbox to a new file every time a user connects up, looks at headers, or deletes a message. While I don't have specific recommendations, I'd advise auditioning a few different packages to see what kind of I/O load they place on a disk farm. Also, you may be better off spreading your load across multiple (cheap) servers rather than putting all your eggs in one expensive basket.
Also, improperly tuned RAID-5-based systems can be slower than the disks they're built out of because of the need to do read-modify-write cycles to update the parity blocks..
actually, my laptop (Sony Z505S) has an on-board eepro 10/100 which seems to work just fine with ipv6 under NetBSD; seems to deal with multicast traffic for neighbor discovery just fine. when in doubt, look at other open-source drivers for clues on how the hardware works..
This is sort of like asking if your serial card supports PPP -- IPv6 vs. IPv4 is handled by a higher protocol layer and the card doesn't get involved at that level.
The one gotcha with ethernet hardware is that v6 makes somewhat heavier use of multicast (in place of broadcast), while most existing ipv4 systems don't use multicast at all. Certainly all earlier 3c9xx cards can deal (I'm running a small v4/v6 net at home using a mix of hardware including 3c905's and 3c900's and they're doing just fine). A more likely compatibility problem is incomplete drivers which don't know how to program the multicast receive filters on certain ethernet NIC's.
IPv6 addresses are 128 bits, typically partitioned into 64 bits of network number and 64 bits of host number. The host number can be assigned manually (as is typically done today with ipv4), derived from a 48-bit or 64-bit MAC address, or (this is what's new in the privacy proposal) generated randomly in a way unlikely to collide.
The network number is assigned by the network and is used to route the packet back to you, just as in IPv4.
Slashdot Mirror
so, not only does "load page table base register" or "load gdt base" or "load ldt selector" have to trap, but so does "store page table base register" or "store gdt base" or "store ldt selector"..
(Any individual virtual address space is limited to 4gb, which is a significant constraint, but no "bank switching" is needed)
I believe that what eventually will to evolve is a whole bunch of little problem-domain-specific public-key infrastructures, some of which will use x.509 certificate formats, some of which won't. pgp, ssh, secure dns, etc, all "do their own thing" and provide a public key infrastructure to attempt to solve the piece of the problem they care about without getting tangled into the morass of hierarchical PKI which caused Privacy Enhanced Mail (PEM) to sink without a trace..
The client retransmits to recover from a dropped SYN/ACK or dropped SYN; the *server* has to retransmit to recover from a dropped ACK (because you don't ever retransmit pure ACK's)
Without going into exhaustive detail, every TCP connection starts with 3 packets:
SYN (client->server)
SYN/ACK (server->client)
ACK (client->server)
If the ACK packet gets dropped (occasional packet loss is a fact of life in the Internet), and the application protocol is such that the server speaks first (which is the case for many protocols including SMTP, FTP, and SSH), the connection hangs.. the client expects the server to say something, and the server never says anything because it doesn't have any connection state saved from the SYN!
These have a number of non-evil uses, particularly when it comes to figuring out the topography of a redundant dual-ported setup..
That said, technical copy-prevention schemes continue to be doomed to failure..
A former employer of mine started down the software patent path for something I designed. I pointed out vigorously that the "invention" was an obvious combination of something I had implemented at a past job, and something which someone else had productized. Shortly thereafter, I was informed that they had decided to suspend the patent process...
NetBSD/alpha, for instance, is using ELF.
NetBSD/i386 and NetBSD/sparc have been switched from a.out to ELF in -current, and will switch to ELF in the 1.5 release.
We use slightly different terminology -- a NetBSD "port" is a port of NetBSD to a particular platform, and we install into /usr/pkg by default instead of /usr/local, to leave /usr/local free for truly local software, but if you're familiar with the FreeBSD ports collection, it should look very familiar to you..
See the list in the right-hand column on www.netbsd.org
Porting NetBSD is so easy that even we developers lose track of how many ports have been checked in to the master sources..
I think someone's just a little bit hypersensitive here...
Ever try to port a source-only driver from one OS to another? I have. it's often not much fun.. a well-written driver can serve as hardware documentation. a poorly written one, well, raises more questions about how the device works than it answers..
Given how many buggy drivers i've seen coming from hardware vendors.. they're often experts at the hardware, but have no clue how to do non-windows drivers. don't tempt them to turn their windows drivers into bad unix drivers... ask for hardware docs only!
At least some POP servers are reputed to do stupid stuff like copying a user's whole mailbox to a new file every time a user connects up, looks at headers, or deletes a message. While I don't have specific recommendations, I'd advise auditioning a few different packages to see what kind of I/O load they place on a disk farm. Also, you may be better off spreading your load across multiple (cheap) servers rather than putting all your eggs in one expensive basket.
Also, improperly tuned RAID-5-based systems can be slower than the disks they're built out of because of the need to do read-modify-write cycles to update the parity blocks..
actually, my laptop (Sony Z505S) has an on-board eepro 10/100 which seems to work just fine with ipv6 under NetBSD; seems to deal with multicast traffic for neighbor discovery just fine. when in doubt, look at other open-source drivers for clues on how the hardware works..
The one gotcha with ethernet hardware is that v6 makes somewhat heavier use of multicast (in place of broadcast), while most existing ipv4 systems don't use multicast at all. Certainly all earlier 3c9xx cards can deal (I'm running a small v4/v6 net at home using a mix of hardware including 3c905's and 3c900's and they're doing just fine). A more likely compatibility problem is incomplete drivers which don't know how to program the multicast receive filters on certain ethernet NIC's.
The network number is assigned by the network and is used to route the packet back to you, just as in IPv4.
See RFC2373: IP Version 6 Addressing Architecture as well as Privacy Extensions for Stateless Address Autoconfiguration in IPv6 for more details.