Excess Nitrogen is actually more dangerous to people than CO2, because it turns out we detect lack of Oxygen by an excess of CO2, not by an actual lack of oxygen. If the problem is excess Nitrogen, our bodies never notice, in fact they might even see a reduced level of CO2 and assume that Oxygen is plentiful.
The Smart ForTwo's main advertising point (apart from it's small size and fuel efficiency) is the visible "Tridion" frame around the passenger compartment, showing that you're going to be safe.
Now look up your BMW (I can't, as you didn't give the model).
A little reading leads me to find that the "one way" cable modems were often capable of two-way cable (but the network wasn't) and/or had a phone-line modem built in too, making them capable of both modulation and demodulation (though on two lines).
Except it isn't digital not even slightly. Transmitting over the distances they do REQUIRES an analogue signal (i.e. transmitting a waveform in varying frequency/phase/amplitude representing the digital signal instead of using the high/low peaks of the wave to represent bits).
That depends, are you in London? Some other big city? No? Then no.
Then again, my parents are in a small village in the middle of Norfolk and they get full 8 Mbps ADSL (I've tested it). The village is so small that the local junior school collects students from several villages and still has to combine several years of students into the same classes, instead of the traditional several classes of students per year. The village is home to the phone exchange which serves the surrounding villages, which is most likely the reason they get full speed ADSL.
I'm in the Newcastle area, and could get Virgin's 50 Mbps cable connection if I wanted (I'm on their 10 Mbps service). However the upstream side of the connection leaves a little to be desired.
Windows' solution is pretty nice. You can pass a pre-created socket handle to accept_ex, which automatically accepts an incoming connection using that socket handle, so that you don't have to use two system calls (select and accept). You can also pre-accept multiple sockets, instead of having to make the system calls under load. Sockets can also be closed with a "re-use" flag, which leaves the handle valid and saves making a system call to create another.
You then associate the sockets with an "IO completion port", which as best as I can tell is a multithreaded-safe linked list for really fast kernel to user program communication. To receive from the socket you make an async receive call, giving a pointer to a buffer to receive into. Whenever data is received on those sockets (and has had a corresponding async request made for it already) the kernel automatically queues the socket handle to that linked list. If you associate a socket with the completion port before you accept a connection with it (i.e. you're using acceptex) it also triggers when the socket accepts a connection. In the user code, you run multiple threads listening on the completion port (you can also use the completion port in the thread pooling API, which runs two threads to each cpu core by default). When a message arrives from the kernel, the most recently finished thread wakes and processes the received data, which will already be in the user-space buffer you provided in the original receive call.
If all threads are busy and there are messages in the completion port they will bounce right off of the completion port, picking up the next bit of completed IO they need to process without making a system call.
At one point in the original I managed to trigger a bug where one of the enemy's "road flags" was literally on our border, and I found I could join my road to it.
My peasants went and stole everything he had lying around.:)
I loved that game, partly because on the Amiga you could do two-player multiplayer with two mice in splitscreen.
However, DLP has its own problems (the rainbow effect is awesome!). LCoS is just another LCD-based technology (assuming I understood the wiki page on LCoS correctly), just with the LCD directly mounted on a mirror instead of projecting through it (and therefore I assume it has the same problem with light getting through "black" as a through-projection LCD). The Wikipedia article on LCoS has an uncited statement that LCoS is better contrast than projecting through an LCD, but doesn't mention black level at all.
LED backlights are no good on very large panels, because they use LED strips around the edge or on one side and a large light diffuser, which still produces an uneven result at large panel sizes. ELP is far better (it's a full panel sized light over the whole display), but far more expensive, and can still have trouble getting even illumination.
XP x64 has been my primary/gaming PC's OS (through three (IIRC) PC parts upgrades) since MS did the free XP to XP x64 upgrade for people with "64 bit" PCs which only had a 32-bit XP on.
Driver support is pretty awesome. Even my no-brand webcam works.
However an IO bottleneck will have a tendency to freeze any programs using the same IO device in blocking mode. e.g. trying to browse the web while bittorrent is going at full speed often causes the browser to time out.
Even then that's due to lack of a decent IO scheduler. IIRC XP's is first come first served, aka greedy git takes all. In XP the greedy process even gets disk IO priority over the Windows kernel trying to page another process back in from page file, meaning a disk and ram-usage heavy program can practically lock up the entire pc, by forcing other processes (including explorer) to completely page out to disk and then consuming all the disk IO, denying them a chance to page back in. You can't even start task manager and kill the offending process while this is happening, because Windows can't get any disk IO time to read the tiny taskman.exe.
And in the case of the server specifying multiple accepted charsets (say ISO-8859-1 and UTF-8), there is no standard for how the client should inform the server which charset it used.
However, having remote access to the host of a bunch of virtual machines would be the equivalent of physical access to those virtual machines. You can change the mounted media, reboot them...
I never said it was. I said browsers submit forms (e.g. the comment form) in either the page's charset or in utf-8 if that isn't possible, but don't tell the server which. Which implies that the page's charset isn't already utf-8.
It's possible that the server is safely storing and handling utf-8 data, and it is just the charset being sent by the server in the content-type header which is causing the BROWSER to screw up the rendering. I'll check.
It's not just slashdot, it's also the fact that HTML/HTTP provides no way to know what charset a form was submitted in. Some browsers append a charset to the content-type http header they send, but most try to send in the same charset as the page, or utf-8 if that's not possible, but don't tell the server which...
I.E. is even better, as it ignores the charset the server sends in its HTTP content-type header and tries to guess instead, unless you put a content-type meta tag in the page.
Slashdot Mirror
Excess Nitrogen is actually more dangerous to people than CO2, because it turns out we detect lack of Oxygen by an excess of CO2, not by an actual lack of oxygen. If the problem is excess Nitrogen, our bodies never notice, in fact they might even see a reduced level of CO2 and assume that Oxygen is plentiful.
If you look up crash tests of the Smart ForTwo on youtube you might be surprised: http://www.youtube.com/watch?v=mz-s1sIoLhU
The Smart ForTwo's main advertising point (apart from it's small size and fuel efficiency) is the visible "Tridion" frame around the passenger compartment, showing that you're going to be safe.
Now look up your BMW (I can't, as you didn't give the model).
Or a P4...
A little reading leads me to find that the "one way" cable modems were often capable of two-way cable (but the network wasn't) and/or had a phone-line modem built in too, making them capable of both modulation and demodulation (though on two lines).
It's a bit clunky, but so is the stupid idea.
Except it isn't digital not even slightly. Transmitting over the distances they do REQUIRES an analogue signal (i.e. transmitting a waveform in varying frequency/phase/amplitude representing the digital signal instead of using the high/low peaks of the wave to represent bits).
ADSL uses variants of QAM modulation.
See: http://en.wikipedia.org/wiki/Carrierless_Amplitude_Phase_Modulation and http://en.wikipedia.org/wiki/Discrete_multitone_modulation for descriptions of the two modulations used in ADSL.
That depends, are you in London? Some other big city? No? Then no.
Then again, my parents are in a small village in the middle of Norfolk and they get full 8 Mbps ADSL (I've tested it). The village is so small that the local junior school collects students from several villages and still has to combine several years of students into the same classes, instead of the traditional several classes of students per year. The village is home to the phone exchange which serves the surrounding villages, which is most likely the reason they get full speed ADSL.
I'm in the Newcastle area, and could get Virgin's 50 Mbps cable connection if I wanted (I'm on their 10 Mbps service). However the upstream side of the connection leaves a little to be desired.
It doesn't emulate Vista because 7 is 100% Vista compatible. Nothing to emulate.
There's a program compatibility option, and all it does is report "Vista" as the OS instead of 7.
Windows' solution is pretty nice. You can pass a pre-created socket handle to accept_ex, which automatically accepts an incoming connection using that socket handle, so that you don't have to use two system calls (select and accept). You can also pre-accept multiple sockets, instead of having to make the system calls under load.
Sockets can also be closed with a "re-use" flag, which leaves the handle valid and saves making a system call to create another.
You then associate the sockets with an "IO completion port", which as best as I can tell is a multithreaded-safe linked list for really fast kernel to user program communication. To receive from the socket you make an async receive call, giving a pointer to a buffer to receive into.
Whenever data is received on those sockets (and has had a corresponding async request made for it already) the kernel automatically queues the socket handle to that linked list. If you associate a socket with the completion port before you accept a connection with it (i.e. you're using acceptex) it also triggers when the socket accepts a connection.
In the user code, you run multiple threads listening on the completion port (you can also use the completion port in the thread pooling API, which runs two threads to each cpu core by default). When a message arrives from the kernel, the most recently finished thread wakes and processes the received data, which will already be in the user-space buffer you provided in the original receive call.
If all threads are busy and there are messages in the completion port they will bounce right off of the completion port, picking up the next bit of completed IO they need to process without making a system call.
I saw one of those for sale at a computer faire quite a few years ago. I was tempted to buy it for the novelty, but I was young and poor at the time.
Now I have an eee 901.
Could you run Photoshop or do your .NET development on a netbook anyway?
No? Moot point then.
Back in the day I had hilarious fun trying to use Norton's (I think) tool for making a bootable virus scan disk.
It put the bootable OS and virus scanner on one floppy, and the virus definitions file on another.
Except that the virus definitions file didn't FIT on a "1.44MB" floppy.
At one point in the original I managed to trigger a bug where one of the enemy's "road flags" was literally on our border, and I found I could join my road to it.
My peasants went and stole everything he had lying around. :)
I loved that game, partly because on the Amiga you could do two-player multiplayer with two mice in splitscreen.
Tennis For Two
Created in 1958 on an analogue computer. ANALOGUE!
However, DLP has its own problems (the rainbow effect is awesome!). LCoS is just another LCD-based technology (assuming I understood the wiki page on LCoS correctly), just with the LCD directly mounted on a mirror instead of projecting through it (and therefore I assume it has the same problem with light getting through "black" as a through-projection LCD). The Wikipedia article on LCoS has an uncited statement that LCoS is better contrast than projecting through an LCD, but doesn't mention black level at all.
LED backlights are no good on very large panels, because they use LED strips around the edge or on one side and a large light diffuser, which still produces an uneven result at large panel sizes. ELP is far better (it's a full panel sized light over the whole display), but far more expensive, and can still have trouble getting even illumination.
Digital projectors often suffer the same problem, as they use a much stronger light projecting a small LCD, it tends to bleed through the black.
There are projectors which dim their bulb for dark images just like you described flat panel TVs doing.
Probably a problem with larger TVs only, which can only use strong backlights around the edges, causing a lot of problems trying to light the middle.
My 22" computer monitor has no trouble what-so-ever with black. Or contrast.
Which drivers?
XP x64 has been my primary/gaming PC's OS (through three (IIRC) PC parts upgrades) since MS did the free XP to XP x64 upgrade for people with "64 bit" PCs which only had a 32-bit XP on.
Driver support is pretty awesome. Even my no-brand webcam works.
However an IO bottleneck will have a tendency to freeze any programs using the same IO device in blocking mode. e.g. trying to browse the web while bittorrent is going at full speed often causes the browser to time out.
Even then that's due to lack of a decent IO scheduler. IIRC XP's is first come first served, aka greedy git takes all. In XP the greedy process even gets disk IO priority over the Windows kernel trying to page another process back in from page file, meaning a disk and ram-usage heavy program can practically lock up the entire pc, by forcing other processes (including explorer) to completely page out to disk and then consuming all the disk IO, denying them a chance to page back in. You can't even start task manager and kill the offending process while this is happening, because Windows can't get any disk IO time to read the tiny taskman.exe.
I think this was fixed in Vista.
I always thought "disks" were those square magnetic things and "discs" were those round mirrored things.
Unfortunately, 16-bit Windows 9x apps can't be run on Windows x64 either, and dosbox can't run them...
Unfortunately IE seems to ignore that completely.
And in the case of the server specifying multiple accepted charsets (say ISO-8859-1 and UTF-8), there is no standard for how the client should inform the server which charset it used.
However, having remote access to the host of a bunch of virtual machines would be the equivalent of physical access to those virtual machines. You can change the mounted media, reboot them...
Forcing the browser to utf-8 doesn't fix the corrupted text, so Slashdot is obviously mangling it server-side.
I never said it was.
I said browsers submit forms (e.g. the comment form) in either the page's charset or in utf-8 if that isn't possible, but don't tell the server which. Which implies that the page's charset isn't already utf-8.
It's possible that the server is safely storing and handling utf-8 data, and it is just the charset being sent by the server in the content-type header which is causing the BROWSER to screw up the rendering. I'll check.
And in other news, Slashdot still fails at UTF8.
It's not just slashdot, it's also the fact that HTML/HTTP provides no way to know what charset a form was submitted in. Some browsers append a charset to the content-type http header they send, but most try to send in the same charset as the page, or utf-8 if that's not possible, but don't tell the server which...
I.E. is even better, as it ignores the charset the server sends in its HTTP content-type header and tries to guess instead, unless you put a content-type meta tag in the page.