SafeStr is one of the technologies these guys have pointed out on their front page. Its just a string library with a number of interesting safety features. However, the fundamental architecture is completely broken:
1. Since the library automatically resizes its strings including the base pointer, that means if you have multiple refs of a string, then manipulations of one of them may leave others in an undefined state. For example:
safestr_t t; /*... */ s.name = t; safestr_append (t, SAFESTR_TEMP ("tail.")); /* Now, while t is well defined, s.name
may or may not be well defined. */
2. The use of SAFESTR_TEMP() (a string that automatically disappears after being passed to any safestr function) is clever but necessarily prevents any of the SafeStr functions from accepting const parameters. This has an additional problem that if you write a function which accepts a safestr_t, then if you pass it to one safestr function its reference might become undefined (you can't know.) For example:
int c3 (safestr_t s, safestr_t t, safestr_t u) {
safestr_append (s, t);/* s might now be undefined */
safestr_append (s, u);
return strlen (s); }
********
If you want to use an actually usefully architected string library try mine here:
http://bstring.sf.net/
In a direct comparison with safeStr, it should be pointed out that bstrlib doesn't have any concept of a "tainted" string. However, it does support read-only strings. bstrlib does not have any of the basic architectural weaknesses described above. It also has numerous other important features which are summarized here:
Comparing the hashes doesn't give you a definitive answer; it does, however, tell you where to look.
No. You do not understand. MD5 has a 128 bit output. 128 bits is a *LOT*. If you were to take every 3-line sequence of text written by every person ever in the history of man and compute the MD5 of each of them, the probability that *ANY* two have the same MD5 sum, but which are not the identical in the first place is vanishingly small.
If found any such collision, you could probably write a paper on it, and it would very readily be published in any crypto publication.
Python contains a built-in module for computing MD5. Assuming it uses a C-backend, then from my own testing, we know then that the program will become disk limited. There will be no significant difference between C or Python on disk limited activities.
Would these hashes of SCO source code be considered derivative works?
Its derivative, but is it work? I think this could easily be explained to the court. There is no expressive usable content in MD5 hashes and its not realistically reversable -- that's the whole point of it.
All kidding aside, at this point the most favorable outcome for SCO (whether they know it yet or not) would be for IBM to dig deeply enough to scare SCO into dropping the case and retiring to a quiet corner to expire without any of the principals doing time for fraud.
I believe that the SCO executives are not yet finished dumping all of their stock. So this is not yet the best outcome for "them".
Object code side with *NOT* be bigger -- it should be *SMALLER* if anything:
Pointers inside objects occupy run-time memory from the *HEAP* -- i.e., they don't have any presence in the object file.
The use of REX to access r8-r15 is the register based alternative to using a SIB byte, and offset for an [ebp+offset] encoding for directly accessing the stack. I.e., paying the cost of an extra prefix byte saves in both execution speed and actual code size versus the spill/fill style or direct stack based alternative.
Auto areas that are larger than 256 bytes because they are filled with a bazillion pointers are indicative of more serious program design flaws (that people don't generally have) than the statistical potential of loss from using far offset values from it. This is an extremely marginal case at best.
I don't understand your linkage complaint -- the more parameters passed in registers, the fewer that will end up on the stack.
Far and away your #1 bug is the infamous "buffer overrun" flaw. These usually mostly manifest themselves in string libraries. I know that you have at least 3 library solutions in-house (Safestr for C, CString in MFC, and basic_string in STL) but your developers don't use them otherwise these problems wouldn't happen.
I'd like to point you out to another alternative:
http://bstring.sf.net/
Which your developers may prefer. But whatever you do, why don't you simply make it a requirement that <string.h> simply be outlawed (you could easily write a tool to enforce that couldn't you?), or take some other drastic action?
Buffer overruns are certainly the most common kind of bug that isn't caught by QA (the right answer is not to try to train QA to find them -- they would require the skill of a hacker.) If you concentrate on this one bug alone, you will probably easily remove 80% of these attacks.
... honestly, AltiVec makes SSE2 and 3Dnow! look like toys by comparison.
That seems a little hard to believe considering that AltiVec can only perform 32 bit floating point (which is not valid for the LinPack test used in the top500 list) and SSE-2 can.
A couple of things make them suitable for clustering: * There's heaps of processor-processor bandwidth and memory bandwidth.
They use HyperTransport which was invented by AMD and used in Opertons.
* On board gigabit ethernet.
Huh? Such things exist in the x86 world as well.
* Monster fast execution of properly written vector code.
AltiVec cannot be used; it can only perform 32 bit floating point calculations which is not legal for the Linpack benchmark used at the top500 site. They have to stick to ordinary FP usage, where they will not have any advantage over Pentiums or Opterons.
* Well designed cooling.
Well designed in terms of what? They are *CLUSTERING* many machines. What matters is the *aggregated* cooling solution, not the cooling of any one single node. The Apple G5 has far more fans than your typical x86 box, which in the end just means more parts which can possibly fail, which becomes a noticable factor in clustering solutions.
Of course, the bang/buck ratio could be an issue for some debate but there's little doubt that in comparison to other commercial unices it's an absolute bargain.
Oh yeah -- they can't strike out the cost of buying a copy of MacOS for each machine, can they? At least with x86's they only need to buy or download one copy of Linux.
AltiVec would be illegal to use for the Linpack test. AMD/Kentucy tried this with 3DNow! in the KLAT2 machine several years ago but were rejected because the computation was not in 64 bits.
AltiVec cannot perform 64bit floating point computations, ergo, AltiVec will not be a factor.
That said, Opertons and Pentiums both have SSE-2 which *does* support 64bit floating point. Thus the question still remains -- why use G5's, when x86s are both cheaper *AND* faster?
Please stop spreading FUD. This is NOT old news. It's new. Apple updated their scores, and now there are production low end machines that have been tested.
The why do all the numbers look exactly the same as the original numbers posted? I followed the links in all directions and could not find new numbers anywhere. All the same old number, all the same old lies.
The usefulness of binary logic is not a relic. Its necessary. Software today heavily relies on the following:
1. Ordinary boolean logic: AND, OR, XOR, NOT. There is no simple way to implement these in bases other than bases which are powers of 2. You *CANNOT* get away with not implementing these in instructions sets. The silicon would be forced to emulate/implement these as some kind of ROM-table look up.
2. Integers being exact powers of 2 in size. There are many bit hacking tricks that "shift bits off the top" which will not work as expected. There is no way to fix this.
Note that an OR operation can actually lead to an OVERFLOW! There are numerous masking tricks that will fail because of this:
x = HIGH_BITS | y;
z = x & SOME_MID_TO_LOW_BITS;
Today's programmers assume that so long as HIGH_BITS and SOME_MID_TO_LOW_BITS don't intersect, then the two lines can be interchanged in order without effect. But because in base 3 the first line can overflow, there's no way to preseve this property.
I think of using ternary logic as kind of like trying to put square carpet in a pentagon shaped room. It makes no sense to me.
----
All this being said, if I am not mistaken base 3 is ALREADY BEING USED(!) internally in certain ALU operations. For example, I am told that FPU multiplication can be (and are) significantly sped up by switching to a base 3 representation (versus a direct binary implementation.)
The reason why ternary works for something like this is because multiplication can be (and is) implemented without relying on bit logic, but just adder (and the consequence arithmetic "RING" that follows) logic.
So... even if you could convince the silicon manufacturers to consider a base 3 CPU, they wouldn't necessarily gain very much for certain operations like FPU multiplication where it is already being leveraged.
Chess grandmasters do not tune their skills by playing lots of games... Most GMs learn by reading books and replaying of important games.
What?!?! This is blatantly incorrect. Many of the world's top Grand Masters have accounts on ICC and play a lot. Certainly GM Alexei Shirov (currently ranked 7th in the world) GM Nigel Short (past World Championship candidate, and ranked 16th in the world) and GM Zong Zhang (ranked 33rd in the world) are known to regularly play lots and lots of blitz games on ICC to keep their skills up. Many of the other top players play under unknown handles, so that nobody knows who they are.
The books are *WRITTEN* by these top GMs -- they have raw databases that they create themselves that are far deeper than just about any book on any opening system. It is also well known that they also use computers to check opening ideas.
And in the endgame, besides trivial ones that can be stored on CD-ROMS (6 pieces or less) humans are *FAR* superior to machines. There are even some endings that *I* could play better than the best computers (I am rated about 1800.)
If I understood what I read correctly, the "X86" CPUs on the market aren't really X86 CPUs anymore. Instead, they are essentially a super-fast hardware emulator of an instruction set. The real instruction set of these chips doesn't resemble X86 *at all*; the chip decodes on the fly from the X86 macro-ops down to the chip's native micro-ops, which are smaller and simpler and easier to track when running in parallel across several execution units.
x86 instructions, are just the architectural instructions and are not called macro-ops. Intel's notation for their internal instructions is to call them microops. AMD's K6 notation was RISC86-ops, and AMD's Athlon notation was to call them macro-ops.
However, it is very important to point out that they don't resemble RISC instructions either. Although they have many of the same properties, they generally can be over 150 bits in length, for example. These instructions also don't exist on any code address per se, and thus could not really be considered a full instruction set in of themselves.
Another thing that should be pointed out is that modern post-RISC out-of-order executing RISCs themselves are also forced to have some kind of alternative instruction set representation as well (since some of them perform complex operations, such as the PowerPC's double write instructions, or any "test-and-set" kind of instructions, and they are stored in internal reorder buffers)
#1. You're cheating yourself.. absolutely, I divorce myself!
Well, if you were bisexual... oh never mind.
#3. Your computer is vulnerable.. avi/mpeg/mov can carry a virus? Learn something new everyday!
ASF files appear to be able to carry executable activeX content. (I can't be 100% sure since Microsoft cease and desisted VirtualDub from reverse engineering the format, but I have run ASF file which popped up a web page from an URL contained in the binary of the file in MBCS format.) The problem is that often an ASF file will be renamed (I have noticed this from ASF files I obtained with Kazaa-lite) with an AVI or MPG file extension. Windows media player will detect the file by content, not by file extension, and after warning you about a mis-match, will go ahead and play it anyway.
#4. You're breaking the law.. >:]
Someone should inform them that price fixing, payola and anti-trust is also breaking the law. Though that applies more to the RIAA than the MPAA.
Given that you, yourself, are not very math/physics savvy, text books alone may not be enough. You might easily end up in a situation of the blind leading the blind when trying to help your kids. Understanding math/physics will often go beyond what any textbook can tell you. You might do a lot better from a person you can interact with who can see how well you are grasping a concept.
If you literally want to go to the trouble of hiring a tutor, then you'd get him/her for your kids obviously, but I don't know what to recommend for adult education. Given the current economy I'm sure the tutor might be willing to help you out as well in a package deal.:)
Then we just need to setup more legit torrents. Why not prod the people at sourceforge to setup a bittorrent system?
Because sourceforge is about source code management, not content management. Even, if you could successfully argue that content is in the same category as source, you also have to contend with sourceforge's policy that everything the maintain be *Open* source. Most AVI, etc, files are in proprietary non-editable closed source format.
Remember that the CD packaging, album art etc are part of what is being sold when the RIAA artists sell their music. While the Album art is superfluous, the packaging is not.
You still need to be enable the complete product, just like Apple has done with its iTunes music service. That means you also have to become an expert at CD burning software, drives etc. In the end possibly the best way to make this into a business is to partner with the CD/DVD burning companies, and/or blank disk (omg, I called it a disc, I am showing my age) sellers.
Selling bits alone online is something porn vendors get away with, but I don't think its the right way to try to sell music. At least not by itself.
Wow, I'm 100% GWB, and 90% Libertarian... according to that site, anyways. Came as a surprise to me, seeing as I usually think like a moderate.
Everyone thinks they're a moderate until they are forced to answer objective questions. I thought I was quite centrist as well, but I've since tested myself and have to admit that I am an *EXTREME* left wing person.
Slashdot Mirror
1. Since the library automatically resizes its strings including the base pointer, that means if you have multiple refs of a string, then manipulations of one of them may leave others in an undefined state. For example:2. The use of SAFESTR_TEMP() (a string that automatically disappears after being passed to any safestr function) is clever but necessarily prevents any of the SafeStr functions from accepting const parameters. This has an additional problem that if you write a function which accepts a safestr_t, then if you pass it to
one safestr function its reference might become undefined (you can't know.) For example:********
If you want to use an actually usefully architected string library try mine here:
http://bstring.sf.net/
In a direct comparison with safeStr, it should be pointed out that bstrlib doesn't have any concept of a "tainted" string. However, it does support read-only strings. bstrlib does not have any of the basic architectural weaknesses described above. It also has numerous other important features which are summarized here:
http://bstring.sf.net/features.html
If found any such collision, you could probably write a paper on it, and it would very readily be published in any crypto publication.
Python contains a built-in module for computing MD5. Assuming it uses a C-backend, then from my own testing, we know then that the program will become disk limited. There will be no significant difference between C or Python on disk limited activities.
Dear Bill,
Far and away your #1 bug is the infamous "buffer overrun" flaw. These usually mostly manifest themselves in string libraries. I know that you have at least 3 library solutions in-house (Safestr for C, CString in MFC, and basic_string in STL) but your developers don't use them otherwise these problems wouldn't happen.
I'd like to point you out to another alternative:
http://bstring.sf.net/
Which your developers may prefer. But whatever you do, why don't you simply make it a requirement that <string.h> simply be outlawed (you could easily write a tool to enforce that couldn't you?), or take some other drastic action?
Buffer overruns are certainly the most common kind of bug that isn't caught by QA (the right answer is not to try to train QA to find them -- they would require the skill of a hacker.) If you concentrate on this one bug alone, you will probably easily remove 80% of these attacks.
That seems a little hard to believe considering that AltiVec can only perform 32 bit floating point (which is not valid for the LinPack test used in the top500 list) and SSE-2 can.
Huh? Such things exist in the x86 world as well.
AltiVec cannot be used; it can only perform 32 bit floating point calculations which is not legal for the Linpack benchmark used at the top500 site. They have to stick to ordinary FP usage, where they will not have any advantage over Pentiums or Opterons.
Well designed in terms of what? They are *CLUSTERING* many machines. What matters is the *aggregated* cooling solution, not the cooling of any one single node. The Apple G5 has far more fans than your typical x86 box, which in the end just means more parts which can possibly fail, which becomes a noticable factor in clustering solutions.
Oh yeah -- they can't strike out the cost of buying a copy of MacOS for each machine, can they? At least with x86's they only need to buy or download one copy of Linux.
AltiVec would be illegal to use for the Linpack test. AMD/Kentucy tried this with 3DNow! in the KLAT2 machine several years ago but were rejected because the computation was not in 64 bits.
AltiVec cannot perform 64bit floating point computations, ergo, AltiVec will not be a factor.
That said, Opertons and Pentiums both have SSE-2 which *does* support 64bit floating point. Thus the question still remains -- why use G5's, when x86s are both cheaper *AND* faster?
The why do all the numbers look exactly the same as the original numbers posted? I followed the links in all directions and could not find new numbers anywhere. All the same old number, all the same old lies.
What that hell is this?!?!
These exactly disclosures were available on the day of the G5 launch. The link with the raw data is here:
Veritest PDF
And you can find a thorough debunking of the whole thing on my site here
This is very, very old news.
...
...
4. Profit!
But I guess that doesn't really fit in with a discussion of base 3
The usefulness of binary logic is not a relic. Its necessary. Software today heavily relies on the following:
... even if you could convince the silicon manufacturers to consider a base 3 CPU, they wouldn't necessarily gain very much for certain operations like FPU multiplication where it is already being leveraged.
1. Ordinary boolean logic: AND, OR, XOR, NOT. There is no simple way to implement these in bases other than bases which are powers of 2. You *CANNOT* get away with not implementing these in instructions sets. The silicon would be forced to emulate/implement these as some kind of ROM-table look up.
2. Integers being exact powers of 2 in size. There are many bit hacking tricks that "shift bits off the top" which will not work as expected. There is no way to fix this.
Note that an OR operation can actually lead to an OVERFLOW! There are numerous masking tricks that will fail because of this:
x = HIGH_BITS | y;
z = x & SOME_MID_TO_LOW_BITS;
Today's programmers assume that so long as HIGH_BITS and SOME_MID_TO_LOW_BITS don't intersect, then the two lines can be interchanged in order without effect. But because in base 3 the first line can overflow, there's no way to preseve this property.
I think of using ternary logic as kind of like trying to put square carpet in a pentagon shaped room. It makes no sense to me.
----
All this being said, if I am not mistaken base 3 is ALREADY BEING USED(!) internally in certain ALU operations. For example, I am told that FPU multiplication can be (and are) significantly sped up by switching to a base 3 representation (versus a direct binary implementation.)
The reason why ternary works for something like this is because multiplication can be (and is) implemented without relying on bit logic, but just adder (and the consequence arithmetic "RING" that follows) logic.
So
The books are *WRITTEN* by these top GMs -- they have raw databases that they create themselves that are far deeper than just about any book on any opening system. It is also well known that they also use computers to check opening ideas.
And in the endgame, besides trivial ones that can be stored on CD-ROMS (6 pieces or less) humans are *FAR* superior to machines. There are even some endings that *I* could play better than the best computers (I am rated about 1800.)
However, it is very important to point out that they don't resemble RISC instructions either. Although they have many of the same properties, they generally can be over 150 bits in length, for example. These instructions also don't exist on any code address per se, and thus could not really be considered a full instruction set in of themselves.
Another thing that should be pointed out is that modern post-RISC out-of-order executing RISCs themselves are also forced to have some kind of alternative instruction set representation as well (since some of them perform complex operations, such as the PowerPC's double write instructions, or any "test-and-set" kind of instructions, and they are stored in internal reorder buffers)
ASF files appear to be able to carry executable activeX content. (I can't be 100% sure since Microsoft cease and desisted VirtualDub from reverse engineering the format, but I have run ASF file which popped up a web page from an URL contained in the binary of the file in MBCS format.) The problem is that often an ASF file will be renamed (I have noticed this from ASF files I obtained with Kazaa-lite) with an AVI or MPG file extension. Windows media player will detect the file by content, not by file extension, and after warning you about a mis-match, will go ahead and play it anyway.
Someone should inform them that price fixing, payola and anti-trust is also breaking the law. Though that applies more to the RIAA than the MPAA.
Given that you, yourself, are not very math/physics savvy, text books alone may not be enough. You might easily end up in a situation of the blind leading the blind when trying to help your kids. Understanding math/physics will often go beyond what any textbook can tell you. You might do a lot better from a person you can interact with who can see how well you are grasping a concept.
:)
If you literally want to go to the trouble of hiring a tutor, then you'd get him/her for your kids obviously, but I don't know what to recommend for adult education. Given the current economy I'm sure the tutor might be willing to help you out as well in a package deal.
Remember that the CD packaging, album art etc are part of what is being sold when the RIAA artists sell their music. While the Album art is superfluous, the packaging is not.
You still need to be enable the complete product, just like Apple has done with its iTunes music service. That means you also have to become an expert at CD burning software, drives etc. In the end possibly the best way to make this into a business is to partner with the CD/DVD burning companies, and/or blank disk (omg, I called it a disc, I am showing my age) sellers.
Selling bits alone online is something porn vendors get away with, but I don't think its the right way to try to sell music. At least not by itself.