The linux kernel does very little interpretation of remotely-provided data. There are occasionally remote exploits (e.g. the Ping of Death in '97 or so), but that code has now been pretty thoroughly checked at this point. Most of the code which cares at all about the validity of data is interfaces only accessible locally.
As usual, there's nothing new about these chips, nor do they have anything to do with DRM. What they have is support for storing keys such that they can be used but not read. There's nothing stopping people from installing their own keys and using those instead. Of course, this could cut you off from the network the device was for, but that's no different from removing and throwing away the PIM for your cell phone. This isn't any different from every single cell phone ever shipped. Or, for that matter, most consumer devices these days, which have microcontroller which are either not set up for reprogramming or only accept signed firmware.
For that matter, this chip doesn't have exclusively internal program memory, meaning that, while you can't get the keys out of a chip, with modifications to the rest of the chipset, you can trick the processor into using the keys for you however you want.
As for installing Linux on one of these systems, the FA (last link) actually lists Linux 2.6.7 as the first choice for "Supported OS".
That's not as bad as TiVoToGo being #4, despite having already been released only a few days outside the specified window. And the X800 got #5 despite being scheduled to be in transit at press time and having previously available to reviewers.
At 3 GHz, light travels 4 inches in a clock cycle. If you have a 2 inch processor, including the delay due to not using light in a vacuum, you simply can't have clock synchronization throughout the chip. That doesn't mean that processors can't go faster, but, when they do go faster, there won't be a single clock whose speed you can report.
There's also less room to increase transistor count in this direction. If, in ten years, they made processors 200 times bigger than they do today, they'd be bigger than laptops and pretty useless. Additionally, they would take 200 times as much power and produce 200 times as much heat if no other major change happened as well. It's basically just not worth bothering with size when there's not all that much to get out of it (Aside from the other issues with making a chip longer than 1/(6 GHz) on a side).
Essentially, everything behaves like viruses in the game, but people didn't realize this in advance. It makes sense that when you import a house, the things in it come along, but people didn't realize that a number of game mechanics were treated as things in houses. People also didn't realize that, if you modified "the espresso machine", the change would apply not just to one item, but to all items like that one, so importing the house with the weird espresso machine imports and applies the weirdness to your espresso machines, which you then pass on when you export your house.
FBI analysts report that it was taken on top of a hill, with a snow-capped mountain not far away. Martial artists are reportedly searching hilly areas in sight of the Rockies for foreboding castles.
The response to such papers really ought to be: "You have a good shorthand, but you need to write everything out when you're turning something in."
The people who write most quickly and with most accuracy are stenographers, who write in something most of us couldn't puzzle out at all. But they then type things up in plain english with standard orthography for the court records. You'll do best at getting people to write in a situation-appropriate way if you recognize the merits of what they're doing when pointing out the unsuitability.
On the other hand, there's plenty of bad writing that's in perfect English and is simply unclear, disorganized, or misleading. I've read perfectly comprehensible text in badly mangled English as well as fluent English which completely failed to convey the author's intended meaning.
There's also a substantial factor of systems being willing to handle incorrect but consistent data. I have an old program which isn't really Y2K compliant, but was reliable in '99 and is still reliable in '105. Sure, you have to type three digits for "YY", but nothing actually breaks anywhere.
There's something to be said for taking email from 100, 1900, 2000, 19100, and so forth, and saying "it's new, because the user hasn't read it, whatever it says."
That interface sounds a lot like Emacs *shell* mode. Personally, I never liked it much, because it doesn't give you a good view of what's actually happened; history is, in fact, static and linear, and an editor doesn't give you a good representation of it.
It would be nice to have the output of a particular command automatically captured for replay (although only for commands that don't do interactive things; the output of "less" would be totally useless afterwards).
I disagree about scripting, because exactly what features people use interactively varies. People who are really comfortable with the language will actually write loops on the command line on occasion when they want to do something to a bunch of files.
On the other hand, years of thought and discussion don't help at all without a certain amount of experience trying to implement the project. You don't find out until you try to write the code what exactly the issues that you're trying to plan to avoid are. If you try to plan before coding at all, you come up with something like EJB, which very elegantly solves problems which don't exist, and doesn't work for reasons that don't impact theory.
The most reliable approach, in my opinion, is to start coding without any planning at all. It won't work, but when you then go into the planning phase, you'll have some clue as to what the pitfalls are that you have to avoid (as well as what things turn out not to be a problem). Then you can write a version that actually works somewhat. There will be new problems and things you didn't get to trying in the first failed attempt, so you'll need a redesign. After a few iterations, you'll have something that's simple and solid.
My personal bias is that you should assume that your project is going to fail and have a lot of scavengable parts, such that your future projects will have a high chance of success (or, at least, start out further ahead).
Insulation isn't adhesive. The problem wasn't with the foam, which performed perfectly well at its function, but with the attachment of the foam to the tank. Obviously, the answer is to attach the same foam better.
I mean, they could replace the foam with ceramic tiles, but that wouldn't actually address the problem of insulation falling off at all.
Having a $35B market doesn't mean that something is mainstream then, beforehand, or whatever. On the other hand, research which would lead an IDC analyst to think that Linux will be a $35B market in 3 years also implies that it is mainstream now. IDC is looking at stuff like long-term corporate purchasing plans. This tells them that a lot of money is likely to be spent on Linux in 2008, and that a lot of long-term plans today include Linux as a future direction.
What's really remarkable about Linus's place in the list is that he doesn't actually have any employees. He doesn't control any finances. He doesn't even influence the people who control the pay of the people he manages. He's such a good manager that people accept his management for no reason other than that it is good. It's quite remarkable that he can actually do this, and also that a business magazine recognizes that this is going on.
A bet Linus could have a great time going to classes in an MBA program and heckling the instructors.
It wouldn't actually be too surprising if the "model" were actually determined in testing rather than in production. Around the 486 at least, Intel was selling theoretically identical chips as different speeds depending on how fast they stayed reliable. Of course, once you've gotten to this stage, there's relatively little you can do to make the info permanent.
Processor time, which is what supercomputer time would be useful for, is completely trivial these days. You can order a processor that's completely sufficient for all people's non-gaming needs for $28.64 (quantity of 1) from digikey. You need more elaborate chips to manage your network connection than you do to run your software.
The important features of a computer these days are fixed storage you control, places to plug in devices, removable media, display, and a small amount of low-latency processor power. A network-accessed supercomputer is completely useless and an operating system is necessary.
Personally, I think there is going to be a market for network-attached storage for consumers (there's a computer in every room of the house. Wouldn't you like them to all share the same document storage?). But everything else sensibly belongs in the computer.
The problem with the current system is that precedent is given exclusively to the most recent edit, rather than any other qualification of a particular edition of an article. The history is available, but there is no way to look at, for example, what editors read over the page and agreed with it, or to browse the latest edition of a page which has been checked by a member of an editorial board you happen to trust.
There's no reason to need a team of professionals for all articles, or even to have a team of professionals be treated specially by the system, but recognizing the existance of qualified authors and their contributions when they do exist would go a long way to improving the result. (For example, revert wars just wouldn't happen, because each side, having written their version, would then have to compete on reputation with the other side or the other version, rather than simply submitting their changes frequently).
If you skip the misleading portions of the article, you'll find that the only new thing here is using a maritime satellite for the connection. They're already putting EMTs in direct contact with doctors at the hospital they're going to and sending data from the ambulance to the hospital. The problem is that they go through places without cell reception and where point-to-point links are blocked by terrain.
Re:Speaking of people understanding
on
100 Years of Einstein
·
· Score: 2, Insightful
It doesn't take much math to understand what he's saying. To work out the consequences, on the other hand, can take a lot. (But something like the view of magnetism as a consequence of special relativity applied to electricity only takes about half a term of calculus beyond the Calc BC AP exam; MIT has a first-term physics course which covers it).
In fact, Feynmann's QED (Quantum ElectroDynamics) doesn't require any tricky math to explain Einstein's more counterintuitive stuff.
I multitask constantly, switching between doing direct work (i.e., actually writing code) consciously and doing other things, such as checking email, reading slashdot, etc., depending on whether I have the answers to my work problems yet. I actually find that not switching away from work every few minutes degrades my ability to work; I get writer's block. But I don't permit interruptions. Email will get read the next time I'm not in the middle of something. I'm actually fine with being interrupted, if it's something that's more important than what I'm doing and will take a long time, because that means that I change my primary task. But anything not important doesn't get my attention until I'm ready to relax my focus.
Academic institutions, recognizing their value, will keep their subscriptions even though they aren't actually necessary for access to the articles. For that matter, NIH could give grants to respected journals for finding good articles. I bet, in fact, that academic institutions would agree to keep their subscriptions as a prerequisite to being able to submit articles regularly (which is to say that the journal may publish submissions from non-subscibers if they seem likely to support the journal's reputation and an editor happens to read it, but they'll be sure to look at any submission from a subscriber while still only publishing it if it seems good).
In general, if the thing that people get when they pay (articles) isn't the same as the value the people they pay add (review), it's possible to change the business model, because there's nothing inherently right about the current model.
There's nothing wrong with XML for a small amount of structured data, provided people use a sane DTD style (none of this "three tags to specify one attribute" junk). Of course, a sensible diffutils for XML is still needed.
In fact, installing everything in/opt/packagename-version and making symlinks works perfectly (except that ldconfig doesn't care for the symlinks, but that turns out not to be a big deal). It would be nice if your average installer would add the symlinks automatically (with a suitable option:./configure --link-prefix=/usr/local --prefix=/opt/%)
For that matter "--link-prefix=~ --prefix=~/opt/~", with ~/bin in $PATH and ~/lib in $LD_LIBRARY_PATH (etc) ought to let people trivially install things for their own use without root.
The linux kernel does very little interpretation of remotely-provided data. There are occasionally remote exploits (e.g. the Ping of Death in '97 or so), but that code has now been pretty thoroughly checked at this point. Most of the code which cares at all about the validity of data is interfaces only accessible locally.
As usual, there's nothing new about these chips, nor do they have anything to do with DRM. What they have is support for storing keys such that they can be used but not read. There's nothing stopping people from installing their own keys and using those instead. Of course, this could cut you off from the network the device was for, but that's no different from removing and throwing away the PIM for your cell phone. This isn't any different from every single cell phone ever shipped. Or, for that matter, most consumer devices these days, which have microcontroller which are either not set up for reprogramming or only accept signed firmware.
For that matter, this chip doesn't have exclusively internal program memory, meaning that, while you can't get the keys out of a chip, with modifications to the rest of the chipset, you can trick the processor into using the keys for you however you want.
As for installing Linux on one of these systems, the FA (last link) actually lists Linux 2.6.7 as the first choice for "Supported OS".
That's not as bad as TiVoToGo being #4, despite having already been released only a few days outside the specified window. And the X800 got #5 despite being scheduled to be in transit at press time and having previously available to reviewers.
At 3 GHz, light travels 4 inches in a clock cycle. If you have a 2 inch processor, including the delay due to not using light in a vacuum, you simply can't have clock synchronization throughout the chip. That doesn't mean that processors can't go faster, but, when they do go faster, there won't be a single clock whose speed you can report.
There's also less room to increase transistor count in this direction. If, in ten years, they made processors 200 times bigger than they do today, they'd be bigger than laptops and pretty useless. Additionally, they would take 200 times as much power and produce 200 times as much heat if no other major change happened as well. It's basically just not worth bothering with size when there's not all that much to get out of it (Aside from the other issues with making a chip longer than 1/(6 GHz) on a side).
Essentially, everything behaves like viruses in the game, but people didn't realize this in advance. It makes sense that when you import a house, the things in it come along, but people didn't realize that a number of game mechanics were treated as things in houses. People also didn't realize that, if you modified "the espresso machine", the change would apply not just to one item, but to all items like that one, so importing the house with the weird espresso machine imports and applies the weirdness to your espresso machines, which you then pass on when you export your house.
If you'd ever seen any burning "protected" DTV broadcasts, you'd be eager to have this safeguard. Those things can be really nasty.
FBI analysts report that it was taken on top of a hill, with a snow-capped mountain not far away. Martial artists are reportedly searching hilly areas in sight of the Rockies for foreboding castles.
The response to such papers really ought to be: "You have a good shorthand, but you need to write everything out when you're turning something in."
The people who write most quickly and with most accuracy are stenographers, who write in something most of us couldn't puzzle out at all. But they then type things up in plain english with standard orthography for the court records. You'll do best at getting people to write in a situation-appropriate way if you recognize the merits of what they're doing when pointing out the unsuitability.
On the other hand, there's plenty of bad writing that's in perfect English and is simply unclear, disorganized, or misleading. I've read perfectly comprehensible text in badly mangled English as well as fluent English which completely failed to convey the author's intended meaning.
There's also a substantial factor of systems being willing to handle incorrect but consistent data. I have an old program which isn't really Y2K compliant, but was reliable in '99 and is still reliable in '105. Sure, you have to type three digits for "YY", but nothing actually breaks anywhere.
There's something to be said for taking email from 100, 1900, 2000, 19100, and so forth, and saying "it's new, because the user hasn't read it, whatever it says."
That interface sounds a lot like Emacs *shell* mode.
Personally, I never liked it much, because it doesn't give you a good view of what's actually happened; history is, in fact, static and linear, and an editor doesn't give you a good representation of it.
It would be nice to have the output of a particular command automatically captured for replay (although only for commands that don't do interactive things; the output of "less" would be totally useless afterwards).
I disagree about scripting, because exactly what features people use interactively varies. People who are really comfortable with the language will actually write loops on the command line on occasion when they want to do something to a bunch of files.
On the other hand, years of thought and discussion don't help at all without a certain amount of experience trying to implement the project. You don't find out until you try to write the code what exactly the issues that you're trying to plan to avoid are. If you try to plan before coding at all, you come up with something like EJB, which very elegantly solves problems which don't exist, and doesn't work for reasons that don't impact theory.
The most reliable approach, in my opinion, is to start coding without any planning at all. It won't work, but when you then go into the planning phase, you'll have some clue as to what the pitfalls are that you have to avoid (as well as what things turn out not to be a problem). Then you can write a version that actually works somewhat. There will be new problems and things you didn't get to trying in the first failed attempt, so you'll need a redesign. After a few iterations, you'll have something that's simple and solid.
My personal bias is that you should assume that your project is going to fail and have a lot of scavengable parts, such that your future projects will have a high chance of success (or, at least, start out further ahead).
Insulation isn't adhesive. The problem wasn't with the foam, which performed perfectly well at its function, but with the attachment of the foam to the tank. Obviously, the answer is to attach the same foam better.
I mean, they could replace the foam with ceramic tiles, but that wouldn't actually address the problem of insulation falling off at all.
Having a $35B market doesn't mean that something is mainstream then, beforehand, or whatever. On the other hand, research which would lead an IDC analyst to think that Linux will be a $35B market in 3 years also implies that it is mainstream now. IDC is looking at stuff like long-term corporate purchasing plans. This tells them that a lot of money is likely to be spent on Linux in 2008, and that a lot of long-term plans today include Linux as a future direction.
What's really remarkable about Linus's place in the list is that he doesn't actually have any employees. He doesn't control any finances. He doesn't even influence the people who control the pay of the people he manages. He's such a good manager that people accept his management for no reason other than that it is good. It's quite remarkable that he can actually do this, and also that a business magazine recognizes that this is going on.
A bet Linus could have a great time going to classes in an MBA program and heckling the instructors.
It wouldn't actually be too surprising if the "model" were actually determined in testing rather than in production. Around the 486 at least, Intel was selling theoretically identical chips as different speeds depending on how fast they stayed reliable. Of course, once you've gotten to this stage, there's relatively little you can do to make the info permanent.
Processor time, which is what supercomputer time would be useful for, is completely trivial these days. You can order a processor that's completely sufficient for all people's non-gaming needs for $28.64 (quantity of 1) from digikey. You need more elaborate chips to manage your network connection than you do to run your software.
The important features of a computer these days are fixed storage you control, places to plug in devices, removable media, display, and a small amount of low-latency processor power. A network-accessed supercomputer is completely useless and an operating system is necessary.
Personally, I think there is going to be a market for network-attached storage for consumers (there's a computer in every room of the house. Wouldn't you like them to all share the same document storage?). But everything else sensibly belongs in the computer.
The problem with the current system is that precedent is given exclusively to the most recent edit, rather than any other qualification of a particular edition of an article. The history is available, but there is no way to look at, for example, what editors read over the page and agreed with it, or to browse the latest edition of a page which has been checked by a member of an editorial board you happen to trust.
There's no reason to need a team of professionals for all articles, or even to have a team of professionals be treated specially by the system, but recognizing the existance of qualified authors and their contributions when they do exist would go a long way to improving the result. (For example, revert wars just wouldn't happen, because each side, having written their version, would then have to compete on reputation with the other side or the other version, rather than simply submitting their changes frequently).
If you skip the misleading portions of the article, you'll find that the only new thing here is using a maritime satellite for the connection. They're already putting EMTs in direct contact with doctors at the hospital they're going to and sending data from the ambulance to the hospital. The problem is that they go through places without cell reception and where point-to-point links are blocked by terrain.
It doesn't take much math to understand what he's saying. To work out the consequences, on the other hand, can take a lot. (But something like the view of magnetism as a consequence of special relativity applied to electricity only takes about half a term of calculus beyond the Calc BC AP exam; MIT has a first-term physics course which covers it).
In fact, Feynmann's QED (Quantum ElectroDynamics) doesn't require any tricky math to explain Einstein's more counterintuitive stuff.
I multitask constantly, switching between doing direct work (i.e., actually writing code) consciously and doing other things, such as checking email, reading slashdot, etc., depending on whether I have the answers to my work problems yet. I actually find that not switching away from work every few minutes degrades my ability to work; I get writer's block. But I don't permit interruptions. Email will get read the next time I'm not in the middle of something. I'm actually fine with being interrupted, if it's something that's more important than what I'm doing and will take a long time, because that means that I change my primary task. But anything not important doesn't get my attention until I'm ready to relax my focus.
Baryons are a subclass of fermion.
Academic institutions, recognizing their value, will keep their subscriptions even though they aren't actually necessary for access to the articles. For that matter, NIH could give grants to respected journals for finding good articles. I bet, in fact, that academic institutions would agree to keep their subscriptions as a prerequisite to being able to submit articles regularly (which is to say that the journal may publish submissions from non-subscibers if they seem likely to support the journal's reputation and an editor happens to read it, but they'll be sure to look at any submission from a subscriber while still only publishing it if it seems good).
In general, if the thing that people get when they pay (articles) isn't the same as the value the people they pay add (review), it's possible to change the business model, because there's nothing inherently right about the current model.
There's nothing wrong with XML for a small amount of structured data, provided people use a sane DTD style (none of this "three tags to specify one attribute" junk). Of course, a sensible diffutils for XML is still needed.
In fact, installing everything in /opt/packagename-version and making symlinks works perfectly (except that ldconfig doesn't care for the symlinks, but that turns out not to be a big deal). It would be nice if your average installer would add the symlinks automatically (with a suitable option: ./configure --link-prefix=/usr/local --prefix=/opt/%)
For that matter "--link-prefix=~ --prefix=~/opt/~", with ~/bin in $PATH and ~/lib in $LD_LIBRARY_PATH (etc) ought to let people trivially install things for their own use without root.