AMD engineers have also been submitting code to allow CoreBoot to run on the company's latest chipsets, such as the RS690 and 780G."
Now that would freakin' rock!!!
Until now, CoreBoot has been really hampered by the fact that it has mostly been supported on server boards, with little to know support on Desktop and Laptop chipsets. This is mostly the fault of the chipset/mobo manufacturers, who have zealously guarded their legacy BIOS crap for reasons that are pretty unfathomable to me.
I would love to be able to run CoreBoot on my Desktop and laptops. It would help to fix soooo many of the legacy BIOS issues that people tear their hair out over: booting USB devices, suspend/resume support, wake-on-LAN support, network booting.
So, go AMD. I've been a loyal fanb^H^H^H^H, uh, customer for years and I'm really glad to see them moving in the direction of open-sourcing their video drivers and now releasing chipset docs. Excellent news.
But in the short term, it's gratifying to be around DC, to look at the government buildings, to go to the website, and know that George Bush ain't in charge anymore. Not that much has changed substantively, of course...:-P
I mean, all of those Apple fans bought into a computing ecosystem that is under the complete and total control of one (1) vendor. Don't like the direction their hardware is going? Well, you're SOL, cause you can't use their software without their hardware.
This is why I laugh whenever people tell me Mac OS X is as good as Linux. Linux isn't just good because it's Unix-like. It's good because it's completely free and open and can run on everything from a Cray to your grandma's toaster.
"and to expand from simple scripts to complex systems"
Now, something here isn't quite right. They allow your simple scripts to expand into a huge unmaintanable mess.
I don't agree in general... I think this is very language-dependent and human-dependent. My Perl codebases got completely unmaintainable as they grew, but with Python I haven't had any problems scaling to thousands of lines of code. Partly I think I've gotten to be a more disciplined programmer, partly I think Python's a better language for scalability.
So, 3 out of 4. That is why they are usefull, and why they aren't a silver bullet.
Well I'd say 4 out of 4, but I agree they aren't a silver bullet:-)
Memory and CPU overhead, and difficulty of distributing complex programs and modules in a standardized way... those are the issues I have with dynamic languages.
From the co-optation of successful ideas across languages, to the infusion of application development into applications that are fast evolving beyond their traditional purpose, to the rise of frameworks, the cloud, and amateur code enablers,...
Honestly, for anyone who actually uses them to solve problems, the benefits of dynamic languages aren't hard to understand: they allow you to code easily and clearly, to debug quickly, and to expand from simple scripts to complex systems. And they're surrounded by supportive developer communities and code libraries.
Just like all the other great geek innovations... we don't need marketing types to notice in order to enjoy our toys:-)
Now that's a ridiculous comparison between Perl 6 and Python 3.0.
Python 3.0 has gone from "a bunch of proposals" to an actual, feature-complete beta in recent months. And most reasonable observers actually believe that there will be a final, shiny 3.0 release this month. Moreover, Python 2.6-final is out and it has most of the 3.0 features backported to it, including the backwards-incompatible ones (optionally turned on and off).
Perl 6 seems to have languished somewhere between "idea" and "implementation" from around 2000 to 2005. Now it turns out that (SURPRISE!), "there's more than one way to do it" with Perl 6. There's a Haskell-based implementation and a Parrot-based implementation, and a few others that aren't as mature too, it seems. I've had a very hard time assessing how mature these are and how much continuity they will find in the final release... since they aren't developed by a core group of developers with a track record.
Python 3.0 is credibly just around the corner, coming from the same core team that brought us all the previous releases. Perl 6 is still stuck in the vague surreal mess of possibility and intrigue that makes Perl simultaneously so much fun and so frustrating.
1. I already know it. I learned it before Ruby was "cool".
The biggest problem with this argument is... Python is incredibly easy for a Perl programmer to learn. I mean, ridiculously so. All the reasonable Perlisms (hashes, lists, foreach, etc.) translate directly, and all the unreasonable ones (*cough* objects *cough*) are just simpler in Python.
I decided to learn Python one day and had basically rewritten (and improved) all of my lab automation scripts in it about 10-20 hours of work later.
2. It's already installed on every Linux and BSD machine. Yes, that means I can run my script on your brand new Ubuntu desktop, or your 1998 BSD server. And it'll work.
Erm... Python has been installed on every Linux/BSD box I've seen in the last 5 years, because a lot of system utilities depend on it. Perl has changed a lot since 1998 too... I wouldn't count on a lot of today's scripts working with Perl 5.1.
3. Great Regex support (am not saying your language de-jour doesn't, just that perl does)
Indeed. When you need regexes, Perl's are undoubtedly the best. Which is why Python copies Perl's regex syntax exactly... including all the new-fangled ?: ?! ?^ stuff. Just learn the Python functions to invoke regexes, and you're done.
4. CPAN is one of the most extensive software libraries known to mankind.
Unfortunately, it's also wildly varying in quality, and there are sometimes 5-10 different modules that sorta-kinda do the same thing and none of them gets everything right. And they might be coded in such different styles as to be nearly impossible to combine.
... all of you Haters out there can go $@_{s/;//g}!
See, the fact that that might be a valid Perl program is part of why I prefer Python:-P
Amen to that. I jumped ship from Perl 5 to Python about 1.5 years ago, and haven't looked back.
There really isn't a lot of difference between the two languages in terms of what they can actually *DO*, it's just that Python does it more easily, more consistently, more readably, and with a broader and more coherent standard library. I'm a lot more productive in Python, and there is nothing it lacks. (Number crunching? Check! Perldl->Numpy. Date manipulation? Check!)
Let me put it this way: If Larry Wall took a time machine back to 2002, and presented Python 2.6 as the brand new Perl 6, everyone would hail it as a brilliant but not excessive redesign, and he would be richly congratulated for the (ahem) brisk development schedule.
Mod parent up. Thanks for the voice of reason in here.
You'll need one of the even fewer DVD Audio albums that isn't up-sampled and re-mixed from a 44.1 KHz 16 bit master, and therefore actually has some chance of containing real extra musical information that isn't on the CD version to make such a comparison valid, otherwise any perceivable differences will be nothing more than artefacts of the up-sampling and re-mastering process.
Just for those who don't know: what the parent is referring to is the ongoing Loudness War, in which nearly all popular music is produced at higher and higher loudness levels, severely reducing the dynamic range to well below what the CD format is capable of. (Louder music sounds better "at first glance", so there's a lot of commercial pressure to do this.)
Some DVD-A and SACD albums are remastered without this execrable dynamic range compression... and sound better as a result. But it would sound just as good in CD or MP3 format if record companies would stop butchering them.
However, there comes a point where it becomes ABSOLUTELY ridiculous. I am very keen on my sounds, and have some high end equipment in my living room.
As you said, to get the best out of it, you NEED high end throughout, no point having a "weakest link". So the source should be good quality well recorded CD/SACD/DVD-Audio/Other LossLess format. No point using a "high end" system with low quality MP3s.
Where the source is digital, ideally keep the signal digital, and unprocessed to the receiver, via TOSlink/SPDIF/HDMI(BluRay), and use the same transmission as the source, so if the source is CD, ensure the transmission is 44.1khz, 16bit,stereo. I have seen so called "Gold Plated TOSlink Optical cables" begin sold for a huge premium. This is ridiculous, as the gold plating has absolutely no effect on an optical cable. Instead, you want to know the quality of the glass used. Again, this is somethign that makes more of a issue with distance. For a 1m Cable, the absolute top quality may be overkill, as signal degradation will be lower than the tolerances of the error correction system. Again the key here is that Digital degrades differently to analogue, and may be up to a point far more forgiving.
How the hell did the parent get modded "Informative". It's standard audiophile drivel with a tiny hint of awareness of the ridiculousness of the phenomenon...
Let's start with the complete bullshit notion that the composition of digital cables can in any way affect their performance. If a digital signal gets through a $5 Walmart cable, it's as good as a signal that goes through a $5,000 audiophile cable. Period. End of story. Analog degradation of a digital signal makes absolutely no difference as long as the signal is recovered at the other end.
For analogue (and electrical based digital cabling), you need impedance matched "OxygenFree" cabling, where the connectors are electrically/chemically and mechanically matched. No point using a Cable with Gold Plated connectors, if the sockets on the source, or receiver is normal steel (this is a BAD thing, to mix gold plated and non gold plated, especially silver).
The same thing applies to speaker wires/connectors, make sure they are matched to the speakers, and the source.
Oh, goody. Now we move onto the bullshit about analog cables and how audiophiles think they can hear tiny anomalies in the conductance of wires that can hardly be detected by sensitive lab instruments.
If I ever find myself out of work, and lose all self-respect and sell my soul, I know I'll be able to make a living inventing bullshit audiophile products and peddling them with a straight face. Like a rock that sits on top of your CD player and adds "sonic purity" to its output. Oh wait, that one already exists.
I don't want a memory stick containing lossy 320kbit songs, I can get that easily enough off the CD (they are still giving you a real CD, right?).
Why not include a 24-bit 192 or 96 khz lossless format, and maybe something in 5.1 instead? DVD-Audio and SACD didn't take off because no one adopted the players, but it might take off if you made it easily playable. I might even pay a slight premium.
Can you actually tell the difference between "lossy 320kbit" audio and lossless audio?
I highly doubt it. Most people can't tell the difference between 128kbps MP3 and lossless. Of course, of course, you're not "most people". You have nice speakers and a very good ear. Unfortunately, there's no evidence that I've seen that *anyone* can systematically distinguish anything better than 192kbps MP3 from the lossless "real thing" even under optimal listening conditions.
As far as I can tell, SACD and DVD-A never took off because (a) they're expensive, (b) they're loaded down with DRM suckage, and (c) no one can hear the difference.
The funny thing is that for some 20 years, before I started using Python, my favorite and almost only language was C, and I don't know of any really good site for C.
I agree. C and Python are, in my opinion, the only languages that integrate *really well* with general UNIX design philosophy. They're both incredibly simple and powerful, in their own ways.
Before Python, I was a Perl guy... but I left Perl a year ago and haven't looked back.
Now I'm getting good at writing Python extension modules in C (what fun). The API is really nice and almost trivial to use from a C programmer's perspective. It's not unlike the GTK APIs, but focuses a litttle less on consistency and a little more on practical usability.
However, I do know of a really good author, that is a "dead tree" author, for C: Herbert Schildt. I would recommend these. Any of them. Well, just kidding, I haven't read them all, I doubt anyone has, but I bet they are all good.
I like his books too, and you have a good point. There are plenty of references for C functions (standard library, man pages, system calls) and plenty of excellent open source example code, but there aren't really any good online resources that teach or demonstrate the idioms of C programming in a step-by-step fashion. I guess that sort of goes hand-in-hand with the roll-your-own attitude that some C programmers have.:-/
They may just like sun on their backs and not in their eyes.
That was my thought too... if cows prefer sun on their backs and not in their eyes, the vast majority of them will point north. Because there have got to be waaay more cows in the Northern Hemipshere.
Why? Because there is much more land in the Northern Hemisphere (about 2.5 times as much... even more excluding Antartica), and much more human population in the Northern Hemisphere (about 8 times as much), so it stands to reason that there are gonna be a lot more cows too.
Now I'm sure that no Slashdot reader will intentionally watch any "sport" that has judges determine the winner, but their wives/girlfriends might seize control of the remote because they want to know who is the best at that ribbon twirling thing.
I don't **HAVE** a wife or girlfriend, you insensitive clods!!!
Gosh, why does Slashdot always have to rub it in my face.
Intel isn't playing the "do as we tell you or we're going home and taking our ball with us" game. What they're doing is looking out for the consumer. Why would the consumer want a fully-functional PC running a slow, innefficient processor like the Atom? Why would an atom-based computer need more than 1 memory dimm, digital video (have you seen Intel's graphics chipsets, they really aren't the greatest), and PCI-express?
Exactly right. This review is almost useless to anyone trying to design a complete system around these processors, since it can't identify which specific components are responsible for the greatest share of the power consumption. Quite disappointing.
According to wikipedia, the hyperthreading Atom Diamondville (at 1.6-2.2 GHz) has a TDP of 4W. Which suggests that its low-power mode is very efficient--if TFA is correct--given that they only saw a 4W increase in power consumption under load.
IMHO, it is a mistake to think that the Nano and the Atom are really fighting for the exact same market. This seems to be based on the fact that they are both available on Mini-ITX boards. It seems to me that Atom is an extremely stripped-down processor designed for extremely low-power use... while the Nano is actually more "beefed-up" than previous Via processors like the C7... featuring more complex execution units and the full 64-bit instruction set.
Right. I get the inspirational quality of putting real live humans on the moon.
But I don't think it is worth it. It is *really* expensive. If it were a billion or two, I'd say, "Go for it." But we're talking tens or hundreds of billions of dollars. Enough to educate thousands of engineers and scientists, or vastly improve health care in our country, or fund aggressive energy research... or even fight a few more months in Iraq.
Some say that the Apollo Program spurred on significant advances in science and technology in the USA. But I think they get it backwards. The Apollo Program was actually more of a *byproduct* of a renewed focus on science and engineering in the face of intense Soviet competition. And not a bad byproduct at that.
I guess I would like to see the US get serious about technical prestige and education FIRST, and only CONSIDER going back to the moon AFTER we've regained our prowess in science and engineering.
Why do want to go to the moon? Because the Chinese are going?
Let's see... why did we want to go last time? Oh, because the Russians were going. Aha.
Putting a man on the moon may be inspiring and make for great geopolitical drama, and it's fun to touch the moon rock at the Air and Space Museum... but it's otherwise an utterly worthless dick-swinging contest.
It's extremely expensive to get there, and the fact that we still have no idea what to do with it (as evidenced by this very article!!) suggests it ain't worth it. Until there's some compelling economic or scientific reason for a moon visit, I believe it's simply a boondoggle for the things-we-can-do-by-wasting-enough-fossil-fuel industry.
Mostly little 8-bitters (PIC and AVR),... If you consider PIC to be RISC, then you, sir, are quite the masochist.:-)
PIC may have a "reduced" instruction set, but it violates nearly every other principal of RISC design: its instruction set is hopelessly non-orthogonal, it is severely lacking in general-purpose registers (ONE), and its addressing modes are extremely crude, requiring bank switching and making position-independent code essentially impossible.
AVR on the other hand is great. It has a fully orthogonal instruction set, 32 general purpose registers, and sane addressing modes.
I don't know why chooses PIC over AVR. Because AVR is RISC, it has *much* better compiler support, including a full GCC port. The only thing I can think of is that, in my experience, Microchip is very generous with free samples of PIC's, while Atmel is very stingy... that's why I ended up using PICs for several student projects, to save myself a few bucks 8-)
... but there are many processors that tend towards the RISC end of the spectrum (ARM, MIPS etc) which clearly have RISC roots. ARM, MIPS etc dominate in mobile space because they switch less transistors to achieve the same function (one of the goals of RISC design) and thus use less power. One reason x86 is encroaching on the mobile space is because the extra transistors required for the complex instruction set are becoming less and less important. It used to be, when you only had 100k transistors to implement your embedded processor, it was a serious drag to use 20k of them for complex microcoded instructions... but now that embedded processors can contain millions of transistors, it's hardly a blip.
Not that I don't think RISC is better for other reasons, I just think that it is losing this particular battle...
The only real point in x86 is Windows compatability. Linux runs fine on ARM and many other architectures. There are probably more ARM Linux systems than x86-based Linux systems (all those Linux cellphones run ARM).
Apart from some very low level stuff, modern code tends to be very CPU agnostic.
Absolutely, Linux runs great on ARM (lots of PDAs) and on MIPS (my hacked Netgear router).
I agree that x86 is only useful for Windows compatibility... witness how quickly Linux software got recompiled for x86-64 (I was running it in 2005 and was by no means an early adopter) while most Windows software is still wheezing along in the 32-bit world. Open-source pretty much removes all the inertia in instruction set choice.
I recently read an interesting book, Guide to RISC Processors by Dandamundi, which compares several RISC families. As I see it, MIPS is essentially RISC the way God intended it to be. It's the most beautifully clean and orthogonal instruction set. Any instruction that could be split into smaller parts has been.
By comparison, SPARC and PowerPC are a little less RISC-y than MIPS, and Itanium strays quite far. ARM is a very clever architecture, in that it offers very high code density through interesting addressing modes, barrel shifting, and condition codes... it maps VERY WELL onto C code.
Frankly, I think we should all just run MIPS. It's such a simple and yet efficient architecture. You can easily implement the core in Verilog. It is easy for compilers to optimize generated code. Quite brilliant. If I could buy myself an ATX motherboard with a fast MIPS processor on it, I'd chuck my x86-64 in no time...
Bravo! Finally, someone who actually intends to help the customer do what they want, rather than tell them they're too stupid to do it...
I know we're all IT people here, we run our own RDBMS, rebuild our kernels, etc. etc. but...
Imagine for a second that you're not the OP's client. Wow, it's going to be awfully frustrating when the company you've hired for database support says, "We won't let you do what you want with the database, because we think you're too stupid."
Even *if* that is true, flat-out rejecting it is going to lose you business fast. Better to build an auxiliary database that they can use for their own queries, or otherwise come up with a real live compromise solution... just as tjstork suggested.
Agreed. I should have said that giga=1000^3, not 1024^3. There are binary prefixes (kibi, mebi, gibi, tebi, etc.) for the latter case.
AFAIK, it's been standard practice for hard drive makers to report capacity in decimal units for years... but operating systems seem to be wildly inconsistent about what they do:-(
Slashdot Mirror
AMD engineers have also been submitting code to allow CoreBoot to run on the company's latest chipsets, such as the RS690 and 780G."
Now that would freakin' rock!!!
Until now, CoreBoot has been really hampered by the fact that it has mostly been supported on server boards, with little to know support on Desktop and Laptop chipsets. This is mostly the fault of the chipset/mobo manufacturers, who have zealously guarded their legacy BIOS crap for reasons that are pretty unfathomable to me.
I would love to be able to run CoreBoot on my Desktop and laptops. It would help to fix soooo many of the legacy BIOS issues that people tear their hair out over: booting USB devices, suspend/resume support, wake-on-LAN support, network booting.
So, go AMD. I've been a loyal fanb^H^H^H^H, uh, customer for years and I'm really glad to see them moving in the direction of open-sourcing their video drivers and now releasing chipset docs. Excellent news.
Very much indeed.
But in the short term, it's gratifying to be around DC, to look at the government buildings, to go to the website, and know that George Bush ain't in charge anymore. Not that much has changed substantively, of course... :-P
... when Barack Obama was inaugurated as US president last week, all traces of George W. Bush disappeared from the White House website.
Ah, hmm... we're in danger of forgetting George W. Bush?
I can't quite figure out the downside.
As a Jew with somewhat Humanistic leanings, who is a devoted user of C and Python...
spot on the mark :-P
Great work, Aram! I can't believe you managed to get your name on slashdot. I seethe with jealousy.
Heck, I'd settle for having a decent paper to put on arXiv!
-Dan Lenski
Gosh, I never coulda seen this coming!!!
I mean, all of those Apple fans bought into a computing ecosystem that is under the complete and total control of one (1) vendor. Don't like the direction their hardware is going? Well, you're SOL, cause you can't use their software without their hardware.
This is why I laugh whenever people tell me Mac OS X is as good as Linux. Linux isn't just good because it's Unix-like. It's good because it's completely free and open and can run on everything from a Cray to your grandma's toaster.
Now, something here isn't quite right. They allow your simple scripts to expand into a huge unmaintanable mess.
I don't agree in general... I think this is very language-dependent and human-dependent. My Perl codebases got completely unmaintainable as they grew, but with Python I haven't had any problems scaling to thousands of lines of code. Partly I think I've gotten to be a more disciplined programmer, partly I think Python's a better language for scalability.
So, 3 out of 4. That is why they are usefull, and why they aren't a silver bullet.
Well I'd say 4 out of 4, but I agree they aren't a silver bullet :-)
Memory and CPU overhead, and difficulty of distributing complex programs and modules in a standardized way... those are the issues I have with dynamic languages.
From the co-optation of successful ideas across languages, to the infusion of application development into applications that are fast evolving beyond their traditional purpose, to the rise of frameworks, the cloud, and amateur code enablers, ...
Honestly, for anyone who actually uses them to solve problems, the benefits of dynamic languages aren't hard to understand: they allow you to code easily and clearly, to debug quickly, and to expand from simple scripts to complex systems. And they're surrounded by supportive developer communities and code libraries.
Just like all the other great geek innovations... we don't need marketing types to notice in order to enjoy our toys :-)
Now that's a ridiculous comparison between Perl 6 and Python 3.0.
Python 3.0 has gone from "a bunch of proposals" to an actual, feature-complete beta in recent months. And most reasonable observers actually believe that there will be a final, shiny 3.0 release this month. Moreover, Python 2.6-final is out and it has most of the 3.0 features backported to it, including the backwards-incompatible ones (optionally turned on and off).
Perl 6 seems to have languished somewhere between "idea" and "implementation" from around 2000 to 2005. Now it turns out that (SURPRISE!), "there's more than one way to do it" with Perl 6. There's a Haskell-based implementation and a Parrot-based implementation, and a few others that aren't as mature too, it seems. I've had a very hard time assessing how mature these are and how much continuity they will find in the final release... since they aren't developed by a core group of developers with a track record.
Python 3.0 is credibly just around the corner, coming from the same core team that brought us all the previous releases. Perl 6 is still stuck in the vague surreal mess of possibility and intrigue that makes Perl simultaneously so much fun and so frustrating.
1. I already know it. I learned it before Ruby was "cool".
The biggest problem with this argument is... Python is incredibly easy for a Perl programmer to learn. I mean, ridiculously so. All the reasonable Perlisms (hashes, lists, foreach, etc.) translate directly, and all the unreasonable ones (*cough* objects *cough*) are just simpler in Python.
I decided to learn Python one day and had basically rewritten (and improved) all of my lab automation scripts in it about 10-20 hours of work later.
2. It's already installed on every Linux and BSD machine. Yes, that means I can run my script on your brand new Ubuntu desktop, or your 1998 BSD server. And it'll work.
Erm... Python has been installed on every Linux/BSD box I've seen in the last 5 years, because a lot of system utilities depend on it. Perl has changed a lot since 1998 too... I wouldn't count on a lot of today's scripts working with Perl 5.1.
3. Great Regex support (am not saying your language de-jour doesn't, just that perl does)
Indeed. When you need regexes, Perl's are undoubtedly the best. Which is why Python copies Perl's regex syntax exactly... including all the new-fangled ?: ?! ?^ stuff. Just learn the Python functions to invoke regexes, and you're done.
4. CPAN is one of the most extensive software libraries known to mankind.
Unfortunately, it's also wildly varying in quality, and there are sometimes 5-10 different modules that sorta-kinda do the same thing and none of them gets everything right. And they might be coded in such different styles as to be nearly impossible to combine.
... all of you Haters out there can go $@_{s/;//g}!
See, the fact that that might be a valid Perl program is part of why I prefer Python :-P
Amen to that. I jumped ship from Perl 5 to Python about 1.5 years ago, and haven't looked back.
There really isn't a lot of difference between the two languages in terms of what they can actually *DO*, it's just that Python does it more easily, more consistently, more readably, and with a broader and more coherent standard library. I'm a lot more productive in Python, and there is nothing it lacks. (Number crunching? Check! Perldl->Numpy. Date manipulation? Check!)
Let me put it this way: If Larry Wall took a time machine back to 2002, and presented Python 2.6 as the brand new Perl 6, everyone would hail it as a brilliant but not excessive redesign, and he would be richly congratulated for the (ahem) brisk development schedule.
Mod parent up. Thanks for the voice of reason in here.
You'll need one of the even fewer DVD Audio albums that isn't up-sampled and re-mixed from a 44.1 KHz 16 bit master, and therefore actually has some chance of containing real extra musical information that isn't on the CD version to make such a comparison valid, otherwise any perceivable differences will be nothing more than artefacts of the up-sampling and re-mastering process.
Just for those who don't know: what the parent is referring to is the ongoing Loudness War, in which nearly all popular music is produced at higher and higher loudness levels, severely reducing the dynamic range to well below what the CD format is capable of. (Louder music sounds better "at first glance", so there's a lot of commercial pressure to do this.)
Some DVD-A and SACD albums are remastered without this execrable dynamic range compression... and sound better as a result. But it would sound just as good in CD or MP3 format if record companies would stop butchering them.
However, there comes a point where it becomes ABSOLUTELY ridiculous. I am very keen on my sounds, and have some high end equipment in my living room.
As you said, to get the best out of it, you NEED high end throughout, no point having a "weakest link". So the source should be good quality well recorded CD/SACD/DVD-Audio/Other LossLess format. No point using a "high end" system with low quality MP3s.
Where the source is digital, ideally keep the signal digital, and unprocessed to the receiver, via TOSlink/SPDIF/HDMI(BluRay), and use the same transmission as the source, so if the source is CD, ensure the transmission is 44.1khz, 16bit,stereo. I have seen so called "Gold Plated TOSlink Optical cables" begin sold for a huge premium. This is ridiculous, as the gold plating has absolutely no effect on an optical cable. Instead, you want to know the quality of the glass used. Again, this is somethign that makes more of a issue with distance. For a 1m Cable, the absolute top quality may be overkill, as signal degradation will be lower than the tolerances of the error correction system. Again the key here is that Digital degrades differently to analogue, and may be up to a point far more forgiving.
How the hell did the parent get modded "Informative". It's standard audiophile drivel with a tiny hint of awareness of the ridiculousness of the phenomenon...
Let's start with the complete bullshit notion that the composition of digital cables can in any way affect their performance. If a digital signal gets through a $5 Walmart cable, it's as good as a signal that goes through a $5,000 audiophile cable. Period. End of story. Analog degradation of a digital signal makes absolutely no difference as long as the signal is recovered at the other end.
For analogue (and electrical based digital cabling), you need impedance matched "OxygenFree" cabling, where the connectors are electrically/chemically and mechanically matched. No point using a Cable with Gold Plated connectors, if the sockets on the source, or receiver is normal steel (this is a BAD thing, to mix gold plated and non gold plated, especially silver).
The same thing applies to speaker wires/connectors, make sure they are matched to the speakers, and the source.
Oh, goody. Now we move onto the bullshit about analog cables and how audiophiles think they can hear tiny anomalies in the conductance of wires that can hardly be detected by sensitive lab instruments.
Being an audiophile is all about self-delusion and elitism as far as I can tell. There is not a shred of evidence that they can actually tell the difference in carefully controlled double blind listening tests (which tend to really piss them off). This NYT article about high-end speaker wire is pretty funny: http://query.nytimes.com/gst/fullpage.html?res=9D06E1D61739F930A15751C1A96F958260&sec=&spon=&pagewanted=all.
If I ever find myself out of work, and lose all self-respect and sell my soul, I know I'll be able to make a living inventing bullshit audiophile products and peddling them with a straight face. Like a rock that sits on top of your CD player and adds "sonic purity" to its output. Oh wait, that one already exists.
For a good refutation of "subjectivist audiophile" BS by a respected audio engineer, read this: http://www.dself.dsl.pipex.com/ampins/pseudo/subjectv.htm (WARNING: Contains actual testable scientific arguments.)
I don't want a memory stick containing lossy 320kbit songs, I can get that easily enough off the CD (they are still giving you a real CD, right?).
Why not include a 24-bit 192 or 96 khz lossless format, and maybe something in 5.1 instead? DVD-Audio and SACD didn't take off because no one adopted the players, but it might take off if you made it easily playable. I might even pay a slight premium.
Can you actually tell the difference between "lossy 320kbit" audio and lossless audio?
I highly doubt it. Most people can't tell the difference between 128kbps MP3 and lossless. Of course, of course, you're not "most people". You have nice speakers and a very good ear. Unfortunately, there's no evidence that I've seen that *anyone* can systematically distinguish anything better than 192kbps MP3 from the lossless "real thing" even under optimal listening conditions.
As far as I can tell, SACD and DVD-A never took off because (a) they're expensive, (b) they're loaded down with DRM suckage, and (c) no one can hear the difference.
lives in suburbs - check
Suburbs? That will come as news to anyone who has been to Hyde Park...
The funny thing is that for some 20 years, before I started using Python, my favorite and almost only language was C, and I don't know of any really good site for C.
I agree. C and Python are, in my opinion, the only languages that integrate *really well* with general UNIX design philosophy. They're both incredibly simple and powerful, in their own ways.
Before Python, I was a Perl guy... but I left Perl a year ago and haven't looked back.
Now I'm getting good at writing Python extension modules in C (what fun). The API is really nice and almost trivial to use from a C programmer's perspective. It's not unlike the GTK APIs, but focuses a litttle less on consistency and a little more on practical usability.
However, I do know of a really good author, that is a "dead tree" author, for C: Herbert Schildt. I would recommend these. Any of them. Well, just kidding, I haven't read them all, I doubt anyone has, but I bet they are all good.
I like his books too, and you have a good point. There are plenty of references for C functions (standard library, man pages, system calls) and plenty of excellent open source example code, but there aren't really any good online resources that teach or demonstrate the idioms of C programming in a step-by-step fashion. I guess that sort of goes hand-in-hand with the roll-your-own attitude that some C programmers have. :-/
Someone prove me wrong, please?
That was my thought too... if cows prefer sun on their backs and not in their eyes, the vast majority of them will point north. Because there have got to be waaay more cows in the Northern Hemipshere.
Why? Because there is much more land in the Northern Hemisphere (about 2.5 times as much... even more excluding Antartica), and much more human population in the Northern Hemisphere (about 8 times as much), so it stands to reason that there are gonna be a lot more cows too.
I don't **HAVE** a wife or girlfriend, you insensitive clods!!!
Gosh, why does Slashdot always have to rub it in my face.
Puh-lease.
Intel isn't playing the "do as we tell you or we're going home and taking our ball with us" game. What they're doing is looking out for the consumer. Why would the consumer want a fully-functional PC running a slow, innefficient processor like the Atom? Why would an atom-based computer need more than 1 memory dimm, digital video (have you seen Intel's graphics chipsets, they really aren't the greatest), and PCI-express?
"Why would anyone need more than 640k of RAM??"
Exactly right. This review is almost useless to anyone trying to design a complete system around these processors, since it can't identify which specific components are responsible for the greatest share of the power consumption. Quite disappointing.
According to wikipedia, the hyperthreading Atom Diamondville (at 1.6-2.2 GHz) has a TDP of 4W. Which suggests that its low-power mode is very efficient--if TFA is correct--given that they only saw a 4W increase in power consumption under load.
OTOH, the 2GHz Nano has a TDP of 25W.
IMHO, it is a mistake to think that the Nano and the Atom are really fighting for the exact same market. This seems to be based on the fact that they are both available on Mini-ITX boards. It seems to me that Atom is an extremely stripped-down processor designed for extremely low-power use... while the Nano is actually more "beefed-up" than previous Via processors like the C7... featuring more complex execution units and the full 64-bit instruction set.
Right. I get the inspirational quality of putting real live humans on the moon.
But I don't think it is worth it. It is *really* expensive. If it were a billion or two, I'd say, "Go for it." But we're talking tens or hundreds of billions of dollars. Enough to educate thousands of engineers and scientists, or vastly improve health care in our country, or fund aggressive energy research... or even fight a few more months in Iraq.
Some say that the Apollo Program spurred on significant advances in science and technology in the USA. But I think they get it backwards. The Apollo Program was actually more of a *byproduct* of a renewed focus on science and engineering in the face of intense Soviet competition. And not a bad byproduct at that.
I guess I would like to see the US get serious about technical prestige and education FIRST, and only CONSIDER going back to the moon AFTER we've regained our prowess in science and engineering.
Why do want to go to the moon? Because the Chinese are going?
... but it's otherwise an utterly worthless dick-swinging contest.
Let's see... why did we want to go last time? Oh, because the Russians were going. Aha.
Putting a man on the moon may be inspiring and make for great geopolitical drama, and it's fun to touch the moon rock at the Air and Space Museum
It's extremely expensive to get there, and the fact that we still have no idea what to do with it (as evidenced by this very article!!) suggests it ain't worth it. Until there's some compelling economic or scientific reason for a moon visit, I believe it's simply a boondoggle for the things-we-can-do-by-wasting-enough-fossil-fuel industry.
PIC may have a "reduced" instruction set, but it violates nearly every other principal of RISC design: its instruction set is hopelessly non-orthogonal, it is severely lacking in general-purpose registers (ONE), and its addressing modes are extremely crude, requiring bank switching and making position-independent code essentially impossible.
AVR on the other hand is great. It has a fully orthogonal instruction set, 32 general purpose registers, and sane addressing modes.
I don't know why chooses PIC over AVR. Because AVR is RISC, it has *much* better compiler support, including a full GCC port. The only thing I can think of is that, in my experience, Microchip is very generous with free samples of PIC's, while Atmel is very stingy... that's why I ended up using PICs for several student projects, to save myself a few bucks 8-)
... but there are many processors that tend towards the RISC end of the spectrum (ARM, MIPS etc) which clearly have RISC roots. ARM, MIPS etc dominate in mobile space because they switch less transistors to achieve the same function (one of the goals of RISC design) and thus use less power. One reason x86 is encroaching on the mobile space is because the extra transistors required for the complex instruction set are becoming less and less important. It used to be, when you only had 100k transistors to implement your embedded processor, it was a serious drag to use 20k of them for complex microcoded instructions... but now that embedded processors can contain millions of transistors, it's hardly a blip.Not that I don't think RISC is better for other reasons, I just think that it is losing this particular battle...
The only real point in x86 is Windows compatability. Linux runs fine on ARM and many other architectures. There are probably more ARM Linux systems than x86-based Linux systems (all those Linux cellphones run ARM).
Apart from some very low level stuff, modern code tends to be very CPU agnostic.
Absolutely, Linux runs great on ARM (lots of PDAs) and on MIPS (my hacked Netgear router).I agree that x86 is only useful for Windows compatibility... witness how quickly Linux software got recompiled for x86-64 (I was running it in 2005 and was by no means an early adopter) while most Windows software is still wheezing along in the 32-bit world. Open-source pretty much removes all the inertia in instruction set choice.
I recently read an interesting book, Guide to RISC Processors by Dandamundi, which compares several RISC families. As I see it, MIPS is essentially RISC the way God intended it to be. It's the most beautifully clean and orthogonal instruction set. Any instruction that could be split into smaller parts has been.
By comparison, SPARC and PowerPC are a little less RISC-y than MIPS, and Itanium strays quite far. ARM is a very clever architecture, in that it offers very high code density through interesting addressing modes, barrel shifting, and condition codes... it maps VERY WELL onto C code.
Frankly, I think we should all just run MIPS. It's such a simple and yet efficient architecture. You can easily implement the core in Verilog. It is easy for compilers to optimize generated code. Quite brilliant. If I could buy myself an ATX motherboard with a fast MIPS processor on it, I'd chuck my x86-64 in no time...
Bravo! Finally, someone who actually intends to help the customer do what they want, rather than tell them they're too stupid to do it...
I know we're all IT people here, we run our own RDBMS, rebuild our kernels, etc. etc. but...
Imagine for a second that you're not the OP's client. Wow, it's going to be awfully frustrating when the company you've hired for database support says, "We won't let you do what you want with the database, because we think you're too stupid."
Even *if* that is true, flat-out rejecting it is going to lose you business fast. Better to build an auxiliary database that they can use for their own queries, or otherwise come up with a real live compromise solution... just as tjstork suggested.
Agreed. I should have said that giga=1000^3, not 1024^3. There are binary prefixes (kibi, mebi, gibi, tebi, etc.) for the latter case.
:-(
AFAIK, it's been standard practice for hard drive makers to report capacity in decimal units for years... but operating systems seem to be wildly inconsistent about what they do