People don't want a single dedicated computer. They don't want their whole lives bound up in one piece of hardware.
This, of course, is why people own iPods, PDAs, cell phones that store dialing lists, etc. They can decide on the type of machine that's best suited to storing particular data.
At least to me, his service doesn't seem like much of an improvement on that. In fact, it seems to do rather the opposite: while I suppose with his service, my data might be spread across a bunch of machines in a web server farm (plus back end servers, etc.) it all looks and acts like it's on one centralized computer.
I have a small number of devices, each with a particular purpose. He probably has more devices, but they all seem to have the same purpose: taking my money, while reducing functionality.
Everything is cake when you are an undergrad, and one week's or even one summer's experience with C++ and.NET is just scratching the surface. The C++ specification book (Stroustrup) is a thousand pages and very densly written..NET is enormous and also takes a year to years to master. The best thing you can do during the summer job is learn from the more experienced people working there (their methods, working with the customer/management, etc.). The programming aspects of the job mainly just bolster the buzzwords on your next resume and provide talking points during interviews.
While you make some good points, you also have a couple of mistakes there. First of all, it's been quite a while since any of Stroustrop's books was really the C++ spec. Anymore, the spec. is the 2003 edition of the C++ standard (aka ISO 14882), and before that it was the 1998 edition of the same. Oh, and FWIW, while it's certainly densely written, it's less than 800 pages long.:-)
.NET is huge, but that's not necessarily very closely related to the time it'll take to master it. In fact, I'd almost go so far as to say that.NET simply isn't oriented toward toward what I would normally consider real mastery. At least from my viewpoint, it's a rather "flat" library -- very large, but not a lot of real depth. Most of the functions just "do what they do", and that's the end of it. To a large extent, "mastery" is mostly a matter of sufficient familiarity that you can quickly find the functions you want/need at any given time.
That's a direct contrast to, for example, the Boost Library or the Loki Library, which are a lot smaller, but a whole lot deeper. Here much of mastery is simply wrapping your head around some of the concepts involved. A few people accustomed to Lisp, Scheme, Ocaml, etc., may already be accustomed to some of them, but most typical programmer have never even considered doing the kinds of things it covers (and even the Lisp crowd is likely to find a fair amount of it somewhat challenging as well).
To put that contrast a bit differently: if you were accustomed to Java (for example), using.NET would mostly mean learning different names for classes and member functions, but the classes and member functions would still be on the same order as you were used to (a bit cleaner in some places, a bit grungier in others, but ultimately the same general kind of thing). By constrast, either Boost or Loki is much more likely to cause fundamental alterations in how you think about and solve your problems.
From a "free speech" point of view, how is this any different than than your local newspaper's editorial policy?
Communications falls into two classes. A newspaper has an editorial policy. In return for that privilege, it's also held responsible for exercising it appropriately. For example, if a newspaper published a threat on somebody's life, they could be held responsible for that threat.
The other category is common carriers. This normally includes things like telephone companies. They are not allowed to exercise any sort of editorial policy on what they carry. In return for that, they are not held responsible for the content -- it is considered a communication direct from the source to the destination, and the source is responsible for the content.
As far as free speech goes, things get a little more complex. Common carriers are frequently monopolies, or at least effectivley monopolies within particular areas (e.g. most of us have little real choice about our local phone carrier, or at least didn't until VoIP became an alternative). In contrast, at least in the United States there are laws that attempt to prevent companies that exercise editorial control from becoming monopolies -- for example, a single company owning every TV station, radio station and newspaper in a given town isn't supposed to be allowed.
At least to me, a backbone provider seems to fit much more closely with the common carrier model. I'm quite certain none of them is going to be willing to take responsibility for the content they deliver (e.g. all the spam I receive), and if they're not willing to take that responsibility, they shouldn't get the privileges that go with it.
Also unlike newspapers, the barriers to entry are exceptionally high. If I don't like my newspaper, I can start writing my own and print it on my ink jet. If I get more subscribers than that will work for, I have a wide choice of print shops, etc., escalating all the way to buying my own large-scale printing presses. By contrast, if the backbone providers decide to throttle my bandwidth, I have no effective alternative -- even if I have an alternative ISP avaialble, it's going to connect to the same backbone, which is where the throttling is being discussed.
2. Does this form of content limitation take away any of the rights you had before the dawn of email?
In theory, no. Effectively, yes.
Yes, you theoretically still have most of the options you did 30 years ago (or whenever). Effectively, however, this is not meaningful. Consider, for example, if the major ISPs decided that all web sites presenting an agenda they considered excessively liberal would get cut to dial-up bandwidth, while all representing sufficiently conservative attitudes would be automatically moved up to the top tier.
30 years ago, both would have been limited to the modes of communication then avaialble. If, however, the communication of one is artificially limited while the other is not, the effect is that on a relative basis, the one has been reduced to far below what was available to it in the past. This argument would be a bit like a TV network refusing to carry ads for a particular candidate on the basis that he still had the possibility of hiring a stage coach to carry his message to the country (and at least in the US, TV networks are specifically required to provide political ads on an even-handed basis).
To summarize: the similarity to a newspaper is mostly superficial -- and (in particular) the difference has already been defined and addressed legally. The ISPs seem to be attempting to allow themselves the privileges of common carrier status, while still being able to exercise editorial control. IMO, the reasons for separating the two are good, and if they want to exercise editorial control, then the absolute least they should be required to do is take the responsibility that goes with it.
Unfairness in the availability of communicaion can effectively reduce communication ability, even if previous capabilities are retained.
And lawyers wonder why we engineers and mathematicians snigger behind their backs.
Oddly, many of the lawyers I know are engineers. I can see where almost anybody could end up a bit twisted from trying to snigger behind their own back...:-)
What we really need is to get the legislatures to write law in clear, boolean logic that anybody can follow and always come up with the same answer....
Experience with programming languages, design specification languages, etc., would tend to indicate that even when everybody wants the communication to be clear, it often isn't. Add in a (sometimes quite strong) motivation to misread, misunderstand, etc., and there's virtually no chance you can prevent all misunderstanding and such.
Don't get me wrong -- I'm certainly not trying to say law-writing isn't open to improvement. At the same time, my own experience has been that a lot of the law is written far more carefully than it's given credit for. There's also quite a bit of room for a bit of judgement in legal matters -- in fact, I'd say some of the worst laws around are those that attempt to be completely binary, and remove all human judgement.
"Dispositive" isn't from "dis-positive". It's from the same root as "disposition", "dispose", etc. What they're saying is that they don't need to send this case back to the lower court for a retrial or anything like that -- they have enough evidence to make a final decision about the case.
CMOS isn't new.
Digital camera's aren't new.
CMOS digital camera's aren't new.
[... ]
Nothing to see, please move along.
There is a bit to see here, but most people are missing it.
The sensor market has been (mostly) split into two parts. CCD sensors are sold on the open market, so (for example) the 8 MP cameras from Konica/Minolta/Sony, Nikon, and Canon (and often a few others) frequently use exactly the same sensor.
CMOS sensors, however, have been mostly custom-designed and built for one specific camera -- Canon's been using them for quite a while, but Canon's sensors are used only in their own cameras. Nikon's built a CMOS-based dSLR as well, but (again) it's used only in that one model of camera.
I can't imagine Micron entering the camera market, so it's a pretty fair guess that this will be offered on the open market -- nearly a first for CMOS sensors. It's also notable that up until now, even if they offered the sensor for others to buy, the sensors have been built by companies that sold cameras (possibly in addition to a lot of other stuff). Micron is a pure semiconductor house, with almost no previous interest in the camera world at all. Given the small number of sensors that really make up the majority of cameras, nearly any new entry into the market is probably a good thing.
Apparently it's easy for the dogs to sniff out *only* the pirate DVDs because those are the ones that haven't washed in months and smell like salt-tack and grog.
You mean there are actually Pastafarian DVDs? No need for any more research into artificial intelligence, eh matey? Aaargh!
Given that the MPAA has been sued under racketeering statutes, shouldn't we be training dogs to sniff out any MPAA (or RIAA) executives who travel? Clearly their traveling would be a strong indication of collusion with their fellow racketeers, otherwise known as conspiracy. Given the way my nose wrinkles at even thinking about them, I'd think it would be easy to train some dogs to recognize their stench.
Of course, if the dogs were trained to attack when they found this particular illegal substance...
Who says it's not damaged already. That's one of the problems with these hacks. You could break a transistor and instead of getting a 1 in 10^-20 chance of error it's now upto 10^-9. Once in a while you'll get an error, probably not notice it yourself but something your doing could be affected.
It's pretty hard to create a problem like this. The manufacturers (with a few notable slipups) test and rate the CPU up to some given temperature. Intel puts a couple of thermal diodes in each chip, to shut the machine down if you exceed the range within which it's reliable. In addition, quite a few parts of the chip have self-checking going on all the time. For an obvious example, cache typically occupies at least half of a modern chip, and a Pentium D's cache error detection/correction coding attached to the data.
In addition, consider what your numbers would mean. An Intel P4 typically executes close to 2 instructions per clock. Just for the sake of argument, let's assume it takes the machine 20 seconds to boot. 4.1 GHz x 2 IPC X 20 seconds gives 16.4 billion (read milliard, if that word's in your vocabulary) instructions just to finish booting.
Since one billion (milliard) is 10^9, that means if your numbers were correct, it would have to survive around 16 incorrectly executed instructions JUST to finish booting. To run a single hour, the number of incorrect instructions would run into the thousands...
What do Real think they have a patent on exactly [... ]
If you really want to know, why don't you read the patent?
If you do so, you'll have the rare privilege of finding that (for example) the claims that this is about fallback and/or buffering, and complete nonsense! The statements about buffering at least have a minimal defense -- as you'd expect in describing a streaming system, the patent claims do mention the client system having buffers -- though even there it's a bit more restrictive than would necessarily be obvious (e.g. it requires separate buffers for the data stream and the metadata).
In fairness, it's a little bit difficult to quickly summarize what is supposed to be novel and non-obvious about what's patented. In many patents, what's supposedly novel, non-obvious, etc. (novel and non-obvious are not considered synonymous) is usually the combination of elements in the patent, rather than one of the elements by itself.
Doing a bit of reading, they talk about doing things like allowing you to recieve the audio data and the metadata from separate servers. They also talk about something that sounds quite a bit like remote DMA. When you send a request for some audio data, you don't just specify a filename -- you specify the memory location on the remote computer where that data is stored.
Disclaimer: I only took a rather quick glance through the patent claims. While I'm reasonably certain that what I've outlined above is discussed in the claims, it wouldn't surprise me at all if there's more to it as well -- the patent has 40 claims altogether, and to really know what it's talking about you should read the disclosure as well as the claims. I'm also not an attorney, so you certainly shouldn't mistake anything I say for legal advice.
[... ] and can I interest them in a bridge?
Can I interest you in learning what the patent covers before you blithely assume it's nonsense?
As a young person considering various choices for the future career I'd like to pursue, IT and computer science continually reappear near the top of the list of fields I'm interested in.
I'd say that if both are showing up, either the testing methodology is a mess, or else you need to give considerably more thought to what you really want. At least IMO, the mindsets needed for IT and computer science are enough different that almost no one person is likely to be particularly good at both.
IT mostly involves applying existing knowledge. It's true that you need often to write bits of code, typically in some scripting language to apply the existing knowledge to your exact situation.
Though the term is often mis-applied, computer science is really about research into things like algorithms, languages, computability, etc. For a true computer scientist, writing code is mostly a sideline, and the code s/he writes will often be little more than a proof of concept to demonstrate something they've invented (e.g. a demonstration implementation of a new algorithm). The code he writes will rarely have much practical applicability -- if he's demonstrating a sorting algorithm, it'll probably have a nearly unusable user interface. OTOH, if he's doing user interface research, it probably won't implement any real algorithm behind that interface.
More or less halfway between the two is software engineering. At least as I'd use the term, software engineering is what many "computer scientists" really do. Specifically, a software engineer is somebody whose primary job is to develop software. The software engineer should be aware of what the computer scientists have invented, and (particularly) needs to have a broader perspective, to help produce complete applications including both (reasonably) optimal algorithms and decent UIs.
From a corporate perspective, computer science falls under "research". Software Engineering falls under "development", and IT falls under operations.
Consider a single task: doing backups. A computer scientist might deal with something like inventing a faster method for coalescing incremental updates to a file to produce the final output more quickly. The software engineers write the backup program that implements this algorithm, along with a decent UI, etc. The IT person is responsible for ensuring that the backup program is run at the right times, ensuring the correct backup media are in the drives at the right times, etc.
A computer scientist will usually be absent-minded, idealistic and will focus on future possibilities. An IT specialist will be pragmatic, focused on the here and now, and his single largest strength will often be presence of mind.
If their system worked for some people and not others, you might stand a chance legally. If there was a reasonably obvious system to who it worked for and who it didn't, you'd probably stand a pretty good chance legally. As-is, however, it apparently just doesn't work for anybody -- and as long as it fails equally for everybody, chances are they're perfectly fine legally.
My guess is that the manager in question simply isn't very woried about hiring anybody right now. If he was working 60+ hours a week to cover for a short staff, you can bet he'd make sure your application was accepted electronically, on paper, or in just about any other form short of scratched onto the wall of a cave...
Of course, the obligatory disclaimer: IANAL, etc., so take it for what it's worth...
A friend of mine said, when Windows 95 came out that "it'll knock the socks off Linux..." and it didn't. Then he said "This windows NT 4.0 will kill Linux" and it didn't. Then "XP is the Linux killer, mark my words. It's got built in security.." and look what happened. Need I go on? The MS buffs continually postition various MS OS releases as Linux killers, and they never are.
Let's see:
A friend of mine said, when Redhat came out that "it'll knock the socks off Windows..." and it didn't. Then he said "This Gentoo will kill Windows" and it didn't. Then "Ubuntu is the Windows killer, mark my words. It's got built in security.." and look what happened. Need I go on? The Linux buffs continually postition various Linux releases as Windows killers, and they never are.
Yup -- sounds just about as accurate in one direction as the other. People have been predicting UNIX taking over the desktop for decades, but its market share is still somewhat less than dominant. In fairness, yes, it's gaining market share, and it wouldn't even surprise me to live long enough to actually see it become dominant. But it clearly hasn't happened yet, and when the predictions started, it was touted as being set to kill off MS-DOS, not Windows (which didn't exist yet).
I suspect what we have here is at least as much a misunderstanding as it is a real disagreement. The issue is what you mean by "control" over something. I think Oracle is thinking in terms of what I'd call positive control -- i.e. having direct input into its development, strategic direction, etc. I suspect IBM is talking more in terms of negative control -- i.e. being able to control what others do with the software.
If that's the case, they're both basically right -- Oracle certainly can buy companies (for example) that have teams working on open source projects, and thereby gain a fair amount of control over the direction that project is likely to take. IBM's right as well though. If (for example) Oracle were to buy Novell, others could still do whatever they liked with Linux and ignore Oracle if they chose to do so.
An investment into open source development gives only the power to persuade, not coerce. The power of persuasion, however, should not be underestimated -- especially if the persuasion is an honestly free offer.
Of course their report would be an a standards based and open format like RTF or text, right?
Yes and no. Yes, it uses PDF for which there are open standards (ISO 15930 and ISO 19005 to name only a couple). No, that's not much like RTF, for which there is not (TTBOMK) an open standard. After Microsoft releases a new version of Word, they (at least usually) publish a specification of the format of RTF files it'll produce -- but that's not much like an open standard process where other interested parties have input into what the spec will look like (like the ISO standards mentioned above).
In fairness, the ISO standards above primarily specify subsets of the PDF format as defined by Adobe, and they use Adobe's specs as normative references, so the difference isn't as clear-cut as it would be in some cases. OTOH, at most this puts PDF alongside RTF -- I certainly can't see any way the RTF spec could be considered any more open, and generally I'd say it's less so.
That would be what - maybe a die 0.3mm on a side today? maybe a bit over 1 mm**2 with all the memory?
It should be smaller than that in 65 nm. Just for one example, NEC claims 404,000 usable gates per square millimeter in a 90 nm process. A 65 nm process should theoretically cut the area in half. Of course, the only company I know of that even claims to offer 65 nm ASIC processing is IBM, and I'm not at all sure they have any customers for it. You have to plan on producing quite a few chips to justify the NRE on a 65 nm ASIC.
If you were going to do memory, you might as well include the full 256 k words it could address, rather than the 128K words the 6600 could actually hold. After all, that's only about a megabyte, which fits on a die pretty easily nowadays...
65 nm process could give it a bit of a clock boost, too, I reckon.
You would certainly think so. In fact, there's a free (as in beer) emulator that runs under Windows. Though it's hard to compare speeds, I'd say the emulator generally runs faster than real hardware did.
Come to think of it, it'd be interesting to see how well it'd work in an FPGA. It'd be pretty cool to see SCOPE running on a machine you can hold in one hand...
Merom is a major revision of Yonah, but is derived from the same code base. In fact, it is still technically a derivative of the P6 family that began with the Pentium Pro 10 years ago.
To those of us old enough to remember, it looks more like part of the family that started with the CDC 6600 over 40 years go.:-) For anybody who cares to look, Design of a Computer: The CDC 6600 (Warning: PDF), describes what may well be the greatest microarchitecture ever. It's by Jim Thornton, who was (to quote Seymour Cray): "personally responsible for most of the detailed design of the Control Data model 6600 system."
Those who look through this book may also note a decided resemblance between the original Pentium and the CDC 6500 (which it also discusses to some degree).
Related to this (but still in the early research phase) is the idea of reconfigurable computing.
[...]
still in the research phase, but interesting to think about.
It's interesting for more than just thought -- it's interesting to play with right now. Unfortunately, most of the tools for FPGA development are oriented primarily toward use by engineers far more than programmers. The hardware could use a bit of extra help too, at least IMO -- one thing I've suggested to Xilinx is some sort of thermal monitoring capability built into the chip. This probably doesn't make a lot of sense on the small, low-end FPGAs (E.g. Spartans) or CPLDs, but it'd add only a trivial percentage to the cost of a high-end Virtex part.
As I noted above, however, the tools are the big problem. Reconfigurable Computing nearly requires dynamic partial reconfiguration of the device (i.e. reprogramming some parts of the circuitry while leaving other parts intact). Xilinx is about the only vendor that even claims to support that, but while the hardware to do it is there, the software support in their toolkit is _quite_ lacking (in fact, there's thread on comp.arch.fpga that's been talking about this (warning -- it gets just a bit heated at times...). Right now, they're adding support via their PlanAhead tool, which is a rather expensive add-on to ISE (their usual toolkit). Worse, it's something you can't plan on distributing for use by even a fairly technically adept end-user.
It's fun to play with, but not really ready for prime time yet -- and neither Altera nor Xilinx (who make the vast majority of FPGAs sold) _seems_ to be particularly interested in supporting either. It'll be interesting to see what happens -- but I'm not going to hold my breath for much to happen either. Reconfigurable computing has been a "next big thing" for 10 years or so now, and I'm not entirely sure how soon that's going to change.
If you want to do some experimenting with it, one interesting possibility is the RaggedStone 1 board from Enterpoint Ltd. -- a 400,000 gate FPGA with a PCI connector. You have to add a PCI core to make it talk to your computer, but opencores.org has a free one that works with it. And to answer the inevitable next question, yes, it does run (under) Linux. If you wanted to get crazy about it, you could even run a copy of ucLinux on the board as well (though this would be a bit pointless -- the main point of reconfigurable computing is to use reconfigurable hardware to implement things that are hard to do well in software).
This seems to have been primarily a result of competition (e.g. with the NATO countries) though.
We've never had a situation where a single communist government existed with essentially no outside competition -- but my guess is that if there was such a thing, it wouldn't be very progressive, technically or otherwise.
ATI will be showing it off behind closed doors this week.
...but considering how ATI's been lately, showing it off this week means they might be able to deliver a working product this year -- but just as likely not.
I really don't mean to be nasty, but it seems like an awful lot of what ATI has announced recently has taken an _awfully_ long time to really become available.
The usual explanation for this is that the effort that goes into designing the chip for the XBox distracts the company involved (previously nVidia, now ATI) to the point that they get behind in the rest of the market. This doesn't really seem to me like it adds up though. First of all, the design work for ATI was clearly done a while before the XBox came out. Second, neither nVidia's design for the original XBox nor ATI's for the 360 is really so revolutionary (despite Microsoft's marketing) that they seem like they should be all that much of a distraction anyway.
A few years ago, they were being slammed for doing load balancing where they offloaded graphics processing onto the CPU when/if the CPU was less busy than the GPU. Now the GPUs are enough faster that they can frequently expect to be "ahead" of the CPU -- so now they're starting to work on doing the opposite, offloading work from the CPU to the GPU instead.
Of course, the basic isn't exactly brand new -- some of us have been writing shaders to handle heavy duty math for a while. The difference is that up until now, most real support for this has been more or less experimental (e.g. the Brook system for doing numeric processing on GPUs. Brook is also sufficiently different from an average programming language that it's probably fairly difficult to put to use in quite a few situations.
Having a physics-oriented framework will probably make this capability quite a bit easier to apply in quite a few more situations, which is clearly a good thing (especially for nVidia and perhaps ATI, of course).
The part I find interesting is that Intel has taken a big part of the low-end graphics market. Now nVidia is working at taking more of the computing high-end market. I can see it now: a game that does all the computing on a couple of big nVidia chips, and then displays the results via Intel integrated graphics...
According to the summary, the US was responsible for 40% of the drop. According to the story, the US was respnosible for 40% of the sales. The story says sales dropped 6% in the US but 7.9% worldwide -- so the US was actually responsible for about well under 40% of the drop.
OTOH, whether it's 6% or 8% doesn't make all that much difference in the end -- this is something like the fifth year running that movie sales have dropped...
I totally agree with the statement about assembler.. So many kids today dont have a clue what their code is *actually* doing.
I think a pretty strong case could be made that the same is true for anybody who's only learned assembly language -- you're still working with a conceptual model that bears (especially in a modern CPU) only a distant relationship with reality.
If you really want to know what you're code is actually doing, you just about need to learn a hardware design language (Verilog and VHDL are the two big ones) and desig at least a simple CPU of your own. If you want to understand a modern CPU in full detail, plan on spending some time at it though -- designing a CPU with things like caching, out of order execution, branch prediction, etc., is a decidedly non-trivial task.
No, I'm not being sarcastic here -- I really do think hardware design is worth learning about. Fortunately, nowadays it's much easier to get into than it used to be. You can pick up an FPGA-based development kit for $100US or so that'll let you do real designs that do real work.
Speaking from experience, it can also be quite a bit of fun. The first time you watch a program running on a CPU you designed from the ground up, it's definitely very cool -- even if it's only an 8-bit CPU running at 10 MHz.
Slashdot Mirror
This, of course, is why people own iPods, PDAs, cell phones that store dialing lists, etc. They can decide on the type of machine that's best suited to storing particular data.
At least to me, his service doesn't seem like much of an improvement on that. In fact, it seems to do rather the opposite: while I suppose with his service, my data might be spread across a bunch of machines in a web server farm (plus back end servers, etc.) it all looks and acts like it's on one centralized computer.
I have a small number of devices, each with a particular purpose. He probably has more devices, but they all seem to have the same purpose: taking my money, while reducing functionality.
While you make some good points, you also have a couple of mistakes there. First of all, it's been quite a while since any of Stroustrop's books was really the C++ spec. Anymore, the spec. is the 2003 edition of the C++ standard (aka ISO 14882), and before that it was the 1998 edition of the same. Oh, and FWIW, while it's certainly densely written, it's less than 800 pages long. :-)
That's a direct contrast to, for example, the Boost Library or the Loki Library, which are a lot smaller, but a whole lot deeper. Here much of mastery is simply wrapping your head around some of the concepts involved. A few people accustomed to Lisp, Scheme, Ocaml, etc., may already be accustomed to some of them, but most typical programmer have never even considered doing the kinds of things it covers (and even the Lisp crowd is likely to find a fair amount of it somewhat challenging as well).
To put that contrast a bit differently: if you were accustomed to Java (for example), using .NET would mostly mean learning different names for classes and member functions, but the classes and member functions would still be on the same order as you were used to (a bit cleaner in some places, a bit grungier in others, but ultimately the same general kind of thing). By constrast, either Boost or Loki is much more likely to cause fundamental alterations in how you think about and solve your problems.
Communications falls into two classes. A newspaper has an editorial policy. In return for that privilege, it's also held responsible for exercising it appropriately. For example, if a newspaper published a threat on somebody's life, they could be held responsible for that threat.
The other category is common carriers. This normally includes things like telephone companies. They are not allowed to exercise any sort of editorial policy on what they carry. In return for that, they are not held responsible for the content -- it is considered a communication direct from the source to the destination, and the source is responsible for the content.
As far as free speech goes, things get a little more complex. Common carriers are frequently monopolies, or at least effectivley monopolies within particular areas (e.g. most of us have little real choice about our local phone carrier, or at least didn't until VoIP became an alternative). In contrast, at least in the United States there are laws that attempt to prevent companies that exercise editorial control from becoming monopolies -- for example, a single company owning every TV station, radio station and newspaper in a given town isn't supposed to be allowed.
At least to me, a backbone provider seems to fit much more closely with the common carrier model. I'm quite certain none of them is going to be willing to take responsibility for the content they deliver (e.g. all the spam I receive), and if they're not willing to take that responsibility, they shouldn't get the privileges that go with it.
Also unlike newspapers, the barriers to entry are exceptionally high. If I don't like my newspaper, I can start writing my own and print it on my ink jet. If I get more subscribers than that will work for, I have a wide choice of print shops, etc., escalating all the way to buying my own large-scale printing presses. By contrast, if the backbone providers decide to throttle my bandwidth, I have no effective alternative -- even if I have an alternative ISP avaialble, it's going to connect to the same backbone, which is where the throttling is being discussed.
In theory, no. Effectively, yes.
Yes, you theoretically still have most of the options you did 30 years ago (or whenever). Effectively, however, this is not meaningful. Consider, for example, if the major ISPs decided that all web sites presenting an agenda they considered excessively liberal would get cut to dial-up bandwidth, while all representing sufficiently conservative attitudes would be automatically moved up to the top tier.
30 years ago, both would have been limited to the modes of communication then avaialble. If, however, the communication of one is artificially limited while the other is not, the effect is that on a relative basis, the one has been reduced to far below what was available to it in the past. This argument would be a bit like a TV network refusing to carry ads for a particular candidate on the basis that he still had the possibility of hiring a stage coach to carry his message to the country (and at least in the US, TV networks are specifically required to provide political ads on an even-handed basis).
To summarize: the similarity to a newspaper is mostly superficial -- and (in particular) the difference has already been defined and addressed legally. The ISPs seem to be attempting to allow themselves the privileges of common carrier status, while still being able to exercise editorial control. IMO, the reasons for separating the two are good, and if they want to exercise editorial control, then the absolute least they should be required to do is take the responsibility that goes with it.
Unfairness in the availability of communicaion can effectively reduce communication ability, even if previous capabilities are retained.
Experience with programming languages, design specification languages, etc., would tend to indicate that even when everybody wants the communication to be clear, it often isn't. Add in a (sometimes quite strong) motivation to misread, misunderstand, etc., and there's virtually no chance you can prevent all misunderstanding and such.
Don't get me wrong -- I'm certainly not trying to say law-writing isn't open to improvement. At the same time, my own experience has been that a lot of the law is written far more carefully than it's given credit for. There's also quite a bit of room for a bit of judgement in legal matters -- in fact, I'd say some of the worst laws around are those that attempt to be completely binary, and remove all human judgement.
"Dispositive" isn't from "dis-positive". It's from the same root as "disposition", "dispose", etc. What they're saying is that they don't need to send this case back to the lower court for a retrial or anything like that -- they have enough evidence to make a final decision about the case.
There is a bit to see here, but most people are missing it.
The sensor market has been (mostly) split into two parts. CCD sensors are sold on the open market, so (for example) the 8 MP cameras from Konica/Minolta/Sony, Nikon, and Canon (and often a few others) frequently use exactly the same sensor.
CMOS sensors, however, have been mostly custom-designed and built for one specific camera -- Canon's been using them for quite a while, but Canon's sensors are used only in their own cameras. Nikon's built a CMOS-based dSLR as well, but (again) it's used only in that one model of camera.
I can't imagine Micron entering the camera market, so it's a pretty fair guess that this will be offered on the open market -- nearly a first for CMOS sensors. It's also notable that up until now, even if they offered the sensor for others to buy, the sensors have been built by companies that sold cameras (possibly in addition to a lot of other stuff). Micron is a pure semiconductor house, with almost no previous interest in the camera world at all. Given the small number of sensors that really make up the majority of cameras, nearly any new entry into the market is probably a good thing.
(Grammar nazi mode)
If you're going to correct someone, do it correctly.
You mean there are actually Pastafarian DVDs? No need for any more research into artificial intelligence, eh matey? Aaargh!
Of course, if the dogs were trained to attack when they found this particular illegal substance...
It's pretty hard to create a problem like this. The manufacturers (with a few notable slipups) test and rate the CPU up to some given temperature. Intel puts a couple of thermal diodes in each chip, to shut the machine down if you exceed the range within which it's reliable. In addition, quite a few parts of the chip have self-checking going on all the time. For an obvious example, cache typically occupies at least half of a modern chip, and a Pentium D's cache error detection/correction coding attached to the data.
In addition, consider what your numbers would mean. An Intel P4 typically executes close to 2 instructions per clock. Just for the sake of argument, let's assume it takes the machine 20 seconds to boot. 4.1 GHz x 2 IPC X 20 seconds gives 16.4 billion (read milliard, if that word's in your vocabulary) instructions just to finish booting.
Since one billion (milliard) is 10^9, that means if your numbers were correct, it would have to survive around 16 incorrectly executed instructions JUST to finish booting. To run a single hour, the number of incorrect instructions would run into the thousands...
You sir, have a mediocre grasp of the blindingly obvious!
I'm tempted to go into a lot more detail, but it would just weaken the message...
If you really want to know, why don't you read the patent?
If you do so, you'll have the rare privilege of finding that (for example) the claims that this is about fallback and/or buffering, and complete nonsense! The statements about buffering at least have a minimal defense -- as you'd expect in describing a streaming system, the patent claims do mention the client system having buffers -- though even there it's a bit more restrictive than would necessarily be obvious (e.g. it requires separate buffers for the data stream and the metadata).
In fairness, it's a little bit difficult to quickly summarize what is supposed to be novel and non-obvious about what's patented. In many patents, what's supposedly novel, non-obvious, etc. (novel and non-obvious are not considered synonymous) is usually the combination of elements in the patent, rather than one of the elements by itself.
Doing a bit of reading, they talk about doing things like allowing you to recieve the audio data and the metadata from separate servers. They also talk about something that sounds quite a bit like remote DMA. When you send a request for some audio data, you don't just specify a filename -- you specify the memory location on the remote computer where that data is stored.
Disclaimer: I only took a rather quick glance through the patent claims. While I'm reasonably certain that what I've outlined above is discussed in the claims, it wouldn't surprise me at all if there's more to it as well -- the patent has 40 claims altogether, and to really know what it's talking about you should read the disclosure as well as the claims. I'm also not an attorney, so you certainly shouldn't mistake anything I say for legal advice.
Can I interest you in learning what the patent covers before you blithely assume it's nonsense?
I'd say that if both are showing up, either the testing methodology is a mess, or else you need to give considerably more thought to what you really want. At least IMO, the mindsets needed for IT and computer science are enough different that almost no one person is likely to be particularly good at both.
IT mostly involves applying existing knowledge. It's true that you need often to write bits of code, typically in some scripting language to apply the existing knowledge to your exact situation.
Though the term is often mis-applied, computer science is really about research into things like algorithms, languages, computability, etc. For a true computer scientist, writing code is mostly a sideline, and the code s/he writes will often be little more than a proof of concept to demonstrate something they've invented (e.g. a demonstration implementation of a new algorithm). The code he writes will rarely have much practical applicability -- if he's demonstrating a sorting algorithm, it'll probably have a nearly unusable user interface. OTOH, if he's doing user interface research, it probably won't implement any real algorithm behind that interface.
More or less halfway between the two is software engineering. At least as I'd use the term, software engineering is what many "computer scientists" really do. Specifically, a software engineer is somebody whose primary job is to develop software. The software engineer should be aware of what the computer scientists have invented, and (particularly) needs to have a broader perspective, to help produce complete applications including both (reasonably) optimal algorithms and decent UIs.
From a corporate perspective, computer science falls under "research". Software Engineering falls under "development", and IT falls under operations.
Consider a single task: doing backups. A computer scientist might deal with something like inventing a faster method for coalescing incremental updates to a file to produce the final output more quickly. The software engineers write the backup program that implements this algorithm, along with a decent UI, etc. The IT person is responsible for ensuring that the backup program is run at the right times, ensuring the correct backup media are in the drives at the right times, etc.
A computer scientist will usually be absent-minded, idealistic and will focus on future possibilities. An IT specialist will be pragmatic, focused on the here and now, and his single largest strength will often be presence of mind.
My guess is that the manager in question simply isn't very woried about hiring anybody right now. If he was working 60+ hours a week to cover for a short staff, you can bet he'd make sure your application was accepted electronically, on paper, or in just about any other form short of scratched onto the wall of a cave...
Of course, the obligatory disclaimer: IANAL, etc., so take it for what it's worth...
Let's see:
A friend of mine said, when Redhat came out that "it'll knock the socks off Windows..." and it didn't. Then he said "This Gentoo will kill Windows" and it didn't. Then "Ubuntu is the Windows killer, mark my words. It's got built in security.." and look what happened. Need I go on? The Linux buffs continually postition various Linux releases as Windows killers, and they never are.
Yup -- sounds just about as accurate in one direction as the other. People have been predicting UNIX taking over the desktop for decades, but its market share is still somewhat less than dominant. In fairness, yes, it's gaining market share, and it wouldn't even surprise me to live long enough to actually see it become dominant. But it clearly hasn't happened yet, and when the predictions started, it was touted as being set to kill off MS-DOS, not Windows (which didn't exist yet).
If that's the case, they're both basically right -- Oracle certainly can buy companies (for example) that have teams working on open source projects, and thereby gain a fair amount of control over the direction that project is likely to take. IBM's right as well though. If (for example) Oracle were to buy Novell, others could still do whatever they liked with Linux and ignore Oracle if they chose to do so.
An investment into open source development gives only the power to persuade, not coerce. The power of persuasion, however, should not be underestimated -- especially if the persuasion is an honestly free offer.
Yes and no. Yes, it uses PDF for which there are open standards (ISO 15930 and ISO 19005 to name only a couple). No, that's not much like RTF, for which there is not (TTBOMK) an open standard. After Microsoft releases a new version of Word, they (at least usually) publish a specification of the format of RTF files it'll produce -- but that's not much like an open standard process where other interested parties have input into what the spec will look like (like the ISO standards mentioned above).
In fairness, the ISO standards above primarily specify subsets of the PDF format as defined by Adobe, and they use Adobe's specs as normative references, so the difference isn't as clear-cut as it would be in some cases. OTOH, at most this puts PDF alongside RTF -- I certainly can't see any way the RTF spec could be considered any more open, and generally I'd say it's less so.
It should be smaller than that in 65 nm. Just for one example, NEC claims 404,000 usable gates per square millimeter in a 90 nm process. A 65 nm process should theoretically cut the area in half. Of course, the only company I know of that even claims to offer 65 nm ASIC processing is IBM, and I'm not at all sure they have any customers for it. You have to plan on producing quite a few chips to justify the NRE on a 65 nm ASIC.
If you were going to do memory, you might as well include the full 256 k words it could address, rather than the 128K words the 6600 could actually hold. After all, that's only about a megabyte, which fits on a die pretty easily nowadays...
You would certainly think so. In fact, there's a free (as in beer) emulator that runs under Windows. Though it's hard to compare speeds, I'd say the emulator generally runs faster than real hardware did.
Come to think of it, it'd be interesting to see how well it'd work in an FPGA. It'd be pretty cool to see SCOPE running on a machine you can hold in one hand...
To those of us old enough to remember, it looks more like part of the family that started with the CDC 6600 over 40 years go. :-) For anybody who cares to look, Design of a Computer: The CDC 6600 (Warning: PDF), describes what may well be the greatest microarchitecture ever. It's by Jim Thornton, who was (to quote Seymour Cray): "personally responsible for most of the detailed design of the Control Data model 6600 system."
Those who look through this book may also note a decided resemblance between the original Pentium and the CDC 6500 (which it also discusses to some degree).
It's interesting for more than just thought -- it's interesting to play with right now. Unfortunately, most of the tools for FPGA development are oriented primarily toward use by engineers far more than programmers. The hardware could use a bit of extra help too, at least IMO -- one thing I've suggested to Xilinx is some sort of thermal monitoring capability built into the chip. This probably doesn't make a lot of sense on the small, low-end FPGAs (E.g. Spartans) or CPLDs, but it'd add only a trivial percentage to the cost of a high-end Virtex part.
As I noted above, however, the tools are the big problem. Reconfigurable Computing nearly requires dynamic partial reconfiguration of the device (i.e. reprogramming some parts of the circuitry while leaving other parts intact). Xilinx is about the only vendor that even claims to support that, but while the hardware to do it is there, the software support in their toolkit is _quite_ lacking (in fact, there's thread on comp.arch.fpga that's been talking about this (warning -- it gets just a bit heated at times...). Right now, they're adding support via their PlanAhead tool, which is a rather expensive add-on to ISE (their usual toolkit). Worse, it's something you can't plan on distributing for use by even a fairly technically adept end-user.
It's fun to play with, but not really ready for prime time yet -- and neither Altera nor Xilinx (who make the vast majority of FPGAs sold) _seems_ to be particularly interested in supporting either. It'll be interesting to see what happens -- but I'm not going to hold my breath for much to happen either. Reconfigurable computing has been a "next big thing" for 10 years or so now, and I'm not entirely sure how soon that's going to change.
If you want to do some experimenting with it, one interesting possibility is the RaggedStone 1 board from Enterpoint Ltd. -- a 400,000 gate FPGA with a PCI connector. You have to add a PCI core to make it talk to your computer, but opencores.org has a free one that works with it. And to answer the inevitable next question, yes, it does run (under) Linux. If you wanted to get crazy about it, you could even run a copy of ucLinux on the board as well (though this would be a bit pointless -- the main point of reconfigurable computing is to use reconfigurable hardware to implement things that are hard to do well in software).
This seems to have been primarily a result of competition (e.g. with the NATO countries) though.
We've never had a situation where a single communist government existed with essentially no outside competition -- but my guess is that if there was such a thing, it wouldn't be very progressive, technically or otherwise.
I really don't mean to be nasty, but it seems like an awful lot of what ATI has announced recently has taken an _awfully_ long time to really become available.
The usual explanation for this is that the effort that goes into designing the chip for the XBox distracts the company involved (previously nVidia, now ATI) to the point that they get behind in the rest of the market. This doesn't really seem to me like it adds up though. First of all, the design work for ATI was clearly done a while before the XBox came out. Second, neither nVidia's design for the original XBox nor ATI's for the 360 is really so revolutionary (despite Microsoft's marketing) that they seem like they should be all that much of a distraction anyway.
Of course, the basic isn't exactly brand new -- some of us have been writing shaders to handle heavy duty math for a while. The difference is that up until now, most real support for this has been more or less experimental (e.g. the Brook system for doing numeric processing on GPUs. Brook is also sufficiently different from an average programming language that it's probably fairly difficult to put to use in quite a few situations.
Having a physics-oriented framework will probably make this capability quite a bit easier to apply in quite a few more situations, which is clearly a good thing (especially for nVidia and perhaps ATI, of course).
The part I find interesting is that Intel has taken a big part of the low-end graphics market. Now nVidia is working at taking more of the computing high-end market. I can see it now: a game that does all the computing on a couple of big nVidia chips, and then displays the results via Intel integrated graphics...
OTOH, whether it's 6% or 8% doesn't make all that much difference in the end -- this is something like the fifth year running that movie sales have dropped...
I think a pretty strong case could be made that the same is true for anybody who's only learned assembly language -- you're still working with a conceptual model that bears (especially in a modern CPU) only a distant relationship with reality.
If you really want to know what you're code is actually doing, you just about need to learn a hardware design language (Verilog and VHDL are the two big ones) and desig at least a simple CPU of your own. If you want to understand a modern CPU in full detail, plan on spending some time at it though -- designing a CPU with things like caching, out of order execution, branch prediction, etc., is a decidedly non-trivial task.
No, I'm not being sarcastic here -- I really do think hardware design is worth learning about. Fortunately, nowadays it's much easier to get into than it used to be. You can pick up an FPGA-based development kit for $100US or so that'll let you do real designs that do real work.
Speaking from experience, it can also be quite a bit of fun. The first time you watch a program running on a CPU you designed from the ground up, it's definitely very cool -- even if it's only an 8-bit CPU running at 10 MHz.