come up with an external, plugin keyboard for a cell phone, and you might have something...
And that is something we could easily sell for $10, since most phones (even super cheap ones) have a serial port interface plug in somewhere. Distributing those would be a great benefit to the poor of the world.
Useless to him, certainly not useless to millions of poor people.
Actually, the $100 computer would be utterly useless to the millions of poor people -- if it every appeared, which I doubt.
Gates is wrong, all the same. There's a much better reason to mock the $100 laptop: what the "$100 laptop" offers already available throughout the third world, and is, increasingly, being used by people in the third world for the same thing that we in the first world use our computers for: communication. Cheap cell phones are blooming throughout Africa and Asia.
The average cell phone is a pretty powerful computer. With a display. And an always-on wireless link. And a storage system. And a data-entry pad. And, and, and.
Gates' criticism is laughable -- there's a lot of use in a small screen, for instance -- but Negroponte's idea is stupid, too.
How can this be informative? It's simply, utterly, totally, wrong.
(a) IBM manufactures Cell for Sony. There's no second source at this time. (b) The circuit boards have been outsourced to a Taiwanese OEM firm. (c) The memory has been outsourced to another OEM.
etc. Sony does not have control over its prices yet, and probably never will, given the marginal difference in cost between Japanese and off-shore assembly.
So, did anyone ever verify Gord's claims? I certainly never saw any evidence besides his screed and the interviews cited therein -- and I'm beginning to wonder if there was any. It's true that by the end, Sony was making money on the PS2 itself, but I don't think that Gord has his head on straight about the early days.
Either way, the PS3 is clearly going to lose money early on. The Cell chip itself costs enough ($237) at the current yields and sizes that a box containing it alone would need to cost $450 at retail for Sony to break even on it, and that's before things like memory, any disk player, or controller handling.
In my experience, zombies care very little about much of anything except the frontal lobes of pre-zombies. I guess I've been associating with the wrong zombies.
Volume shadow storage is exactly this kind of incremental, real-time backup process. How does this differ technically from that? (Other than the fact that you can now dynamically back up your morning toast, which is useful if a slice goes up in flames...)
That is exactly how this work. The reason it's so useful for a Windows box arises from one of the ways in which Windows makes interesting use of files on disk.
When a DLL is loaded into memory from disk, it's only relocated if there's already another DLL loaded in the same slot in virtual memory. If there's no conflict with the DLL, it's not relocated; code pages are read directly from disk and never written back. Instead, when they're swapped out (it the machine doesn't have enough RAM), the page is simply dropped into the big bucket; when it's needed again - say, because the component is loaded into another process space - it's reread from disk. The same situation obtains with "true" EXE's, except that it's slightly easier: since there's only one EXE in a given process space, no EXE's ever conflict with one another, and so they are always read, unaltered, from disk.
(If you write code for Windows, by the way, you should know that. One of the easiest ways to speed up the loading of a DLL is to rebase it on disk. There's a Windows executable called rebase.exe which rebases a DLL automatically.)
You can see why this makes a Flash-based code store compelling on a Windows system -- rebased DLLs and EXEs only change very rarely; system code, in particular, only changes when the component is updated. If this persistent store uses an MRU updating algorithm, then the code pages which are frequently used wind up in this cache, and whenever they are first loaded into process memory, they are available instantly.
This is nonsense. I just went to search.msn.com, and the top three are a pointer to the Mathworld, followed by two pointers to Wikipedia, the first being to Ramsey theory.
Caching the working set from a Windows app is a lot different from caching the heap. You can't cache the heap on a removable device without risking a bit of twitchery, but you absolutely *can* cache unrelocated program code, which saves you seek time on the hard disk.
"Quantum cryptographic protocols are so secure that they can not only discover tapping but also where and how much information is leaking out. Now, using telecloning, the identity and location of the eavesdropper can be concealed."
, but the summary says "eavesdropping on a quantum encrypted link can now be done without detection", which is exactly the opposite.
There's only one small problem with this: Microsoft doesn't have a monopoly in email server software or in mobile device software. So there's no "monopoly" to leverage.
Really? So, explain to me why throw should be avoided in all procedural languages except Scheme, and then in all cases except one, and why goto should be preferred. Explain to me why forward goto is to be preferred in all cases when you are writing against one code generator, but not against another. Those are facts which are every bit as critical to good code as whether you use bubble sort or heap sort. (In the light of which, did you know that there are extremely important cases where bubble sort is actually faster than heap sort, O(n^2) in worst case or not?)
Academic theorists don't think of those as foundational, and many students come away from that fact thinking they aren't important. Go ask Don Knuth what he thinks about that view, though, and you'll learn what he thinks is important. They're not beautiful -- in fact, they're quite ugly -- but they are keys to writing good code. None of them can be learned from reading about the "programming-language-du-jour".
There's a name for an programmer who can't actually write code well: unemployed. The "foundation" of computer engineering is writing code, not designing code.
You can do real computer engineering even if you don't know the formal difference between O(n) and O(n^2). You can't do real computer engineering if you don't know the difference between throw and goto in a non-functional language.
No, you don't get it. Red Hat wants to be able to guarantee that you are actually running what you think you're running when you boot your system. You may think that there are no root kits for Linux, but, if you do, then you're wrong -- and the only way to protect a system against that is to implement a TCM at some level or another.
Why do you have a right to impose a confidentiality agreement on that information, though? You don't own it -- you've said so yourself. It belongs to the "community".
The instant you start talking about information you don't want to share, you need to ask if other entities might also have information which they legitimately don't want to share. If they do, then you have to ask if they have any rights to enforce those desires.
The worst part of the/. story is that it doesn't include the key fact in the IE blog: Microsoft found the bug during internal testing, validated that it couldn't be exploited, and therefore didn't choose to fix it for beta. That's the right decision to make -- it's a preview of a beta, after all! Unexploitable crashes are a non-issue in a beta.
I don't think so, but it's certainly a supportable claim.
Either way, the AC was going on about how only about 900K units had sold worldwide (up from his previous spam about the console not selling out in the US, which has been refuted a bunch of time). That's just not true.
Slashdot Mirror
Hmm...
Actually, the $100 computer would be utterly useless to the millions of poor people -- if it every appeared, which I doubt.
Gates is wrong, all the same. There's a much better reason to mock the $100 laptop: what the "$100 laptop" offers already available throughout the third world, and is, increasingly, being used by people in the third world for the same thing that we in the first world use our computers for: communication. Cheap cell phones are blooming throughout Africa and Asia.
The average cell phone is a pretty powerful computer. With a display. And an always-on wireless link. And a storage system. And a data-entry pad. And, and, and.
Gates' criticism is laughable -- there's a lot of use in a small screen, for instance -- but Negroponte's idea is stupid, too.
How can this be informative? It's simply, utterly, totally, wrong.
(a) IBM manufactures Cell for Sony. There's no second source at this time.
(b) The circuit boards have been outsourced to a Taiwanese OEM firm.
(c) The memory has been outsourced to another OEM.
etc. Sony does not have control over its prices yet, and probably never will, given the marginal difference in cost between Japanese and off-shore assembly.
No -- that's Napoleon you're quoting. The Art of War is about winning wars when you can't assume that your enemy will do anything stupid.
So, did anyone ever verify Gord's claims? I certainly never saw any evidence besides his screed and the interviews cited therein -- and I'm beginning to wonder if there was any. It's true that by the end, Sony was making money on the PS2 itself, but I don't think that Gord has his head on straight about the early days.
Either way, the PS3 is clearly going to lose money early on. The Cell chip itself costs enough ($237) at the current yields and sizes that a box containing it alone would need to cost $450 at retail for Sony to break even on it, and that's before things like memory, any disk player, or controller handling.
Excuse me. The correct term is "manipulated state pre-lived corpse" (MS PC). This is the origin of the term "Zombie PC".
In my experience, zombies care very little about much of anything except the frontal lobes of pre-zombies. I guess I've been associating with the wrong zombies.
No -- that's suspend to RAM, not suspend to disk. Suspend2 is the equivalent of Windows' "Hibernate".
Volume shadow storage is exactly this kind of incremental, real-time backup process. How does this differ technically from that? (Other than the fact that you can now dynamically back up your morning toast, which is useful if a slice goes up in flames...)
Yes. Stringer was talking about the Japanese release here, though -- so this is a six month slip.
That is exactly how this work. The reason it's so useful for a Windows box arises from one of the ways in which Windows makes interesting use of files on disk.
When a DLL is loaded into memory from disk, it's only relocated if there's already another DLL loaded in the same slot in virtual memory. If there's no conflict with the DLL, it's not relocated; code pages are read directly from disk and never written back. Instead, when they're swapped out (it the machine doesn't have enough RAM), the page is simply dropped into the big bucket; when it's needed again - say, because the component is loaded into another process space - it's reread from disk. The same situation obtains with "true" EXE's, except that it's slightly easier: since there's only one EXE in a given process space, no EXE's ever conflict with one another, and so they are always read, unaltered, from disk.
(If you write code for Windows, by the way, you should know that. One of the easiest ways to speed up the loading of a DLL is to rebase it on disk. There's a Windows executable called rebase.exe which rebases a DLL automatically.)
You can see why this makes a Flash-based code store compelling on a Windows system -- rebased DLLs and EXEs only change very rarely; system code, in particular, only changes when the component is updated. If this persistent store uses an MRU updating algorithm, then the code pages which are frequently used wind up in this cache, and whenever they are first loaded into process memory, they are available instantly.
This is nonsense. I just went to search.msn.com, and the top three are a pointer to the Mathworld, followed by two pointers to Wikipedia, the first being to Ramsey theory.
Caching the working set from a Windows app is a lot different from caching the heap. You can't cache the heap on a removable device without risking a bit of twitchery, but you absolutely *can* cache unrelocated program code, which saves you seek time on the hard disk.
Except that Microsoft's response to the EC's demands was exactly what you asked for: source code availability.
Firefox and Opera, baby. (And IE7, too). Tabs are the new blue.
Really? So, explain to me why throw should be avoided in all procedural languages except Scheme, and then in all cases except one, and why goto should be preferred. Explain to me why forward goto is to be preferred in all cases when you are writing against one code generator, but not against another. Those are facts which are every bit as critical to good code as whether you use bubble sort or heap sort. (In the light of which, did you know that there are extremely important cases where bubble sort is actually faster than heap sort, O(n^2) in worst case or not?) Academic theorists don't think of those as foundational, and many students come away from that fact thinking they aren't important. Go ask Don Knuth what he thinks about that view, though, and you'll learn what he thinks is important. They're not beautiful -- in fact, they're quite ugly -- but they are keys to writing good code. None of them can be learned from reading about the "programming-language-du-jour".
There's a name for an programmer who can't actually write code well: unemployed. The "foundation" of computer engineering is writing code, not designing code. You can do real computer engineering even if you don't know the formal difference between O(n) and O(n^2). You can't do real computer engineering if you don't know the difference between throw and goto in a non-functional language.
No, you don't get it. Red Hat wants to be able to guarantee that you are actually running what you think you're running when you boot your system. You may think that there are no root kits for Linux, but, if you do, then you're wrong -- and the only way to protect a system against that is to implement a TCM at some level or another.
Why do you have a right to impose a confidentiality agreement on that information, though? You don't own it -- you've said so yourself. It belongs to the "community". The instant you start talking about information you don't want to share, you need to ask if other entities might also have information which they legitimately don't want to share. If they do, then you have to ask if they have any rights to enforce those desires.
The worst part of the /. story is that it doesn't include the key fact in the IE blog: Microsoft found the bug during internal testing, validated that it couldn't be exploited, and therefore didn't choose to fix it for beta. That's the right decision to make -- it's a preview of a beta, after all! Unexploitable crashes are a non-issue in a beta.
Did you say that about Google's hiring of Kai-Fu Lee? If not, then you're being hypocritical.
Nope -- they're legally required to display slow-moving vehicle signs, but all three are perfectly legal off of limited access highways.
I don't think so, but it's certainly a supportable claim. Either way, the AC was going on about how only about 900K units had sold worldwide (up from his previous spam about the console not selling out in the US, which has been refuted a bunch of time). That's just not true.