Although you could argue that the shareholders own the $40 billion (and Bill Gates works for them too), it's not like they can get their hands on it. If people sell the stock, they won't be selling it back to Microsoft, they will be selling it to other saps in the stock market.
In fact the $40 billion in cash puts a floor on how low the stock can go, since the stock shouldn't drop much below the breakup value of the company (what you would get if you bought the whole company, sold off the buildings, etc and took the $40 billion for yourself). Of course with a market cap of $275 billion the breakup value is a long way down.
I wasn't clear. I meant I did not want a law saying "all data formats must now be documented" -- I consider that to be intellectual property theft by the government. What I wanted was the government to say "all data format that we use must now be documented."
If this was done by law or executive order or whatever is less important, although as you say the method might influence how permanent it is. But I think if the government even just said that government procurement people should favor documented data formats, Microsoft would have the Office spec available the next day (or the day after it got done complaining about the new rule).
The linked-to article is confusing two things. First is when a trademarked name is ruled to be generic because the company was not enforcing it. One example (from a quick Google search) is "escalator". There are many words that are *used* as if they had become generic (kleenex, walkman, xerox, q-tip, band-aid, etc) and in some cases other companies have attempted to show that the term *has* become generic, but I don't think a lot of names have actually gone that way.
Now aspirin is a special case. The *patent* on aspirin was held by Bayer (a German company) and expired around the beginning of World War I. However Bayer still held the *trademark* on the name aspirin. But the US government stripped it from Bayer as part of the treaty ending the war.
This is a quote from a
longer article (about Cipro, also owned by Bayer and under patent suspension threat from the US gov):
The Alien Property Custodian, a wartime office charged with seizing enemy-owned assets on U.S. territory, was entitled to confiscate all German property -- intellectual and physical -- and that included the Bayer and Aspirin names. On Dec. 12, 1918, when the war had ended, all of Bayer's assets, including the names, were auctioned off to an American company, Sterling Drug.
In the 1920s, American courts dealt a huge blow to Sterling when it allowed Aspirin to be used as a generic term at the retail level. Other companies began selling the compound under that name, capitalizing on Bayer's huge advertising campaign initiated before the Great War. In Germany, Canada and many other countries, Aspirin is still a trademark (hence the capital A) and if you ask a pharmacist for aspirin, you will get Bayer Aspirin.
ANYWAY having said all that I think it is silly to say that because file formats are used a lot, they may become generic. A lot of people drink Coke, and nobody is saying its formula is about to become generic.
Proprietary formats that store user data are bogus. It's your data, and you are dependent on some company staying in business and continuing to support their format? So it's fine if someone wants to store game levels or whatever in some proprietary format, but the second there is data in there that belongs to the user, the format needs to be documented.
And the best way the government can accomplish this is not by passing a law -- I am strongly against the government taking something that a company feels is proprietary and simply making it public. But, it could be accomplished simply by stating that the government itself will only use documented formats for data, which will require all major software vendors to document theirs.
AND just to clarify, this is not saying that all formats should be standardized or designed by committee or only changed with public approval...companies can make whatever format they want and change it whenever they want, as long as they document it.
I guess in general avoiding copies is a good thing, it frees the CPU to do something else. You just may not always have something else for the CPU to do, but hey why not give it the opportunity.
I understand the issues you bring up, but I still think it can be done. You are thinking of it as receiving into one of the standard buffers you have preallocated into the netcard's receive ring, and then somehow making this map into the user's buffer. That's not what I mean.
I mean in certain cases (but cases that generally correspond to the ones you would care about, large transfers to a server), you have the user's buffer ahead of time, and furthermore there is just one client of the port, and TCP knows this because it has *assigned* the port to that client. For example when the ftp daemon is receiving a put command, it moves the client computer over to a random port, which it asks TCP to assign to it. Let's say TCP assigns port 0x9876. So TCP knows that only the ftp daemon is the only one using port 0x9876. And the ftp daemon has posted a big receive to get the data. So TCP can take that receive's buffer and hand it to the driver and say "all data [but not the headers] received on port 0x9876 goes in this buffer." Then the card packs the data in and in the normal case where every packet is received only once and in order, it works.
The firmware mod you would have to do is instead of the card having one big ring of receive buffers, it needs a bunch of "per-port" buffers (plus one big ring as before). Now that takes some space to set up the control, but the buffers themselves are all user buffers, so there is not a *lot* more storage needed. The firmware needs to pick out the port number "on the fly" while it is receiving the packet, but I think it could to that.
There may be alignment issues....maybe the card has to say "gee the next spot for packets to port 0x9876 has an address that is congruent to 3 modulo 4...so it has to put one extra byte somewhere (along with the header maybe) and then start its transfer at the 4-byte boundary.
If you want to slap down credentials, I was one of the main designers of both NDIS (the transport <-> network card interface) and TDI (the transport <-> level above) interfaces in NT. And I wrote several transports and netcard drivers. So I know a bit whereof I speak.
I would not say Softimage foughts its way free (I worked at Softimage from August 1995 to September 1996, an event chronicled in chapters 5, 6, and 7 of my
book, which you can start reading right here).
It would be more accurate to say Microsoft bought Softimage for unclear reasons, tried to Microsoftify it to some extent, decided it wasn't really worth owning, and found Avid as an exit strategy. Softimage was completely owned by Microsoft, and the decision on what to do with Softimage was made by Microsoft.
So how are things up there in the tundra...is Marche Michel still around?!?
I meant asynchronous I/O where the app is expecting it to be asynchronous. With sockets there is some way to wait for a write to complete (which I don't remember offhand, I'm much more familiar with the kernel parts), and using the NT API you can do a wait...I think even with Win32 file APIs you can wait. But I think the default is to have I/O be synchronous, so a dumb app will work. And I disagree that you can't expect an app doing asynchronous I/O not to touch a buffer until the write is done. That's just a broken app. What if it is multithreaded and changes the buffer during the write? What if it zeros it out BEFORE the write?!? Etc etc.
It's true some cards can't do a busmaster send from discontiguous buffers. So they do have to copy to contiguous memory, or to card memory, or do DMA, or whatever...but that's something the card driver has to just deal with. Nobody above the network card driver has to care.
So it sounds like the network card flag you mentioned is just an indicator of the ability to send discontiguous buffers directly? That is, a status indication, not something an app has to worry about....so that's fine, I withdraw my ragging on that.
Yes, you need separate buffers for the headers (I tried to explain this in my first post but wasn't that clear).
Let's say you get a 64K buffer from the user. So you hand it to the card and say "all data for port 0x1234 goes in here." Then you also give a chain of receive headers, 64 bytes or whatever. The processing after that should be pretty straightforward...when the card interrupts you with a packet received, it sets a flag saying that the data was put in a user buffer. Then the network card driver tells TCP it has a packet and that it has split header/data and the data is at location XXX. At that point the processing should be basically the same for TCP, verifying checksums and headers etc, but then at the last step where it would copy the data to the user's buffer, it just doesn't have to -- as long as the data was supposed to wind up at XXX.
The tricky case is handling drops and dups and out of order. For example if the fifth packet in a transfer is received third, then TCP can't just move it to the right spot because the card may be using that spot to receive another packet. In general trying to tell the card "oh you should back up and start receiving new packets here instead of here" is tricky timing because a packet may be coming in while you are trying to tell the card that.
Of course in situations like this TCP doesn't have to be perfectly optimized since you will likely need to retransmit anyway, but it shouldn't be terrible. And the card will also need to be given a set of general buffers for packets that are not to an expected port, or where the user buffer runs out of room, etc. Then TCP has to be clever about putting those packets in the right place.
You could have the card be smarter and actually known about where to put each packet, it couldn't even do acks and retransmit requests...but you don't want to make it too complicated. Plus I think you want to avoid having the card need to interpret any part of the packet that is encrypted during an IPSEC session (which I don't know exactly where that begins). Some cards do IPSEC in hardware but that is another issue.
And of course this only helps if the server is CPU-bound, as opposed to disk or network etc.
Don't know anything about Linux, but compared to NT this seems incredibly complicated. In NT you can take any user buffer, probe it, map it, and lock it. Don't have to worry about "user space behaviour" and whatnot. If the user is doing synchronous write()s (or whatever) the call won't even return until the kernel code tells says it is done with it. And for asynchronous, you would hope the user won't be walking all over the buffers it has handed over until the call is done. And in all cases the kernel components handle the buffers in the same way, you don't need your network card to indicate with a flag whether it can do zero-copy sends (?!?!?!?!?!?!?).
Sure you would have to only do it with certain things were true -- the user had already posted a buffer, nobody else was using that port, etc. But a standard situation like somebody ftp'ing up a huge file would match those conditions.
Now I confess I don't know anything about the internals of any Unix version. What I worked on was NT. And in NT this would be very easy (memory-management-wise I mean) as long as you had the user's buffer ahead of time...no need to have receive buffers aligned on a page boundary or anything. Since I don't know *nix, I don't know why that restriction would be needed. The card could receive anywhere in memory (doesn't need to be aligned)...and in NT you can map any user buffer into kernel space so any device driver can access it, then lock it to a physical address so the card can access it.
I'm surprised nobody has come up with hardware to do this. The problem is the network card needs to know about the user's buffer ahead of time. In the old days (i.e. 5 years ago) you had a mix of Netbeui and IPX and TCP on a network and it didn't make much sense to make a card intelligent enough to figure out where to put packets.
But now all anyone cares about is TCP. Furthermore, a typical copy of data to a server goes something like:
1) packet sent by the client to a known port on the server
2) a few packets to set things up and assign a dedicated server port
3) lots of data blasting from the client to the dedicated server port
4) some cleanup packets at the end
Step 3 is what you care about. So you would need to tell the network card, when you get packets for this port, put the data in this buffer in the order received, and put the headers here (in some small header-sized buffers TCP would also provide). Now you might get bad checksums (although the hardware could check that also) or drops or out of order, then you would need to rearrange...but in the 99%+ normal case you get all the packets in order with valid checksums. So the card stuffs the data in the right place, TCP checks the header buffers to make sure everything is kosher, and boom your data is in memory with no copies and off to disk (or wherever) it goes.
You need some other stuff like TCP has to be able to hint this to the network card driver, and figure out if more than one app is using a port (so it can turn all this optimization off) and so on. But hey when it worked it would be cool.
The other way this would work is if the network card was set up with a big chain of receive buffers and it would actually hand a buffer up to TCP (so it got taken out of the chain) and then eventually it would get it back...but this requires a lot of trust of the levels above TCP that ultimately decide when the receive data isn't needed anymore.
As Dilbert said this weekend...if you can understand the preceding, you have my sympathy.
You know when the packet was received when you get an ack for it (for TCP, with UDP you can just dump it to the network card and forget about it since it's unreliable delivery). Obviously in this situation you need to hold on to the user's buffer until you have gotten an ack, otherwise you don't have the data until you need to retransmit. But you want to optimize for the general case which is you do get an ack real quick and then you can just return the buffer...I suppose a clever TCP implementation using this would have some spare buffers, and after some time without an ack (maybe the first retransmission, maybe sooner), it would copy the data and give the user's buffer back. But again that is a rare case so the extra copy there doesn't matter.
As fow how noticeable they will be...according to the email, it increased from 52 megabits/second to almost 90 megabits/second. But transmitting over a series of hops (like on the Internet), your speed is gated by the slowest link or router, and it is doubtful the whole end-to-end chain will be able to handle 90 Mbps (or 52 Mbps for that matter). So even with a monster send window you would still need to stop transmitting well before you got an ack and could send more.
Of course on a local 100 Mbps Ethernet playing networked games this could be quite nice.
Where in the article does it say anything about Microsoft being able "to prevent competitors' programmes from being installed"?!? I'm sure several people submitted the NYT link, was this the least biased writeup that the editors could find?
Look, with the settlement as written, Microsoft will release a new OS, some app will break (as they inevitably do) -- then it becomes a big shouting match about did Microsoft do it on purpose or not. Who does that help?
The problem with all this stuff is they are trying to do one thing, which is protect Netscape, but they have to write it in some generic legal way so that isn't obvious -- so you wind up with vague terms like "good cause".
The fact that Microsoft thinks it is just shows how clueless they are about this (something I was trying to remedy when I was there).
You generally only need to attend to your headless machine when something goes wrong. So guess what goes wrong a lot...the network! So much for Terminal Services. Unless you have a second net card on an internal net (which you might want to have anyway as opposed to leaving a Terminal Services session on your public network)...but as you can see people care about having a *VGA* card in their servers, a second net card is even more $$$. If you are trying to get a 1U server in a rack, every bit of hardware counts.
Anyway the proper way to do headless is over a serial port, to a command-line prompt. Sun boxes have a dedicated port for this; x86 Unix machines do this over a standard serial port; there are some non-Microsoft products for Windows 2000 that do this, providing a command-prompt you can connect to over a serial port, but they are hampered by a) the lack of command-line tools and b) the fact that they don't run at elevated priority so they won't work for a lot of hung systems. This should be much improved with.NET Server.
I am pretty sure that the NT loader (that loads the kernel etc) has a check in it for the presence of VGA hardware.
How sure am I? Well, before I left Microsoft, I was a developer working on headless support for Windows XP (work that I think will first appear in the server version of XP, which I think is going to be called Windows.NET server). And the dependency was there then in the shipped Windows 2000, so unless it was removed in a service pack, it is still there.
Actually I'm surprised you can even get the machine booted far enough to ping it.
There were some BIOSes out there that allow booting without VGA so it's not a pure BIOS limitation.
There is a guide to "lights out operation" (a term Microsoft sometimes uses which may help you in your search) posted
here
on Microsoft's site. It is interesting for its hardware solutions but it is 3 years old and covers NT 4 (which did not have the VGA requirement).
Hey who modded that down! Glad to see someone is paying attention to my writing...
- adam
P.S. As in, using "Linux" to refer to an entire GNU/Linux distribution.
If you want to try to arrange a local screening...
on
Revolution OS
·
· Score: 2
This is email I got from the filmmaker:
From: "J.T.S. Moore"
The key is to make the local arthouse theaters aware of the number of people passionate about Linux. Most arthouse theater bookers are not really conscious of the Open Source movement. If people do try to lobby their local arthouse theater, tell them the distributor is Seventh Art Releasing in Los Angeles.
Also, people interested in screenings can also e-mail info@revolution-os.com. I cannot promise that the distributor will be able to set up anything, but any feedback helps. At some point in the near future, I hope to make the film available on videotape for LUGs to screen it at their meetings.
The SMB/CIFS license I thought was to satisfy the European investigation. Perens is bollixing that up with the Justice Department/nine states settlement, which would involve documenting the protocol, but I don't think says anything about releasing the source, and in any case is off in the future, since the settlement has not been accepted yet.
And the part about "MS's 'Trustworthy Computing' campaign has failed once again" is silly. They just reviewed the code in the last couple of months. The new code has not yet been magically transported onto every machine with IIS installed.
I'm not saying that IIS is not a pile of slop, of course.
If.Net just winds up being another version of Java, that is a wasted opportunity. The goal should be to not have to worry about sandboxing the unknown code you bring down from a website to run on your machine -- because you don't do that. Instead, you make RPC calls to that machine. That is what the XML part is about.
What dumping Hailstorm shows is that Microsoft's plan to use Hailstorm to establish the.Net platform was bogus. They need to first get.Net established. Then they can worry about.Net "applications" like Hailstorm.
Wired recently ran an
article
about game AI and how realistic it was. Typical breathless sentence: "Watching those sprites dance on the screen, you can't help but think that these simulated minds are displaying emotions - joy, solidarity, love for life - that are unfathomable in a videogame".
This seems a bit much even for Wired. The creatures in these games are following a predefined set of rules, certainly they are a complex set of rules, but the way they "learn" is entirely predetermined (that is, what they learn depends on what they are exposed to, but the formula for converting exposure into knowledge is set by the game designers). I think the fact that the graphics are rendered so realistically makes it easier to make the leap to thinking they are really acting "intelligent."
Who knows what really sets human intelligence apart, is it ability to make rules or nondeterministic memory or whatever, but it seems evident (to me, in my ever-so-humble opinion) that these creatures don't have it.
You are correct that the disruptive technology can be the way a product is created.
As I mentioned in the article on kuro5hin I linked to, Linux is not fundamentally developed differently from Windows. It is still written in C, compiled, debugged, tested, etc the same way. The open source nature is a secondary aspect. Of course many OSS aspects will disagree with me. But if you had an OS produced by really different means...say by the oft-longed-for, mythical method of just "compiling" a requirements definition...now that would be disruptive!!
The GPL and open source development are different and do have advantages compared to how Windows is developed. But I'm still not sure they fit the structure defined in The Innovator's Dilemma of customers leading an existing company upmarket until it is replaced by something "good enough". In particular who are the "customers" for the source license of an operating system.
I have written elsewhere that you can split the value of open source into two aspects, the fact that source code is available and the fact that there is little intellectual property hoarding. I don't know if the source code issue has a disruptive aspect because I don't think Microsoft's customers are telling them "hide the code" and then suddenly the available code becomes "good enough" (except maybe in security where the "we keep the code secret for your protection" model will be disrupted by the "anyone can see the code" model).
HOWEVER I will say that maybe the "protect the intellectual property" aspect of Microsoft's software is prime for disruption by the OSS "share the intellectual property" model. That is, customers think it is a good sign when Microsoft has patented technology and proprietary protocols, but then they will wake up and realize that the OSS stuff is "good enough" (probably better actually!) and open protocols are "good enough" (again, probably better).
I thought Eric Raymond said something funny in the article: "You get a disruptive technology... that is initially much lower price and reliability, but it's cost-effective in niche markets where low cost is really important". Is he really saying Linux has lower reliability! Perish the thought! But I think he felt he had to say it, in order to make Linux fit the disruptive technology model better.
Slashdot Mirror
In fact the $40 billion in cash puts a floor on how low the stock can go, since the stock shouldn't drop much below the breakup value of the company (what you would get if you bought the whole company, sold off the buildings, etc and took the $40 billion for yourself). Of course with a market cap of $275 billion the breakup value is a long way down.
- adam
If this was done by law or executive order or whatever is less important, although as you say the method might influence how permanent it is. But I think if the government even just said that government procurement people should favor documented data formats, Microsoft would have the Office spec available the next day (or the day after it got done complaining about the new rule).
- adam
Now aspirin is a special case. The *patent* on aspirin was held by Bayer (a German company) and expired around the beginning of World War I. However Bayer still held the *trademark* on the name aspirin. But the US government stripped it from Bayer as part of the treaty ending the war. This is a quote from a longer article (about Cipro, also owned by Bayer and under patent suspension threat from the US gov):
The Alien Property Custodian, a wartime office charged with seizing enemy-owned assets on U.S. territory, was entitled to confiscate all German property -- intellectual and physical -- and that included the Bayer and Aspirin names. On Dec. 12, 1918, when the war had ended, all of Bayer's assets, including the names, were auctioned off to an American company, Sterling Drug.
In the 1920s, American courts dealt a huge blow to Sterling when it allowed Aspirin to be used as a generic term at the retail level. Other companies began selling the compound under that name, capitalizing on Bayer's huge advertising campaign initiated before the Great War. In Germany, Canada and many other countries, Aspirin is still a trademark (hence the capital A) and if you ask a pharmacist for aspirin, you will get Bayer Aspirin.
ANYWAY having said all that I think it is silly to say that because file formats are used a lot, they may become generic. A lot of people drink Coke, and nobody is saying its formula is about to become generic.
- adam
And the best way the government can accomplish this is not by passing a law -- I am strongly against the government taking something that a company feels is proprietary and simply making it public. But, it could be accomplished simply by stating that the government itself will only use documented formats for data, which will require all major software vendors to document theirs.
AND just to clarify, this is not saying that all formats should be standardized or designed by committee or only changed with public approval...companies can make whatever format they want and change it whenever they want, as long as they document it.
So for this I came up with the idea of the Open Data Format Initiative...which I have done nothing with yet, but might one of these years. I even bounced the idea off a few politicians!
- adam
I guess in general avoiding copies is a good thing, it frees the CPU to do something else. You just may not always have something else for the CPU to do, but hey why not give it the opportunity.
- adam
- adam
I mean in certain cases (but cases that generally correspond to the ones you would care about, large transfers to a server), you have the user's buffer ahead of time, and furthermore there is just one client of the port, and TCP knows this because it has *assigned* the port to that client. For example when the ftp daemon is receiving a put command, it moves the client computer over to a random port, which it asks TCP to assign to it. Let's say TCP assigns port 0x9876. So TCP knows that only the ftp daemon is the only one using port 0x9876. And the ftp daemon has posted a big receive to get the data. So TCP can take that receive's buffer and hand it to the driver and say "all data [but not the headers] received on port 0x9876 goes in this buffer." Then the card packs the data in and in the normal case where every packet is received only once and in order, it works.
The firmware mod you would have to do is instead of the card having one big ring of receive buffers, it needs a bunch of "per-port" buffers (plus one big ring as before). Now that takes some space to set up the control, but the buffers themselves are all user buffers, so there is not a *lot* more storage needed. The firmware needs to pick out the port number "on the fly" while it is receiving the packet, but I think it could to that.
There may be alignment issues....maybe the card has to say "gee the next spot for packets to port 0x9876 has an address that is congruent to 3 modulo 4...so it has to put one extra byte somewhere (along with the header maybe) and then start its transfer at the 4-byte boundary.
If you want to slap down credentials, I was one of the main designers of both NDIS (the transport <-> network card interface) and TDI (the transport <-> level above) interfaces in NT. And I wrote several transports and netcard drivers. So I know a bit whereof I speak.
- adam
It would be more accurate to say Microsoft bought Softimage for unclear reasons, tried to Microsoftify it to some extent, decided it wasn't really worth owning, and found Avid as an exit strategy. Softimage was completely owned by Microsoft, and the decision on what to do with Softimage was made by Microsoft.
So how are things up there in the tundra...is Marche Michel still around?!?
- adam
It's true some cards can't do a busmaster send from discontiguous buffers. So they do have to copy to contiguous memory, or to card memory, or do DMA, or whatever...but that's something the card driver has to just deal with. Nobody above the network card driver has to care.
So it sounds like the network card flag you mentioned is just an indicator of the ability to send discontiguous buffers directly? That is, a status indication, not something an app has to worry about....so that's fine, I withdraw my ragging on that.
- adam
Let's say you get a 64K buffer from the user. So you hand it to the card and say "all data for port 0x1234 goes in here." Then you also give a chain of receive headers, 64 bytes or whatever. The processing after that should be pretty straightforward...when the card interrupts you with a packet received, it sets a flag saying that the data was put in a user buffer. Then the network card driver tells TCP it has a packet and that it has split header/data and the data is at location XXX. At that point the processing should be basically the same for TCP, verifying checksums and headers etc, but then at the last step where it would copy the data to the user's buffer, it just doesn't have to -- as long as the data was supposed to wind up at XXX.
The tricky case is handling drops and dups and out of order. For example if the fifth packet in a transfer is received third, then TCP can't just move it to the right spot because the card may be using that spot to receive another packet. In general trying to tell the card "oh you should back up and start receiving new packets here instead of here" is tricky timing because a packet may be coming in while you are trying to tell the card that.
Of course in situations like this TCP doesn't have to be perfectly optimized since you will likely need to retransmit anyway, but it shouldn't be terrible. And the card will also need to be given a set of general buffers for packets that are not to an expected port, or where the user buffer runs out of room, etc. Then TCP has to be clever about putting those packets in the right place.
You could have the card be smarter and actually known about where to put each packet, it couldn't even do acks and retransmit requests...but you don't want to make it too complicated. Plus I think you want to avoid having the card need to interpret any part of the packet that is encrypted during an IPSEC session (which I don't know exactly where that begins). Some cards do IPSEC in hardware but that is another issue.
And of course this only helps if the server is CPU-bound, as opposed to disk or network etc.
- adam
- adam
Now I confess I don't know anything about the internals of any Unix version. What I worked on was NT. And in NT this would be very easy (memory-management-wise I mean) as long as you had the user's buffer ahead of time...no need to have receive buffers aligned on a page boundary or anything. Since I don't know *nix, I don't know why that restriction would be needed. The card could receive anywhere in memory (doesn't need to be aligned)...and in NT you can map any user buffer into kernel space so any device driver can access it, then lock it to a physical address so the card can access it.
- adam
But now all anyone cares about is TCP. Furthermore, a typical copy of data to a server goes something like:
1) packet sent by the client to a known port on the server
2) a few packets to set things up and assign a dedicated server port
3) lots of data blasting from the client to the dedicated server port
4) some cleanup packets at the end
Step 3 is what you care about. So you would need to tell the network card, when you get packets for this port, put the data in this buffer in the order received, and put the headers here (in some small header-sized buffers TCP would also provide). Now you might get bad checksums (although the hardware could check that also) or drops or out of order, then you would need to rearrange...but in the 99%+ normal case you get all the packets in order with valid checksums. So the card stuffs the data in the right place, TCP checks the header buffers to make sure everything is kosher, and boom your data is in memory with no copies and off to disk (or wherever) it goes.
You need some other stuff like TCP has to be able to hint this to the network card driver, and figure out if more than one app is using a port (so it can turn all this optimization off) and so on. But hey when it worked it would be cool.
The other way this would work is if the network card was set up with a big chain of receive buffers and it would actually hand a buffer up to TCP (so it got taken out of the chain) and then eventually it would get it back...but this requires a lot of trust of the levels above TCP that ultimately decide when the receive data isn't needed anymore.
As Dilbert said this weekend...if you can understand the preceding, you have my sympathy.
- adam
As fow how noticeable they will be...according to the email, it increased from 52 megabits/second to almost 90 megabits/second. But transmitting over a series of hops (like on the Internet), your speed is gated by the slowest link or router, and it is doubtful the whole end-to-end chain will be able to handle 90 Mbps (or 52 Mbps for that matter). So even with a monster send window you would still need to stop transmitting well before you got an ack and could send more.
Of course on a local 100 Mbps Ethernet playing networked games this could be quite nice.
- adam
Look, with the settlement as written, Microsoft will release a new OS, some app will break (as they inevitably do) -- then it becomes a big shouting match about did Microsoft do it on purpose or not. Who does that help?
The problem with all this stuff is they are trying to do one thing, which is protect Netscape, but they have to write it in some generic legal way so that isn't obvious -- so you wind up with vague terms like "good cause".
- adam
You generally only need to attend to your headless machine when something goes wrong. So guess what goes wrong a lot...the network! So much for Terminal Services. Unless you have a second net card on an internal net (which you might want to have anyway as opposed to leaving a Terminal Services session on your public network)...but as you can see people care about having a *VGA* card in their servers, a second net card is even more $$$. If you are trying to get a 1U server in a rack, every bit of hardware counts.
Anyway the proper way to do headless is over a serial port, to a command-line prompt. Sun boxes have a dedicated port for this; x86 Unix machines do this over a standard serial port; there are some non-Microsoft products for Windows 2000 that do this, providing a command-prompt you can connect to over a serial port, but they are hampered by a) the lack of command-line tools and b) the fact that they don't run at elevated priority so they won't work for a lot of hung systems. This should be much improved with .NET Server.
- adam
How sure am I? Well, before I left Microsoft, I was a developer working on headless support for Windows XP (work that I think will first appear in the server version of XP, which I think is going to be called Windows .NET server). And the dependency was there then in the shipped Windows 2000, so unless it was removed in a service pack, it is still there.
Actually I'm surprised you can even get the machine booted far enough to ping it.
There were some BIOSes out there that allow booting without VGA so it's not a pure BIOS limitation.
There is a guide to "lights out operation" (a term Microsoft sometimes uses which may help you in your search) posted here on Microsoft's site. It is interesting for its hardware solutions but it is 3 years old and covers NT 4 (which did not have the VGA requirement).
- adam
- adam
P.S. As in, using "Linux" to refer to an entire GNU/Linux distribution.
- adam
The Trustworthy Computing initiative failures will start showing up next year.
- adam
I'm not saying that IIS is not a pile of slop, of course.
- adam
What dumping Hailstorm shows is that Microsoft's plan to use Hailstorm to establish the .Net platform was bogus. They need to first get .Net established. Then they can worry about .Net "applications" like Hailstorm.
- adam
This seems a bit much even for Wired. The creatures in these games are following a predefined set of rules, certainly they are a complex set of rules, but the way they "learn" is entirely predetermined (that is, what they learn depends on what they are exposed to, but the formula for converting exposure into knowledge is set by the game designers). I think the fact that the graphics are rendered so realistically makes it easier to make the leap to thinking they are really acting "intelligent."
Who knows what really sets human intelligence apart, is it ability to make rules or nondeterministic memory or whatever, but it seems evident (to me, in my ever-so-humble opinion) that these creatures don't have it.
- adam
As I mentioned in the article on kuro5hin I linked to, Linux is not fundamentally developed differently from Windows. It is still written in C, compiled, debugged, tested, etc the same way. The open source nature is a secondary aspect. Of course many OSS aspects will disagree with me. But if you had an OS produced by really different means...say by the oft-longed-for, mythical method of just "compiling" a requirements definition...now that would be disruptive!!
The GPL and open source development are different and do have advantages compared to how Windows is developed. But I'm still not sure they fit the structure defined in The Innovator's Dilemma of customers leading an existing company upmarket until it is replaced by something "good enough". In particular who are the "customers" for the source license of an operating system.
I have written elsewhere that you can split the value of open source into two aspects, the fact that source code is available and the fact that there is little intellectual property hoarding. I don't know if the source code issue has a disruptive aspect because I don't think Microsoft's customers are telling them "hide the code" and then suddenly the available code becomes "good enough" (except maybe in security where the "we keep the code secret for your protection" model will be disrupted by the "anyone can see the code" model).
HOWEVER I will say that maybe the "protect the intellectual property" aspect of Microsoft's software is prime for disruption by the OSS "share the intellectual property" model. That is, customers think it is a good sign when Microsoft has patented technology and proprietary protocols, but then they will wake up and realize that the OSS stuff is "good enough" (probably better actually!) and open protocols are "good enough" (again, probably better).
I thought Eric Raymond said something funny in the article: "You get a disruptive technology... that is initially much lower price and reliability, but it's cost-effective in niche markets where low cost is really important". Is he really saying Linux has lower reliability! Perish the thought! But I think he felt he had to say it, in order to make Linux fit the disruptive technology model better.
- adam