Longhorn will almost certainly be released late next year; Microsoft has shifted from delaying it to removing things. By next year, Longhorn will be almost identical to XP, and delaying it further would be pointless. Of course, everything originally billed as Longhorn will be later, and the release name won't be "Longhorn", but they'll retire the codename and start talking about a new one for the stuff they've been working on.
It's probably better to say that there's a 1 in 73000 chance that a big earthquake will hit on any particular day, not taking into account any information about the day. If we were to look back in 10000 years, we'd probably say that 50 big earthquakes happened there, following close to a Poisson distribution. Sure, 300 years is longer than average, but 11 of those 50 will probably be longer. Chances are there'll have been a period under 5 years and one over 780 years, too.
It's pretty clear from conservation of energy that earthquakes release some of the potential energy which has built up. What we don't know is how that energy changes over time and how much there is at any particular moment, so the "releasing stress" concept doesn't have any practical application: we know that the fault has less energy today than it did yesterday, but we don't know how much it had, and we won't know when it builds up to be more again.
But as a simple application of the theory, it's obvious that expecting big earthquakes to be periodic doesn't make sense; there could hardly be a fault that produces only really big earthquakes after pressure has built up for 200 years.
I doubt the open source community would, in general, particularly care about AIX or OS/2. Sun's released Solaris, and nobody seems to care particularly much aside from people who were already using it. Sun had to add a bunch of new features to Solaris 10 to get people to be at all curious. IBM's been working on new OS features, but they've been contributing them to Linux, not doing much with them in AIX. And OS/2 is almost gone at this point; their OS/2 support is primarily "we'll help you switch to Linux before we stop supporting OS/2 next year."
It's possible that they'll open-source both of them before too long, but more to console the remaining users than to help the open-source community.
So you've seen people running the PPC version of OS X on non-Apple hardware? This won't even be the first strong hardware tie-in by Apple.
Of course, the way they did that was to make OS X rely on features of the hardware that aren't available in commodity hardware. The PPC chip instead of the x86 was one thing, but not the only thing. The memory layout, the boot sequence, and so forth were all different; the mac had a custom motherboard and firmware, so it would be difficult if possible at all (without copyright violations) to produce a mac clone without licensing stuff from Apple (which they weren't willing to do).
Reportedly, however, their Intel machines will be PC clones, which I think is a big mistake. While the tie-in effect is the same, it's a lot more palateable to customers if the reason OS X doesn't run on a no-name PC is that the OS tries to do actual work with hardware that it doesn't have, rather than that it detects that the hardware isn't branded correctly and just refuses.
I can understand using off-the-shelf parts for the internal OS testing, and maybe even the developer kit, but the actual systems really ought to have some important difference from what other people do.
Note, on the other hand, that.03 is a significant effect if you've memorized 9.803 m/s^2. For that matter, things effectively weighing.3% more at the poles is responsible for sealevel at the poles being 21km closer to the center of the earth than it is on the equator.
It sounds like Jobs had the discipline to show up for classes he wasn't taking and do the work. It makes sense that he'd learn more than students who don't show up or do the work for classes they are taking. Registering for classes and getting grades is useful for keeping most people focused, but, if you're sufficiently motivated anyway, it's not worth it for the piece of paper. Depending on the field, access to facilities might be worthwhile, but that's not necessarily the case, either. Research groups can help a lot, but not all that much more than starting a little company.
I think the future is really parallelism from analysis, but languages still have to change such that programmers can actually specify what can be done in parallel without making the decision about whether it should be split or not. We need to work out the questions that compilers need programmer input on, and how to phrase these questions such that programmers can answer them reliably from their knowledge of the program.
I don't think that programmers will ever be able to identify 64 things that could be done at the same time. On the other hand, it is probably possible to specify interference throughout a program, and have the compiler deal with the threads per se. Programmers can't track lots of threads of execution, but they have a good idea of dependencies; compilers don't know the dependencies, but can track arbitrary quantities of threads. The solution is to get the information the programmer has to the compiler to assist it in its analysis.
Re:Question of Compatibility vs. Reliability
on
HTTP Request Smuggling
·
· Score: 4, Insightful
The actual issue is cases where someone makes sense of malformed input and then passes that input on to something else. The proper thing to do is always pass on correctly-formed input. If you get malformed input and interpret it somehow, you then need to pass on your interpretation, not the original. The guideline is to be permissive in what you accept and strict in what you transmit; when you're passing something on, you need to canonicalize it in transit.
A good example of this is how the legal system works. When a court makes a decision on the application of a law to an unclear situation, that becomes part of the case law, such that there is a consistent interpretation, rather than an ambiguous situation being interpreted randomly each time it occurs.
Actually, the two documents are actually almost identical. The difference is only one block in the whole file, which essentially acts as a selector for which of the two sets of content is displayed. MD5 (like most hash functions) works on fixed-size blocks smaller than the average file. To hash a complete file, you hash the first block, feed that into the hash with the second block, feed that into the hash with the third block, and so forth. So they have two files, and the first blocks are the same, the second blocks are different but hash the same, and the rest of the files are the same. Of course, the second blocks are junk, but the postscript is expecting a block-sized arbitrary value at that point anyway, so it doesn't matter that there's junk there.
So they are actually using a format that can contain an exact quantity of extraneous information that doesn't get rendered but entirely changes what does get rendered.
The same thing could be done with PDF or doc, and executables, but not anything compressed (it won't decompress at all if a block is changed) and not HTML without javascript (there's no way to test which block of junk is included and show different results based on that).
It's not particularly hard to get enough understanding of a programming language to follow a detailed bug report and determine that it's accurate and that the patched version doesn't do the same thing. It's a lot harder to actually write new code, and it's hard to identify problems, but it's pretty easy to tell if the code does what the bug report says it does.
The main advantage of Google Maps over MapQuest is that you can actually look over the route and get a reasonable idea of the area you'll be going through. Then, when you get diverted, you have a chance of getting back on track. You also have a better chance of recognizing the turns after looking at how the cross-streets are arranged.
It's not all that big a deal, actually. It's $100M over about 3 years. The FBI employs "15,904 Professional Support people", who presumably make at least $30K each year, for a low estimate on salary of $477M each year. Salary is generally considered to be a third of an employer's costs in employing someone (the rest being benefits, supporting equipment, office space, etc). So the human support staff cost at least $4.3B over the duration of this project. If the project had a 50-50 chance of success, and success would allow them to be 5% more efficient, it was a good bet to pay for itself over a period as long as it took to do.
Nobody really knows how to get projects to work out reliably, either in industry or in government. Consider how much money Microsoft has spent on things that aren't in Longhorn. Or how much Walmart spent unsuccessfully competing with NetFlix. Good practice is to make enough attempts at not too high a cost, relative to your operating budget, that you'll have a success that pays for all the failures. It's really the only way to be competitive, because a conservative plan with no projects that don't fail costs much more for the results (assuming that the project doesn't fail anyway).
Your company shouldn't be counted in this statistic, because this is looking at the change in the number of companies using or considering Linux; you're using it already and expanding your use isn't counted. I suspect that Linux in the US is closing in on the point where everyone has considered it and either formed a plan for switching things or decided not to switch anything. There's plenty more growth to go in companies expanding their Linux use, but that's a different metric.
Chances are the Intel macs will have Open Firmware instead of a PC-style BIOS. There's a lot more to the PC architecture than the processor, and the OS legitimately relies on all of it. You'll be able to use the CPU from your commodity PC hardware, but you won't get it to read your hard drive unless you have a motherboard with Apple's firmware, and it won't run at all unless there's physical RAM where the BIOS is on a PC.
It is common in the ARM world to have chips which combine an ARM core with other stuff; PortalPlayer could have hardware decoders or DSPs in there with the ARM7. They provide software for their chips to do audio stuff (i.e., most of the iPod functionality other than the interface), and it might take advantage of custom hardware, so it could be difficult to just switch processors. On the other hand, if Apple has completely CPU-based implementations of all the codecs they care about, they could easily switch to a different chip.
(IIRC, people have figured out how to program for the iPod, but haven't worked out how to play music at full speed on it, due to not knowing the interface to the DSP, which is what makes the Apple firmware work.)
The definition of the second is now based on the physical quantity that atomic clocks measure, so the clocks are, when functioning properly, correct by definition. They can therefore just look at how much agreement a bunch of clocks have with each other. That is, they don't have to worry about the issue of all of the clocks being systematically fast or slow, like if they were mechanical watches which could all be consistant, but all tick at a rate different from a second, because the second is defined such that this is not the case.
x86 or even Intel chips doesn't imply an open architecture. There's a lot more to building a machine than the processor, and PPC processors are hardly less commodity than x86 ones. A machine with an x86_64 on a Mac-like motherboard is not all that implausible. On the other hand, it's much more likely that Apple would switch the processors in the iPod from PortalPlayer-supplied ARM7s to Intel ones.
There's no reason that consoles couldn't get normal keyboards and mice, some custom combination (designed to balance in a lap better), or even a special key arrangement for gaming.
Cache-Control only works on a per-request basis, and Last-Modified only works if you decide to check again. They're designed for clients like web browsers, where you only care about whether there have been changes when the user is checking on the site; they're not good for trying to schedule spidering, because many things specify "no-cache" (if the user wants to look at the page, just get a new one) and doing HEAD requests on the whole web for the Last-Modified dates is going to be slow.
Isn't the logical conclusion that the other students were unable to perform well on tests because doing homework trained them in ways that didn't work for tests. On the other hand, the question remains as to whether tests actually reflect a working knowledge of particular subjects better than homework; probably there are some subjects of each sort.
It is certainly possible that what is necessary in order to do well on tests is confidence going into the test and confidence when the material is presented, in which case the other students working to solve homework problems could have been the reason they did worse than you.
A mistake that many people, including this commissioner, make when thinking about open source development is to think that creating a commercial software product is essentially creating some software and then getting paid. In fact, there is a huge amount of work and even more risk in getting it from the point where it is a perfect piece of software to the point where you have money.
Marketting, sales, accounting, payroll, tech support, and business administration are all full-time jobs that developers don't want to do, and all of them would be necessary to have a successful commercial product. Open-source developers could do all this extra work, and would either get some money or lose some money. But they could also paint houses if they wanted more money, and it would be more fun, and a less risky and faster source of income.
It's autumn in Massachusetts but summer everywhere else (the screenshot is clearly from last week). New Jersey's looked like that since they finished paving it. Indiana, however, is just odd.
(The image data that Google is currently using in this and Maps is composed of the best images they could find from old data for each location, and these don't necessarily match in features like time of year, time of day, and weather; however, Indiana only seems to be grey in this screenshot, not in the data on Maps)
Most likely, there is some other factor which is preventing the exploit from working. So the vulnerability is actually exploiting some bug, but then some other check prevents anything untoward from happening. Ideally, there would be some way of checking the integrity of a process or of the system, which would identify after the fact that an exploit violated the security model in some way that had little effect (e.g., a function returned to an unmapped address, indicating a stack attack failure due to randomized memory arrangement).
In most cases, anyway, a partial exploit leads to a child process segfaulting rather than exiting normally, which is a pretty good test; it indicates something's wrong, even if it doesn't matter for some other reason. (And it's always possible that there could be a way around the check that caught the first try)
It would also be nice if there was a kernel memory location for proof-of-concept exploits to write, and a root-only syscall to write it. That way, you could have a simple demonstration that an attack got to write kernel memory or got root, without needing to determine what the exploit does, how to verify that it needs to work to do it, and how to clean up after it to try again.
Installing Linux on a laptop is just as easy as installing it on a desktop. The question is whether it will work when you're done, or whether the hardware won't be supported. But that's not something that's affected by how much work you put into installing it; it's a matter of whether you got a machine with the right parts. I think what HP is doing is actually ideal: they're marketting machines as having hardware that works perfectly when you install Ubuntu (from their CD; I'm not sure if they've added stuff or if it's an unmodified release). It says good things about the Linux support of the machine (and the future maintainability) if they feel comfortable that end users can install and don't need to jump through confusing hoops; if I decide to install a different distribution or a new version in a couple of years, it's much better if I don't have to figure out how they got things to work back then.
Slashdot Mirror
Longhorn will almost certainly be released late next year; Microsoft has shifted from delaying it to removing things. By next year, Longhorn will be almost identical to XP, and delaying it further would be pointless. Of course, everything originally billed as Longhorn will be later, and the release name won't be "Longhorn", but they'll retire the codename and start talking about a new one for the stuff they've been working on.
It's probably better to say that there's a 1 in 73000 chance that a big earthquake will hit on any particular day, not taking into account any information about the day. If we were to look back in 10000 years, we'd probably say that 50 big earthquakes happened there, following close to a Poisson distribution. Sure, 300 years is longer than average, but 11 of those 50 will probably be longer. Chances are there'll have been a period under 5 years and one over 780 years, too.
It's pretty clear from conservation of energy that earthquakes release some of the potential energy which has built up. What we don't know is how that energy changes over time and how much there is at any particular moment, so the "releasing stress" concept doesn't have any practical application: we know that the fault has less energy today than it did yesterday, but we don't know how much it had, and we won't know when it builds up to be more again.
But as a simple application of the theory, it's obvious that expecting big earthquakes to be periodic doesn't make sense; there could hardly be a fault that produces only really big earthquakes after pressure has built up for 200 years.
I doubt the open source community would, in general, particularly care about AIX or OS/2. Sun's released Solaris, and nobody seems to care particularly much aside from people who were already using it. Sun had to add a bunch of new features to Solaris 10 to get people to be at all curious. IBM's been working on new OS features, but they've been contributing them to Linux, not doing much with them in AIX. And OS/2 is almost gone at this point; their OS/2 support is primarily "we'll help you switch to Linux before we stop supporting OS/2 next year."
It's possible that they'll open-source both of them before too long, but more to console the remaining users than to help the open-source community.
So you've seen people running the PPC version of OS X on non-Apple hardware? This won't even be the first strong hardware tie-in by Apple.
Of course, the way they did that was to make OS X rely on features of the hardware that aren't available in commodity hardware. The PPC chip instead of the x86 was one thing, but not the only thing. The memory layout, the boot sequence, and so forth were all different; the mac had a custom motherboard and firmware, so it would be difficult if possible at all (without copyright violations) to produce a mac clone without licensing stuff from Apple (which they weren't willing to do).
Reportedly, however, their Intel machines will be PC clones, which I think is a big mistake. While the tie-in effect is the same, it's a lot more palateable to customers if the reason OS X doesn't run on a no-name PC is that the OS tries to do actual work with hardware that it doesn't have, rather than that it detects that the hardware isn't branded correctly and just refuses.
I can understand using off-the-shelf parts for the internal OS testing, and maybe even the developer kit, but the actual systems really ought to have some important difference from what other people do.
Note, on the other hand, that .03 is a significant effect if you've memorized 9.803 m/s^2. For that matter, things effectively weighing .3% more at the poles is responsible for sealevel at the poles being 21km closer to the center of the earth than it is on the equator.
It sounds like Jobs had the discipline to show up for classes he wasn't taking and do the work. It makes sense that he'd learn more than students who don't show up or do the work for classes they are taking. Registering for classes and getting grades is useful for keeping most people focused, but, if you're sufficiently motivated anyway, it's not worth it for the piece of paper. Depending on the field, access to facilities might be worthwhile, but that's not necessarily the case, either. Research groups can help a lot, but not all that much more than starting a little company.
I think the future is really parallelism from analysis, but languages still have to change such that programmers can actually specify what can be done in parallel without making the decision about whether it should be split or not. We need to work out the questions that compilers need programmer input on, and how to phrase these questions such that programmers can answer them reliably from their knowledge of the program.
I don't think that programmers will ever be able to identify 64 things that could be done at the same time. On the other hand, it is probably possible to specify interference throughout a program, and have the compiler deal with the threads per se. Programmers can't track lots of threads of execution, but they have a good idea of dependencies; compilers don't know the dependencies, but can track arbitrary quantities of threads. The solution is to get the information the programmer has to the compiler to assist it in its analysis.
The actual issue is cases where someone makes sense of malformed input and then passes that input on to something else. The proper thing to do is always pass on correctly-formed input. If you get malformed input and interpret it somehow, you then need to pass on your interpretation, not the original. The guideline is to be permissive in what you accept and strict in what you transmit; when you're passing something on, you need to canonicalize it in transit.
A good example of this is how the legal system works. When a court makes a decision on the application of a law to an unclear situation, that becomes part of the case law, such that there is a consistent interpretation, rather than an ambiguous situation being interpreted randomly each time it occurs.
Actually, the two documents are actually almost identical. The difference is only one block in the whole file, which essentially acts as a selector for which of the two sets of content is displayed. MD5 (like most hash functions) works on fixed-size blocks smaller than the average file. To hash a complete file, you hash the first block, feed that into the hash with the second block, feed that into the hash with the third block, and so forth. So they have two files, and the first blocks are the same, the second blocks are different but hash the same, and the rest of the files are the same. Of course, the second blocks are junk, but the postscript is expecting a block-sized arbitrary value at that point anyway, so it doesn't matter that there's junk there.
So they are actually using a format that can contain an exact quantity of extraneous information that doesn't get rendered but entirely changes what does get rendered.
The same thing could be done with PDF or doc, and executables, but not anything compressed (it won't decompress at all if a block is changed) and not HTML without javascript (there's no way to test which block of junk is included and show different results based on that).
It's not particularly hard to get enough understanding of a programming language to follow a detailed bug report and determine that it's accurate and that the patched version doesn't do the same thing. It's a lot harder to actually write new code, and it's hard to identify problems, but it's pretty easy to tell if the code does what the bug report says it does.
we don't sleep around
But we may not parenthesize "don't sleep around" the way everyone expects...
The main advantage of Google Maps over MapQuest is that you can actually look over the route and get a reasonable idea of the area you'll be going through. Then, when you get diverted, you have a chance of getting back on track. You also have a better chance of recognizing the turns after looking at how the cross-streets are arranged.
It's not all that big a deal, actually. It's $100M over about 3 years. The FBI employs "15,904 Professional Support people", who presumably make at least $30K each year, for a low estimate on salary of $477M each year. Salary is generally considered to be a third of an employer's costs in employing someone (the rest being benefits, supporting equipment, office space, etc). So the human support staff cost at least $4.3B over the duration of this project. If the project had a 50-50 chance of success, and success would allow them to be 5% more efficient, it was a good bet to pay for itself over a period as long as it took to do.
Nobody really knows how to get projects to work out reliably, either in industry or in government. Consider how much money Microsoft has spent on things that aren't in Longhorn. Or how much Walmart spent unsuccessfully competing with NetFlix. Good practice is to make enough attempts at not too high a cost, relative to your operating budget, that you'll have a success that pays for all the failures. It's really the only way to be competitive, because a conservative plan with no projects that don't fail costs much more for the results (assuming that the project doesn't fail anyway).
Your company shouldn't be counted in this statistic, because this is looking at the change in the number of companies using or considering Linux; you're using it already and expanding your use isn't counted. I suspect that Linux in the US is closing in on the point where everyone has considered it and either formed a plan for switching things or decided not to switch anything. There's plenty more growth to go in companies expanding their Linux use, but that's a different metric.
Chances are the Intel macs will have Open Firmware instead of a PC-style BIOS. There's a lot more to the PC architecture than the processor, and the OS legitimately relies on all of it. You'll be able to use the CPU from your commodity PC hardware, but you won't get it to read your hard drive unless you have a motherboard with Apple's firmware, and it won't run at all unless there's physical RAM where the BIOS is on a PC.
It is common in the ARM world to have chips which combine an ARM core with other stuff; PortalPlayer could have hardware decoders or DSPs in there with the ARM7. They provide software for their chips to do audio stuff (i.e., most of the iPod functionality other than the interface), and it might take advantage of custom hardware, so it could be difficult to just switch processors. On the other hand, if Apple has completely CPU-based implementations of all the codecs they care about, they could easily switch to a different chip.
(IIRC, people have figured out how to program for the iPod, but haven't worked out how to play music at full speed on it, due to not knowing the interface to the DSP, which is what makes the Apple firmware work.)
The definition of the second is now based on the physical quantity that atomic clocks measure, so the clocks are, when functioning properly, correct by definition. They can therefore just look at how much agreement a bunch of clocks have with each other. That is, they don't have to worry about the issue of all of the clocks being systematically fast or slow, like if they were mechanical watches which could all be consistant, but all tick at a rate different from a second, because the second is defined such that this is not the case.
x86 or even Intel chips doesn't imply an open architecture. There's a lot more to building a machine than the processor, and PPC processors are hardly less commodity than x86 ones. A machine with an x86_64 on a Mac-like motherboard is not all that implausible. On the other hand, it's much more likely that Apple would switch the processors in the iPod from PortalPlayer-supplied ARM7s to Intel ones.
There's no reason that consoles couldn't get normal keyboards and mice, some custom combination (designed to balance in a lap better), or even a special key arrangement for gaming.
Cache-Control only works on a per-request basis, and Last-Modified only works if you decide to check again. They're designed for clients like web browsers, where you only care about whether there have been changes when the user is checking on the site; they're not good for trying to schedule spidering, because many things specify "no-cache" (if the user wants to look at the page, just get a new one) and doing HEAD requests on the whole web for the Last-Modified dates is going to be slow.
Isn't the logical conclusion that the other students were unable to perform well on tests because doing homework trained them in ways that didn't work for tests. On the other hand, the question remains as to whether tests actually reflect a working knowledge of particular subjects better than homework; probably there are some subjects of each sort.
It is certainly possible that what is necessary in order to do well on tests is confidence going into the test and confidence when the material is presented, in which case the other students working to solve homework problems could have been the reason they did worse than you.
A mistake that many people, including this commissioner, make when thinking about open source development is to think that creating a commercial software product is essentially creating some software and then getting paid. In fact, there is a huge amount of work and even more risk in getting it from the point where it is a perfect piece of software to the point where you have money.
Marketting, sales, accounting, payroll, tech support, and business administration are all full-time jobs that developers don't want to do, and all of them would be necessary to have a successful commercial product. Open-source developers could do all this extra work, and would either get some money or lose some money. But they could also paint houses if they wanted more money, and it would be more fun, and a less risky and faster source of income.
It's autumn in Massachusetts but summer everywhere else (the screenshot is clearly from last week). New Jersey's looked like that since they finished paving it. Indiana, however, is just odd.
(The image data that Google is currently using in this and Maps is composed of the best images they could find from old data for each location, and these don't necessarily match in features like time of year, time of day, and weather; however, Indiana only seems to be grey in this screenshot, not in the data on Maps)
Most likely, there is some other factor which is preventing the exploit from working. So the vulnerability is actually exploiting some bug, but then some other check prevents anything untoward from happening. Ideally, there would be some way of checking the integrity of a process or of the system, which would identify after the fact that an exploit violated the security model in some way that had little effect (e.g., a function returned to an unmapped address, indicating a stack attack failure due to randomized memory arrangement).
In most cases, anyway, a partial exploit leads to a child process segfaulting rather than exiting normally, which is a pretty good test; it indicates something's wrong, even if it doesn't matter for some other reason. (And it's always possible that there could be a way around the check that caught the first try)
It would also be nice if there was a kernel memory location for proof-of-concept exploits to write, and a root-only syscall to write it. That way, you could have a simple demonstration that an attack got to write kernel memory or got root, without needing to determine what the exploit does, how to verify that it needs to work to do it, and how to clean up after it to try again.
Installing Linux on a laptop is just as easy as installing it on a desktop. The question is whether it will work when you're done, or whether the hardware won't be supported. But that's not something that's affected by how much work you put into installing it; it's a matter of whether you got a machine with the right parts. I think what HP is doing is actually ideal: they're marketting machines as having hardware that works perfectly when you install Ubuntu (from their CD; I'm not sure if they've added stuff or if it's an unmodified release). It says good things about the Linux support of the machine (and the future maintainability) if they feel comfortable that end users can install and don't need to jump through confusing hoops; if I decide to install a different distribution or a new version in a couple of years, it's much better if I don't have to figure out how they got things to work back then.