There are a large number of great USB to serial port adapters on the market
FTFY
Most USB to serial port adaptors have lower voltages than serial ports traditionally had and afaict ALL of them have much higher latencies than traditional serial ports. These issues will cause some equipment not to work. The first issue can be solved by building your own adaptor with custom level shift circuitry but there is really nothing you can do about the second issue.
Sure, PDFs are great for printing, but who prints anymore? It's 2011.
I do because when reading a long document I preffer to do it on paper than on screen;)
get rid of PDFs entirely.
Going from printed to pdf was a relatively easy transition. Just install a printer driver or a plugin in your document preperation system and you are good to go. For big documents you probablly want to convert the TOC to bookmarks but even that isn't too big a deal (for latex users the hyperref package can do it and IIRC for word users the hyperref package can do it). Even paper documents could be converted to PDF if necessary though the results were often less than ideal. Storing stuff electronically represented a major convenience improvement and cost saving over a photocopy on request system (which afaict is how both academic papers and component datasheets were handled in the days before PDF).
Preparing reflowable documents on the other hand requires a totally different workflow than preparing sequences of pages. Making a workflow that does both well (because you still have to provide a printed/printable version) is even harder. Further even if all new documents were prepared to be reflowable (fat chance) that still doesn't provide a soloution for existing non-reflowable content.
Because when you are comparing parts it's so much easier to have the PDFs open in tabs of the same window as the search that found them than having to open them in a seperate app, look at them and then find the browser window you were using again. Especially if you are working on windows which doesn't have virtual desktops.
I just hope this new PDF system is actually fit for the purpose of looking at things like IC data sheets (which means it MUST support PDF bookmarks and it MUST NOT choke on large PDF files).
Is it really lying? is there a formal definition of the "hyperthreading bit"
In both cases you have two logical cores that share some computing resources, the only difference is in what computing resources are shared. From the point of view of an OS scheduler knowing exactly which computing resources are shared is FAR less important than knowing that resources are shared
If he is REALLY spending $8000 more on an intel server than an AMD one then either he is getting MASSIVELY ripped off, comparing servers that are radically different in other ways or comparing servers with more than 2 sockets.
That sounds like extreme hyperbole to me. Care to show me a case where an Intel server costs that much more than an AMD one with equivalent computing power.
Note that register size and address size need not be the same. There were many processors out there with 16-bit memory addresses but only 8-bit registers and data bus. Likewise most 16-bit systems had some mechanism for accessing more than 2^16 memory addresses. Even 32-bit systems often had mechanisms for accessing more than 2^32 memory address though they were little used.
OTOH 64-bit CPUs often don't bother with support for full 64-bit addresses (though they are often designed so they can be allowed in future without changing userland code) because people simply don't have anywhere near that much memory.
I don't think there is much point increasing the size of integer data words beyond 64-bit. Most apps simply don't need numbers that big.
Notice how amount of oil used to make electricity is NEGLIGIBLE compared to either the total amount of energy used to make electricity or the total amount of oil used. Electricity comes mostly from natural gas, coal, nuclear and hydro (in that order).
Well it was marketed as XP but really under the hood it's 2K3.
although it never was supported very well by other vendors
The big vendors of core hardware like intel, NVIDIA etc support it just fine. Support from vendors of less core hardware is patchy (few officially support it but in practice the drivers for vista and win7 usually work).
XP wasn't written for 6 or more CPUs/cores
XP was derived from 2K which was written to support far more than that.
Originally, vanilla 2K only was "licensed" for two CPUs
Depends which edition you bought. Pro was 2, server was 4, advanced server was 8 and datacenter server was 32. Afaict win2K didn't understand hyperthreading or multicore though so every logical processor counted against the limit of your edition.
Individual end user lines may not usually cross borders but the network as a whole does and that is ultimately what matters. You can't really cut a country off from the global phone system just because they refuse to enforce your rules on telemarketing.
The thing with a term like "embedded systems" is that it spans a HUGE gamut of hardware doing a huge range of functions. Some of runs linux, some runs windows, some runs other propietry operating systems, some doesn't run an OS at all.
Windows seems to have carved quite a niche in systems that are neither power or latency critical. For example the user interface and data processing on your test gear (the actual capture is almost certainly handled by other processors). This use is a source of IT headaches since the vendors often don't like security updates or antivirus software but the vendors don't seem to care about that (most likely because IT aren't the ones buying the equipment).
The thing with windows XP professional x64 edition* is that it has a VERY small installed base and so many software and perhipheral vendors don't care about it. Most often the stuff works anyway with drivers intended for 64-bit vista/win7 but sometimes it doesn't (for example the NI mydaq doesn't work) and sometimes it sorta works (for example the DT9816 will work with the low level API but not with the high level API).
It was not until vista that MS really started trying to pressure vendors to support x64 (though their "designed for" logo program).
*BTW "XP 64-bit edition" was the version for the Itanium. and "XP professional x64 edition" is really 2K3 (NT 5.2) under the hood.
Traditionally a "TCP/IP stack" gave two main options for applications.
* an "unreliable", non congesion-controlled and non-connection based message based protocol with limited message sizes and no message aggregation (UDP) * a "reliable" congestion controlled, connection orientated stream based protocol (TCP) .
So the path of least resistance for most applications was to turn their messages into a stream so they could transmit arbitary sized messages and take advantage of the "reliable", connection orientated nature of TCP. This works tolerably but it less than ideal, for example if a packet is lost then it delays messages in subsequent packets as the processing to turn packets back into a stream must happen in-order.
SCTP provides a richer interface that avoids this deficiency. Sadly it came along too late to have much impact. Apps that couldn't tolerate TCP had already built custom soloutions on top of UDP
You also have to use registered memory, which costs more
While 4G registered ECC modules are more expensive than 4GB desktop (unregistered NON-ecc) modules the opposite is true for 8GB modules. 8GB desktop modules are arround $200 each while 8GB registered ECC modules are arround $100 each.
What is really annoying is that afaict NO LGA1155 processors (not even the xeons) support registered memory, and 8GB unregistered ECC modules seem virtually non-existent.
64GB is even more high end. At this point, no desktop component works (until the SB-E series comes out). You have to buy workstation/server class boards and Xeon processors. Right there you are talking a ton more money. You also have to use registered memory, which costs more. This is very much a high end only situation.
It really depends on what your priorities are. You can get a CPU+MB+64GB of ram for arround $1300 ($800 for memory, $250 for CPU, $250 for MB) by going socket G34 but you end up with a CPU that will be shitty at low thread count tasks.
Also with many projects you can reduce the number of parallel builds invoked by make saving ram at the cost of not being able to exploit as much parallelism.
But yeah in general laptop users get shafted on ram because they generally only get two ram slots and even when their platform supports 8GB modules they are frightfully expensive but then IMO if you are trying to do heavy computation on laptops you are probably doing it wrong.
16 GB of RAM is an awful lot of it, by today's standards.
Currently 16GB is the max you can put in a mainstream (but not bottom of the barrel) desktop with reasonablly priced modules and afaict it's been that way for a couple of years now. Desktops based on the high end LGA1366 socket support 24GB of reasonably priced modules.
Once you go byeond 24GB you currently have to either buy frightfully expensive 8GB unregistered modules or buy a server platform that supports registered modules and/or more ram slots.
TFA: "5+ hours of CPU time for a single build, 25+ minutes of wall time, as measured on a workstation (dual-E5620 i.e. 2x quad-core 2.4GHz HT, with 24GB of RAM, no SSD)." /. Summary: "It will take 5 hours to compile on a dual quad-core 2+GHz workstation"
Indeed though support for 16GB is nothing unusual these days, if your desktop was made in the last couple of years and wasn't bottom of the barrel it will probablly support 16GB.
I suspect it's still a lot cheaper to buy a 1 TB hard drive than a 1 TB SSD (or 1024 GB SSD I suppose)
Indeed
if they even exist.
Afaict currently the most you can get is 600GB* in a 2.5 inch bay (one 2.5 inch drive), 1.2 TB in a 3.5 inch bay (2 2.5 inch drives with a mounting adaptor) or 3.6TB in a 5.25 inch bay (6 2.5 inch drives in a mounting adaptor). A 1TB 2.5 inch SSD has been announced but doesn't seem to be on the market yet.
The thing is a large proportion number of users really don't need that much storage. Most buisness desktops and laptops are likely to have windows, office and one or two specialist buisness apps. In most cases (unless the specialist apps are very large) that will probablly fit on a 60GB SSD which isn't wildy expensive. Buisnesses often tend to discourage people from storing lots of stuff locally.
What I mean is that for things like the "pellet launcher" and "pellet target" rather than placing a single object you have to build it up out of many peices in the map editor.
That's fine, they will sell exactly ZERO of them until the price goes back to normal.
BS, those who actually need capacity NOW will still buy drives. So will those for whom the cost of hard drives is lost in the noise. The only people who will stop buying are those who either don't really need them right now or are really short on cash.
I haven't bought portal 2 yet but I remember for the original portal mapping was a MAJOR PITA not because of any problem with hammer itself but because many of the immovable items in the game (emmitters, targets etc) needed to be built up manually in the map rather than being items that could simply be placed.
The reason the floppy drive phaseout took so long is that it wasn't the CD alone that killed it. It was the USB flash drive that killed it. CDs are good, but they're a bit clumsy to work with compared to the floppy drive.
More specifically the vendors screwed up on packet writing. Had packet writing been made a standard feature of windows with a standard format I expect things would have turned out rather differently.
Slashdot Mirror
There are a large number of great USB to serial port adapters on the market
FTFY
Most USB to serial port adaptors have lower voltages than serial ports traditionally had and afaict ALL of them have much higher latencies than traditional serial ports. These issues will cause some equipment not to work. The first issue can be solved by building your own adaptor with custom level shift circuitry but there is really nothing you can do about the second issue.
Sure, PDFs are great for printing, but who prints anymore? It's 2011.
I do because when reading a long document I preffer to do it on paper than on screen ;)
get rid of PDFs entirely.
Going from printed to pdf was a relatively easy transition. Just install a printer driver or a plugin in your document preperation system and you are good to go. For big documents you probablly want to convert the TOC to bookmarks but even that isn't too big a deal (for latex users the hyperref package can do it and IIRC for word users the hyperref package can do it). Even paper documents could be converted to PDF if necessary though the results were often less than ideal. Storing stuff electronically represented a major convenience improvement and cost saving over a photocopy on request system (which afaict is how both academic papers and component datasheets were handled in the days before PDF).
Preparing reflowable documents on the other hand requires a totally different workflow than preparing sequences of pages. Making a workflow that does both well (because you still have to provide a printed/printable version) is even harder. Further even if all new documents were prepared to be reflowable (fat chance) that still doesn't provide a soloution for existing non-reflowable content.
Because when you are comparing parts it's so much easier to have the PDFs open in tabs of the same window as the search that found them than having to open them in a seperate app, look at them and then find the browser window you were using again. Especially if you are working on windows which doesn't have virtual desktops.
I just hope this new PDF system is actually fit for the purpose of looking at things like IC data sheets (which means it MUST support PDF bookmarks and it MUST NOT choke on large PDF files).
Is it really lying? is there a formal definition of the "hyperthreading bit"
In both cases you have two logical cores that share some computing resources, the only difference is in what computing resources are shared. From the point of view of an OS scheduler knowing exactly which computing resources are shared is FAR less important than knowing that resources are shared
If he is REALLY spending $8000 more on an intel server than an AMD one then either he is getting MASSIVELY ripped off, comparing servers that are radically different in other ways or comparing servers with more than 2 sockets.
When you can save 8000 per server
That sounds like extreme hyperbole to me. Care to show me a case where an Intel server costs that much more than an AMD one with equivalent computing power.
Note that register size and address size need not be the same. There were many processors out there with 16-bit memory addresses but only 8-bit registers and data bus. Likewise most 16-bit systems had some mechanism for accessing more than 2^16 memory addresses. Even 32-bit systems often had mechanisms for accessing more than 2^32 memory address though they were little used.
OTOH 64-bit CPUs often don't bother with support for full 64-bit addresses (though they are often designed so they can be allowed in future without changing userland code) because people simply don't have anywhere near that much memory.
I don't think there is much point increasing the size of integer data words beyond 64-bit. Most apps simply don't need numbers that big.
Sorrry I screwed up that last list slightly, it should be coal, natural gas, nuclear and hydro (in that order)
http://upload.wikimedia.org/wikipedia/commons/5/54/LLNL_US_Energy_Flow_2009.png
Notice how amount of oil used to make electricity is NEGLIGIBLE compared to either the total amount of energy used to make electricity or the total amount of oil used. Electricity comes mostly from natural gas, coal, nuclear and hydro (in that order).
XP comes in a 64 bit flavor as well,
Well it was marketed as XP but really under the hood it's 2K3.
although it never was supported very well by other vendors
The big vendors of core hardware like intel, NVIDIA etc support it just fine. Support from vendors of less core hardware is patchy (few officially support it but in practice the drivers for vista and win7 usually work).
XP wasn't written for 6 or more CPUs/cores
XP was derived from 2K which was written to support far more than that.
Originally, vanilla 2K only was "licensed" for two CPUs
Depends which edition you bought. Pro was 2, server was 4, advanced server was 8 and datacenter server was 32. Afaict win2K didn't understand hyperthreading or multicore though so every logical processor counted against the limit of your edition.
Individual end user lines may not usually cross borders but the network as a whole does and that is ultimately what matters. You can't really cut a country off from the global phone system just because they refuse to enforce your rules on telemarketing.
The thing with a term like "embedded systems" is that it spans a HUGE gamut of hardware doing a huge range of functions. Some of runs linux, some runs windows, some runs other propietry operating systems, some doesn't run an OS at all.
Windows seems to have carved quite a niche in systems that are neither power or latency critical. For example the user interface and data processing on your test gear (the actual capture is almost certainly handled by other processors). This use is a source of IT headaches since the vendors often don't like security updates or antivirus software but the vendors don't seem to care about that (most likely because IT aren't the ones buying the equipment).
The thing with windows XP professional x64 edition* is that it has a VERY small installed base and so many software and perhipheral vendors don't care about it. Most often the stuff works anyway with drivers intended for 64-bit vista/win7 but sometimes it doesn't (for example the NI mydaq doesn't work) and sometimes it sorta works (for example the DT9816 will work with the low level API but not with the high level API).
It was not until vista that MS really started trying to pressure vendors to support x64 (though their "designed for" logo program).
*BTW "XP 64-bit edition" was the version for the Itanium. and "XP professional x64 edition" is really 2K3 (NT 5.2) under the hood.
Traditionally a "TCP/IP stack" gave two main options for applications.
* an "unreliable", non congesion-controlled and non-connection based message based protocol with limited message sizes and no message aggregation (UDP)
* a "reliable" congestion controlled, connection orientated stream based protocol (TCP) .
So the path of least resistance for most applications was to turn their messages into a stream so they could transmit arbitary sized messages and take advantage of the "reliable", connection orientated nature of TCP. This works tolerably but it less than ideal, for example if a packet is lost then it delays messages in subsequent packets as the processing to turn packets back into a stream must happen in-order.
SCTP provides a richer interface that avoids this deficiency. Sadly it came along too late to have much impact. Apps that couldn't tolerate TCP had already built custom soloutions on top of UDP
You also have to use registered memory, which costs more
While 4G registered ECC modules are more expensive than 4GB desktop (unregistered NON-ecc) modules the opposite is true for 8GB modules. 8GB desktop modules are arround $200 each while 8GB registered ECC modules are arround $100 each.
What is really annoying is that afaict NO LGA1155 processors (not even the xeons) support registered memory, and 8GB unregistered ECC modules seem virtually non-existent.
64GB is even more high end. At this point, no desktop component works (until the SB-E series comes out). You have to buy workstation/server class boards and Xeon processors. Right there you are talking a ton more money. You also have to use registered memory, which costs more. This is very much a high end only situation.
It really depends on what your priorities are. You can get a CPU+MB+64GB of ram for arround $1300 ($800 for memory, $250 for CPU, $250 for MB) by going socket G34 but you end up with a CPU that will be shitty at low thread count tasks.
Also with many projects you can reduce the number of parallel builds invoked by make saving ram at the cost of not being able to exploit as much parallelism.
Intel's most advanced and expensive laptop processors, on sale currently and in the foreseeable near future, only support 8 GB of RAM.
Some are listed as supporting 16GB or 32GB. for example http://ark.intel.com/products/50067, http://ark.intel.com/products/52224
But yeah in general laptop users get shafted on ram because they generally only get two ram slots and even when their platform supports 8GB modules they are frightfully expensive but then IMO if you are trying to do heavy computation on laptops you are probably doing it wrong.
16 GB of RAM is an awful lot of it, by today's standards.
Currently 16GB is the max you can put in a mainstream (but not bottom of the barrel) desktop with reasonablly priced modules and afaict it's been that way for a couple of years now. Desktops based on the high end LGA1366 socket support 24GB of reasonably priced modules.
Once you go byeond 24GB you currently have to either buy frightfully expensive 8GB unregistered modules or buy a server platform that supports registered modules and/or more ram slots.
Yeah laptops are a pain if you want/need lots of ram. Some can handle 2x8GB but 8GB laptop modules are bloody expensive.
TFA: "5+ hours of CPU time for a single build, 25+ minutes of wall time, as measured on a workstation (dual-E5620 i.e. 2x quad-core 2.4GHz HT, with 24GB of RAM, no SSD)."
/. Summary: "It will take 5 hours to compile on a dual quad-core 2+GHz workstation"
and a computer that can take 16 gigs of RAM.
Indeed though support for 16GB is nothing unusual these days, if your desktop was made in the last couple of years and wasn't bottom of the barrel it will probablly support 16GB.
I suspect it's still a lot cheaper to buy a 1 TB hard drive than a 1 TB SSD (or 1024 GB SSD I suppose)
Indeed
if they even exist.
Afaict currently the most you can get is 600GB* in a 2.5 inch bay (one 2.5 inch drive), 1.2 TB in a 3.5 inch bay (2 2.5 inch drives with a mounting adaptor) or 3.6TB in a 5.25 inch bay (6 2.5 inch drives in a mounting adaptor). A 1TB 2.5 inch SSD has been announced but doesn't seem to be on the market yet.
The thing is a large proportion number of users really don't need that much storage. Most buisness desktops and laptops are likely to have windows, office and one or two specialist buisness apps. In most cases (unless the specialist apps are very large) that will probablly fit on a 60GB SSD which isn't wildy expensive. Buisnesses often tend to discourage people from storing lots of stuff locally.
What I mean is that for things like the "pellet launcher" and "pellet target" rather than placing a single object you have to build it up out of many peices in the map editor.
http://developer.valvesoftware.com/wiki/Creating_an_energy_ball_launcher_and_catcher
9 steps to built a launcher and 25 steps to build a target!
That's fine, they will sell exactly ZERO of them until the price goes back to normal.
BS, those who actually need capacity NOW will still buy drives. So will those for whom the cost of hard drives is lost in the noise. The only people who will stop buying are those who either don't really need them right now or are really short on cash.
I haven't bought portal 2 yet but I remember for the original portal mapping was a MAJOR PITA not because of any problem with hammer itself but because many of the immovable items in the game (emmitters, targets etc) needed to be built up manually in the map rather than being items that could simply be placed.
The reason the floppy drive phaseout took so long is that it wasn't the CD alone that killed it. It was the USB flash drive that killed it. CDs are good, but they're a bit clumsy to work with compared to the floppy drive.
More specifically the vendors screwed up on packet writing. Had packet writing been made a standard feature of windows with a standard format I expect things would have turned out rather differently.