In some cases, a digital signature (of the cryptographic kind, not the Slashdot ID kind) can be used as a legally-recognized signature. In some places. Not all places recognize such signatures, and not all places that do will recognize it for all types of contract. Your mileage WILL vary whether you like it or not.
Mostly because downloading a library, reading through the non-existent docs, examining code in order to write own docs coz nothing worth reading was supplied, fixing the inevitable off-by-one bug that only affects the case you're concerned with, realizing the implementation was never properly tested and has chronic robustness/security/performance issues, and then downloading another library where you will discover exactly the same problems, rinse, repeat, is always going to be slower than writing your own.
Hell, half the places I've worked get so stroppy over licenses that the meetings on whether it's acceptable to the politics of the project to use a given library take far longer than just writing my own sort, linked-list, stack, queue or whatever.
It used to be that, for DOS, there were more shareware change directory programs than anything else. This wasn't because people needed more change directory programs or that there was even a demand for change directory programs. It was precisely because there was NO demand that there was a glut, a paradox in the supply-and-demand model.
I saw some documentation for a program once. At least, I think I did. (Seriously, the only decent effort I've seen in software documentation was at Daresbury Laboratory in the UK. Since moving to the States, I've seen stuff that calls itself documentation but that is a blatant troll on the part of the author.)
The reason that PGCC compiled better code for the Pentiums than EGCS did, and why EGCS compiled better code for the Athlon than PGCC did, is that optimization is still a black art.
Similarly, if you want to compile a program "better", you run it through a source-to-source optimizer, then compile it in profile mode, then run it in typical usage, then compile it again with the profiler data. This is merely automated hand-optimizing, since you're still telling the code what is important and what isn't, overriding the compiler's built-in logic.
And there again, if you want it really fast, you do get in there and tighten the code further. Even with the profiling data, you still know more about the context the program will be used in than the compiler can ever know. (This is especially true of parallel programming, as compilers are just not capable of parallelizing code efficiently. Which is why you have hacks like OpenMP, to manually specify all the stuff that the compiler can't do.)
Hand-turning is fun, yes. I got all the floating-point variables crammed for a Mandelbrot generator crammed into the 80287 stack, which meant I didn't need to do painfully slow loads and saves of 80-bit data.
There is no practical difference between OO code and structured code. The article assumed structured code means goto and gosub, but any Real Programmer knows that procedures (which are just gosubs by name rather than address) are still structured programming.
So what's OO? Each class is just a bunch of functions and procedures, with one entry point and one exit point for each - your standard structured programming methodology. The fact that there are different classes makes no difference. Calls between classes don't change the nature of a class any more than pipes between programs change the nature of programs.
I wasn't impressed by other claims, either. Garbage collection is still a major headache in coding, which is why there are so many debugging mallocs and so many re-implementations of malloc() for specialist purposes. Memory leaks are still far, far too common - indeed they're probably the number 1 cause of crashes these days.
Pointer arithmetic? Still very very common. If you want to access data in an internal database quickly, you don't use SQL. You use a hash lookup and offset your pointer.
Sorts? Who the hell uses a sort library? Sort libraries are necessarily generic, but applications often need to be efficient. Particularly if they're real-time or HPC. Even mundane programmers would not dream of using a generic library that includes sorts they'll never refer to in, say, an e-mail client or a game. They'll write their own.
One of the reasons people will choose a malloc() like hoard, or an accelerated library like liboil is that the standard stuff is crappy for anything but doing standard stuff. This isn't the fault of the glibc folks, it's the fault of computers for not being infinitely fast and the fault of code not being absolutely identical between tasks.
The reason a lot of these rules were developed was that you needed to be able to write reusable code that also had a high degree of correctness. Today, you STILL need to be able to write reusable code that also has a high degree of correctness. If anything, the need for correctness has increased as security flaws become all the more easily exploited, and the need for reusability has increased as code bases are often just too large to be refactored on every version. (Reusability is just as important between versions as it is between programs - a thing coders often forget, forcing horrible API and ABI breakages.)
The reason that software today is really no better, stability-wise, than it was 15-30 years ago is that new coders think they can ignore the old lessons because they're "doing something different", only to learn later on that really they aren't.
Way back when, I would access the Naval Research Lab's websites for copies of OPIE (a one-time password suite), their IPSec code, their IPv6 code and their IPv4/IPv6 multiprotocol suite.
These days, they have some nice stuff in the areas of multicasting, wireless routing and network testing tools.
Even the DoD's Office of Information Security Research has done Open Source work before, publishing one of the early IPSec implementations publicly through MIT.
So other than the DoD finally putting onto a more official level a practice that has been commonplace for decades (the sharing of source under true open source licenses), what exactly is new here? That the politicians at the top of the food chain figured something out? That's just a freak event, a result of the statistical nature of quantum mechanics.
It's covered in physics, to the extent that photosynthesis and the photoelectric effect are used to demonstrate photons must have momentum. (The law of conservation of momentum requires that the momentum going in equals the momentum coming out, so if the electron has momentum, then the photon must also.)
If you use Coreboot (formerly known as LinuxBIOS), optimized kernel settings, optimized glibc settings, and stick to a lightweight window manager on X, you should get exactly what you're describing.
Anyone who understands physics knows that the boiling point of helium at one atmosphere is 4.2 kelvin, that aerospace specifications usually call for something that'll handle somewhere in the -90C to the -125C range, and that 4.2K is a good deal colder.
Anyone who understands maths can then deduce that being able to overclock - or even run - at 4.2K is better than is required. It doesn't matter if they dip the damn chip in helium or tomato ketchup. What matters is that it operates in the range required, which it evidently does.
No, overclocking is not generally done by the military or in civil aviation. Yawn. And what does that have to do with the price of turnips? What they need is chips that can take considerable stress, handle the heat ranges required, and preferably handle a decent amount of radiation. (10,000 Rads seems to be a common target.)
Heat range has been dealt with. Stress - well, the chip didn't shatter, despite what is presumably a fairly substantial heat gradient when overclocking to 7+ GHz. So it seems to do stress ok.
Radiation can't be gauged, but you can always slather the chip casing with lead.
Look, this isn't rocket science. Oh. Wait. Maybe it is. I don't recall anyone of your attitude at NASA when I worked there.
Well, it depends. One of the biggest problems on increasing performance has been heat extraction. In order to be able to reliably overclock to 7 GHz, they must have done some fantastic work on the layout and the heat transport. That, in turn, means the processor will be safer in "hot" environments (such as data centres), that it will likely be possible to go to a smaller die size (since die size is partially constrained by heat), that it may be able to run an improved version of Intel's "hyperthreading", and that it should be more robust under normal conditions.
Since layout is also critical for high-end usage (such as aerospace tolerances), there is the distinct possibility that AMD might be better-placed to sell their new CPU to industries that would not be able to run anything like that high-end for many years.
I consider it noteworthy that they found a vat of liquid nitrogen with sufficient capacity to think that it could trump any human being. Other than lawyers and politicians.
Because museums and culture ministers like something to brag about. So long as THEY treat it as a contest, they're going to submit material. The moment they see it as educational, well, that's the department of education, which is some other guy. Not their problem any more.
Slashdot Mirror
I dunno. It would be kind of handy to be able to @toad lawyer.
In some cases, a digital signature (of the cryptographic kind, not the Slashdot ID kind) can be used as a legally-recognized signature. In some places. Not all places recognize such signatures, and not all places that do will recognize it for all types of contract. Your mileage WILL vary whether you like it or not.
Mostly because downloading a library, reading through the non-existent docs, examining code in order to write own docs coz nothing worth reading was supplied, fixing the inevitable off-by-one bug that only affects the case you're concerned with, realizing the implementation was never properly tested and has chronic robustness/security/performance issues, and then downloading another library where you will discover exactly the same problems, rinse, repeat, is always going to be slower than writing your own.
Hell, half the places I've worked get so stroppy over licenses that the meetings on whether it's acceptable to the politics of the project to use a given library take far longer than just writing my own sort, linked-list, stack, queue or whatever.
It used to be that, for DOS, there were more shareware change directory programs than anything else. This wasn't because people needed more change directory programs or that there was even a demand for change directory programs. It was precisely because there was NO demand that there was a glut, a paradox in the supply-and-demand model.
I saw some documentation for a program once. At least, I think I did. (Seriously, the only decent effort I've seen in software documentation was at Daresbury Laboratory in the UK. Since moving to the States, I've seen stuff that calls itself documentation but that is a blatant troll on the part of the author.)
The reason that PGCC compiled better code for the Pentiums than EGCS did, and why EGCS compiled better code for the Athlon than PGCC did, is that optimization is still a black art.
Similarly, if you want to compile a program "better", you run it through a source-to-source optimizer, then compile it in profile mode, then run it in typical usage, then compile it again with the profiler data. This is merely automated hand-optimizing, since you're still telling the code what is important and what isn't, overriding the compiler's built-in logic.
And there again, if you want it really fast, you do get in there and tighten the code further. Even with the profiling data, you still know more about the context the program will be used in than the compiler can ever know. (This is especially true of parallel programming, as compilers are just not capable of parallelizing code efficiently. Which is why you have hacks like OpenMP, to manually specify all the stuff that the compiler can't do.)
Hand-turning is fun, yes. I got all the floating-point variables crammed for a Mandelbrot generator crammed into the 80287 stack, which meant I didn't need to do painfully slow loads and saves of 80-bit data.
There is no practical difference between OO code and structured code. The article assumed structured code means goto and gosub, but any Real Programmer knows that procedures (which are just gosubs by name rather than address) are still structured programming.
So what's OO? Each class is just a bunch of functions and procedures, with one entry point and one exit point for each - your standard structured programming methodology. The fact that there are different classes makes no difference. Calls between classes don't change the nature of a class any more than pipes between programs change the nature of programs.
I wasn't impressed by other claims, either. Garbage collection is still a major headache in coding, which is why there are so many debugging mallocs and so many re-implementations of malloc() for specialist purposes. Memory leaks are still far, far too common - indeed they're probably the number 1 cause of crashes these days.
Pointer arithmetic? Still very very common. If you want to access data in an internal database quickly, you don't use SQL. You use a hash lookup and offset your pointer.
Sorts? Who the hell uses a sort library? Sort libraries are necessarily generic, but applications often need to be efficient. Particularly if they're real-time or HPC. Even mundane programmers would not dream of using a generic library that includes sorts they'll never refer to in, say, an e-mail client or a game. They'll write their own.
One of the reasons people will choose a malloc() like hoard, or an accelerated library like liboil is that the standard stuff is crappy for anything but doing standard stuff. This isn't the fault of the glibc folks, it's the fault of computers for not being infinitely fast and the fault of code not being absolutely identical between tasks.
The reason a lot of these rules were developed was that you needed to be able to write reusable code that also had a high degree of correctness. Today, you STILL need to be able to write reusable code that also has a high degree of correctness. If anything, the need for correctness has increased as security flaws become all the more easily exploited, and the need for reusability has increased as code bases are often just too large to be refactored on every version. (Reusability is just as important between versions as it is between programs - a thing coders often forget, forcing horrible API and ABI breakages.)
The reason that software today is really no better, stability-wise, than it was 15-30 years ago is that new coders think they can ignore the old lessons because they're "doing something different", only to learn later on that really they aren't.
I dunno. More people seem to be interested when the guy has a magician's hat than a scientist's lab coat.
Yeah, but since the military have published (on about this scale) GPLed and BSDed source code for decades, was it news even then?
Way back when, I would access the Naval Research Lab's websites for copies of OPIE (a one-time password suite), their IPSec code, their IPv6 code and their IPv4/IPv6 multiprotocol suite.
These days, they have some nice stuff in the areas of multicasting, wireless routing and network testing tools.
Even the DoD's Office of Information Security Research has done Open Source work before, publishing one of the early IPSec implementations publicly through MIT.
So other than the DoD finally putting onto a more official level a practice that has been commonplace for decades (the sharing of source under true open source licenses), what exactly is new here? That the politicians at the top of the food chain figured something out? That's just a freak event, a result of the statistical nature of quantum mechanics.
I'm still not sure what there is here that wasn't covered by Einstein when the photoelectric effect was first described.
It's only actually dangerous in Sydney, where you have to wear special hats to stop the crows who also got that talk.
It's covered in physics, to the extent that photosynthesis and the photoelectric effect are used to demonstrate photons must have momentum. (The law of conservation of momentum requires that the momentum going in equals the momentum coming out, so if the electron has momentum, then the photon must also.)
Is that what the Government wants you to believe?
If the disk is holographic (as opposed to the data), doesn't that mean it's not actually there?
It'll never happen. Holograms are interference patterns, and it's illegal to interfere with a computer's operations.
Did you know, statistically it is possible that every molecule in your body will spontaneously relocate itself to the moon? This COULD happen!
Well, the rain in Spain falls mainly on the plain. So I'm guessing they've headed into the hills where it's dry enough for the bees.
It's being compared to Windows 7. Do you REALLY want screenshots, or painkillers?
If you use Coreboot (formerly known as LinuxBIOS), optimized kernel settings, optimized glibc settings, and stick to a lightweight window manager on X, you should get exactly what you're describing.
Well, the APNG (animated PNG) format never really went anywhere.
Anyone who understands physics knows that the boiling point of helium at one atmosphere is 4.2 kelvin, that aerospace specifications usually call for something that'll handle somewhere in the -90C to the -125C range, and that 4.2K is a good deal colder.
Anyone who understands maths can then deduce that being able to overclock - or even run - at 4.2K is better than is required. It doesn't matter if they dip the damn chip in helium or tomato ketchup. What matters is that it operates in the range required, which it evidently does.
No, overclocking is not generally done by the military or in civil aviation. Yawn. And what does that have to do with the price of turnips? What they need is chips that can take considerable stress, handle the heat ranges required, and preferably handle a decent amount of radiation. (10,000 Rads seems to be a common target.)
Heat range has been dealt with. Stress - well, the chip didn't shatter, despite what is presumably a fairly substantial heat gradient when overclocking to 7+ GHz. So it seems to do stress ok.
Radiation can't be gauged, but you can always slather the chip casing with lead.
Look, this isn't rocket science. Oh. Wait. Maybe it is. I don't recall anyone of your attitude at NASA when I worked there.
Well, it depends. One of the biggest problems on increasing performance has been heat extraction. In order to be able to reliably overclock to 7 GHz, they must have done some fantastic work on the layout and the heat transport. That, in turn, means the processor will be safer in "hot" environments (such as data centres), that it will likely be possible to go to a smaller die size (since die size is partially constrained by heat), that it may be able to run an improved version of Intel's "hyperthreading", and that it should be more robust under normal conditions.
Since layout is also critical for high-end usage (such as aerospace tolerances), there is the distinct possibility that AMD might be better-placed to sell their new CPU to industries that would not be able to run anything like that high-end for many years.
Yeah, but who trusts dhrystone benchmarks any more? I wanna see how the overclocked version does on LINPACK tests.
I consider it noteworthy that they found a vat of liquid nitrogen with sufficient capacity to think that it could trump any human being. Other than lawyers and politicians.
Because museums and culture ministers like something to brag about. So long as THEY treat it as a contest, they're going to submit material. The moment they see it as educational, well, that's the department of education, which is some other guy. Not their problem any more.