I definitely agree that any attempt at semi-intelligent filtering must be moderated down rather than killed... you know that no matter how well thought out the system is, it will end up "catching" insightful, legitimate posts from time to time. At least with a mod down, it has a chance to be modded back up by humans.
Also, the diffs would quickly become overwhelming. Using a diff method would mean storing all "bad" recent posts, and diffing each new posts against every one of those...
While the md5 hash is of course easily circumvented, it's still a good system, it will eliminate people too stupid to circumvent it... Perhaps it would even have the unintended effect of filtering out redundant one-liner comment-stereotypes like "I Agree".
You ask if "Unix" can handle it, then later if Linux can. Of course, commercial unices can easily handle things as much as 1000x (Yes, I've got one running that big about 30 feet from me)that size, given enough money.
30GB is really a trivial size for a database in the modern age. I think that Linux/Oracle can _do_ it today, but probably not as well as a commercial solution (this is not flamebait: I love linux and can't wait for linux to be the top DB platform, but I don't think we're there yet).
Of course, if you're looking down a long road of development, testing, deploymeny, and then maintenance... by the time you get any significant distance down that road, there should be packaged-up ready-to-go Linux-2.4/Oracle machines that could really blow a competitor away. . . In wihch I definitely start working with what you can in the Linux/Oracle field today.
I think that Netscape may have done more harm than good in the long run. With the existance of a "free" binary netscape browser for Linux all these years, followed by the spawning of the always-behind-schedule Mozilla project, people in the Linux community have been lazy and never really put gusto behind an independant, standards-conformant GPL browser project.
Granted, there have been several projects... but virtually nobody uses them (and thus you have a lack of coders/testers) because they can cop out and use Netscape instead.
In the IE/NS religious war, I have always sided with Netscape (hey, I was an original Mosaic user), but if they (Netscape/Mozilla.org) aren't going to do the job right, then the community needs to step up in its own defense and spawn a new project.
You can also do a virtual click track w/o shipping anything anywhere. They could measure network latency between each musician and a central point, and then send out a latency-corrected clicktrack to everyone.
FreeSpeech is apparently some alpha-stage linuxy GPL speech recognition software. I don't know anything about it, and the HTML is practically empty at the given link. A search for FreeSpeech at the main Sourceforge page will turn up a page for it that has a few useful tidbits and source tarball downloads though.
It would make the most sense if this cpu was @ 133 FSB (8.5x multiplier == 1.1305 Ghz).
As mentioned in another reply, most recent intel CPU's are at least multiplier locked. You can usually still overclock by adjusting the FSB, but at 8.5x this gets very dangerous quickly.
Example: for a 1.13 Ghz (133x8.5) processor, if you overclocked the bus up from 133 to 140 (a modest 5% move), the processor steps up to 1.19 Ghz. Since these cores are in limited quantity and nothing faster is made, it is probably a decent bet that either the processor or the integrated L2 would fail before you got to 1.2 Ghz.
Also, notice on the main security page that the ordering of the security bulletin numbers don't line up with the published dates. This seems like hard evidence that they don't inform their customers of these security problems quickly in the order received, but rather whenever they finally get around to having some half-answer (which will be days after bugtraq and the like have eaten it up).
The 80GB drive is 5400 RPM and only has 4 platters, and therefore 8 heads. The claimed media speed (I assume for a sustained contiguous transfer, which is best case) is 46.7MB/sec. The claimed average seek time is " None of these numbers are too horribly bad for a 5400 RPM IDE disk. My problems are:
If you really only use 2-12GB of data, and the other "junk" you'd fill this drive with is archival stuff you're not going to access hardly at all, write your junk out to tape/CD/DVD-RAM or something
If you really have close to 80GB of working data to work with, accessing it all from a single 80GB drive is going to be much slower than using 4 20GB drives in a Raid-1 (striped) config... or even just as a 4 disks with different data on them.
Of course, it goes without saying that regardless of any of the above, SCSI is better than IDE for serious data access.
The IDE bus is at 66 on modern motherboards now, with 100 on it's way out the door as we speak (these Maxtor's in question are Ultra-100, incidentally). The very least they could do with these mammoth drives is get the internal speed of the media closer to the bus speed, so that there isn't so much performance loss (versus same data set split over multiple smaller drives).
The pic was probably doctored... but that doesn't neccesarily mean the AppleInsider is defrauding its browsers. It could be that these pics were leaked to them by someone in Apple, where they are known to be doctored-up "artists's renditions" of a new product in the works...
One thing that lends credibility to the general idea of a cube-shaped server from Apple: Remember the NeXT Cube? Wasn't that Jobs's?:)
Seems to me with this card ATI is finally starting to cater to the "I need high performance graphics at any price NOW" crowd that 3Dfx and then NVidia have dominated in the past... as opposed to their (ATI's) earlier catering to the large volume OEM market for an affordable card that supported the right buzzwords, but which no serious gamer would want.
With ATI's financial resources, they could possibly change the high-end 3d graphics landscape if they continue moving in this direction over the next generation or two of cards.
I'm being redundant intentionally here and wasting space, but I just have to stand up and agree outloud. In my mind, Woz definitely ranks in the top 10 computer hackers of all time. And I was never even an Apple fan.
Well... while I see your point (a closed driver, or a half-closed driver (opensource most code + a binary file of special routines to link against) is better than nothing for Joe Linux User.
However, many people use (or would like to use, or might use) Linux for secure computing, and usually one of their primary basis for doing so is that every opcode that will ever hit the processor of their secure box is fully backed by open, readable source code. If there's a bug, security hole, or backdoor, they know that even without the usually great help from the community and the code authors, they _could_ track it down and fix it all themselves.
They also know that blatant security holes, bugs, and especially secret backdoors have a much harder time living very long in an open source driver.
One thing's for sure: While I might begrudgingly use Binary OSS Sound Drivers on my Linux Desktop, I sure as hell would never use a binary ethernet card driver on my linux firewall.
You are correct that a supercomputer turns a calculation problem into an I/O problem, and that therefore the best I/O architecture wins, which would be an advanced local supercomputer bus, rather than the 'net.
However, this is true only given roughly equivalent computing power. If you think of distributed.net as a supercomputer, and compare it to a modern one (say, the Cray T3E series or something), you find that:
The Cray can communicate between it's processors much, much more efficiently, and therefore does a better job per flop of cpu power
distributed network computing still outperforms it because it (much less efficiently) is utilizing hundreds of thousands of processors, loosely coupled.
I think there are still large engineering challenges to overcome before a local supercomputer can scale to compete with the raw flops size of distributed network computing.
Of course, there's still the issue that distributed.net-style computing only works well for a small subset of the problems that work well for the Cray. But for these problems, I think it is a faster architecture given the level of participation.
I would now rant for pages about the coming networked computing architectures, where all network terminals sell unused slices of computing power to the highest bidder for micropayments... and that those computing slices might be used by the content/service providers who are serving the contents/services to the terminals, which creates an almost liquid computing environment... but that's all pipe dreams for now.
You don't have to be quite so scathing. I think I fully disclaimed my comments appropriately. I know that TUX isn't khttpd. However, you will note that TUX does concede that khttpd was an important learning experience on the way to TUX. The other "dynamic" features are nice, and I'm sure they are great, but I'm betting the primary performance benefit of TUX comes from the same basic concepts as khttpd. I'm not dissing TUX by any means, I think it sounds great.
Moving web serving into the kernel is very beneficial, but only for static content. If you think through what happens on a typical Linux/Apache server when a static page is requested, there's lots of room for performance improvement. This is basically because both communication paths for the Apache server (the socket communication to the user and the I/O to the disk file) go through the kernel seperately. This means the data is (redundantly) read from disk by the kernel, copied to userspace for Apache to see, just so that Apache can copy it back to kernel space through socket calls to send it out a TCP port basically unaltered. Doing this in the kernel means you can achieve the same result with a single copy from the disk driver to the TCP stack within kernel space.
Note that I haven't looked at TUX, and what I've said above is a general explanation of the type of concept that TUX is about, therefore I might be missing a few technicalities.
The new massively parallel computers are even faster than distributed.net... I think it's easier to build and coordinate a large beowulf than it is to coordinate a few tens of thousands of hobbyists.
I disagree. Recently (over the past month or so), I put several large computers worth many millions of dollars to work on distributed.net. Specfically we're talking about multiple Sun E10K's, multiple IBM SP/2 Clusters, and a small Beowulf cluster.
While it did bump my individual stats up into the top 30-ish during the days I did this (and made me _Really_ wonder what those other "individuals" above me were running), my input was still massively outdone by the rest of distributed.net as a whole.
Based on this, I don't really think it is possible to buy (for any remotely reasonable amount of money) a general purpose hardware solution which can parallel distributed.net.
It has always seemed to me that PostgreSQL leans in the direction of an Open Source professional database with a modern syntax, cutting-edge feature set, etc.... Basically, designed for the Oracle user looking for an Open Source solution.
OTOH, MySQL seems to me to lean in the direction of the life-long linuxhacker/perlcoder who doesn't really care about the latest Corporate technologies, and just wants an effective and efficient method of storing some data.
Just my view of the whole thing, of course. Overall, I like them both and I hope they both continue on side-by-side. We need both alternatives around.
You're right, Winelib is exactly what I was talking about. (I've never used Wine, forgive me). At least from an outsider perspective, nothing I've ever heard about Wine has ever led me to believe that they had anything like Winelib... maybe they should work on giving it more exposure.
Are there any projects out there aiming at providing the Win32 API as a native linux library which implements these calls in terms of calls to the kernel/glibc/X/GTK+/etc....? I would think that a "native" Win32 API implementation would be far more useful. It would mean that vendors who write Win32 software could port their product with relatively minimal effort and probably not quite as huge a performance hit. They would basically just have to undo the MSVC++ specifics of their code and then recompile under linux/g++. As stated in the other posts (re: Corel/Wine/Porting), the goal is always that the vendor would then see the light and do a truly native port later . . .
Also, the diffs would quickly become overwhelming. Using a diff method would mean storing all "bad" recent posts, and diffing each new posts against every one of those...
While the md5 hash is of course easily circumvented, it's still a good system, it will eliminate people too stupid to circumvent it... Perhaps it would even have the unintended effect of filtering out redundant one-liner comment-stereotypes like "I Agree".
30GB is really a trivial size for a database in the modern age. I think that Linux/Oracle can _do_ it today, but probably not as well as a commercial solution (this is not flamebait: I love linux and can't wait for linux to be the top DB platform, but I don't think we're there yet).
Of course, if you're looking down a long road of development, testing, deploymeny, and then maintenance... by the time you get any significant distance down that road, there should be packaged-up ready-to-go Linux-2.4/Oracle machines that could really blow a competitor away. . . In wihch I definitely start working with what you can in the Linux/Oracle field today.
Granted, there have been several projects... but virtually nobody uses them (and thus you have a lack of coders/testers) because they can cop out and use Netscape instead.
In the IE/NS religious war, I have always sided with Netscape (hey, I was an original Mosaic user), but if they (Netscape/Mozilla.org) aren't going to do the job right, then the community needs to step up in its own defense and spawn a new project.
You can also do a virtual click track w/o shipping anything anywhere. They could measure network latency between each musician and a central point, and then send out a latency-corrected clicktrack to everyone.
As mentioned in another reply, most recent intel CPU's are at least multiplier locked. You can usually still overclock by adjusting the FSB, but at 8.5x this gets very dangerous quickly.
Example: for a 1.13 Ghz (133x8.5) processor, if you overclocked the bus up from 133 to 140 (a modest 5% move), the processor steps up to 1.19 Ghz. Since these cores are in limited quantity and nothing faster is made, it is probably a decent bet that either the processor or the integrated L2 would fail before you got to 1.2 Ghz.
Someone just had to correct me... 11 minutes after I corrected myself...
Also, notice on the main security page that the ordering of the security bulletin numbers don't line up with the published dates. This seems like hard evidence that they don't inform their customers of these security problems quickly in the order received, but rather whenever they finally get around to having some half-answer (which will be days after bugtraq and the like have eaten it up).
I meant Raid-0 (Striped), Not Raid-1, which is mirroring... not that it's material to the comment.
The IDE bus is at 66 on modern motherboards now, with 100 on it's way out the door as we speak (these Maxtor's in question are Ultra-100, incidentally). The very least they could do with these mammoth drives is get the internal speed of the media closer to the bus speed, so that there isn't so much performance loss (versus same data set split over multiple smaller drives).
One thing that lends credibility to the general idea of a cube-shaped server from Apple: Remember the NeXT Cube? Wasn't that Jobs's? :)
With ATI's financial resources, they could possibly change the high-end 3d graphics landscape if they continue moving in this direction over the next generation or two of cards.
I'm being redundant intentionally here and wasting space, but I just have to stand up and agree outloud. In my mind, Woz definitely ranks in the top 10 computer hackers of all time. And I was never even an Apple fan.
However, many people use (or would like to use, or might use) Linux for secure computing, and usually one of their primary basis for doing so is that every opcode that will ever hit the processor of their secure box is fully backed by open, readable source code. If there's a bug, security hole, or backdoor, they know that even without the usually great help from the community and the code authors, they _could_ track it down and fix it all themselves.
They also know that blatant security holes, bugs, and especially secret backdoors have a much harder time living very long in an open source driver.
One thing's for sure: While I might begrudgingly use Binary OSS Sound Drivers on my Linux Desktop, I sure as hell would never use a binary ethernet card driver on my linux firewall.
My $.02 :)
Do you have any specs on the size of it? Or links? I'm really curious....
However, this is true only given roughly equivalent computing power. If you think of distributed.net as a supercomputer, and compare it to a modern one (say, the Cray T3E series or something), you find that:
- The Cray can communicate between it's processors much, much more efficiently, and therefore does a better job per flop of cpu power
- distributed network computing still outperforms it because it (much less efficiently) is utilizing hundreds of thousands of processors, loosely coupled.
I think there are still large engineering challenges to overcome before a local supercomputer can scale to compete with the raw flops size of distributed network computing.Of course, there's still the issue that distributed.net-style computing only works well for a small subset of the problems that work well for the Cray. But for these problems, I think it is a faster architecture given the level of participation.
I would now rant for pages about the coming networked computing architectures, where all network terminals sell unused slices of computing power to the highest bidder for micropayments... and that those computing slices might be used by the content/service providers who are serving the contents/services to the terminals, which creates an almost liquid computing environment... but that's all pipe dreams for now.
I'm no ueber-kernel-hacker either. You shouldn't be embarrassed, all is fine.
You don't have to be quite so scathing. I think I fully disclaimed my comments appropriately. I know that TUX isn't khttpd. However, you will note that TUX does concede that khttpd was an important learning experience on the way to TUX. The other "dynamic" features are nice, and I'm sure they are great, but I'm betting the primary performance benefit of TUX comes from the same basic concepts as khttpd. I'm not dissing TUX by any means, I think it sounds great.
Note that I haven't looked at TUX, and what I've said above is a general explanation of the type of concept that TUX is about, therefore I might be missing a few technicalities.
Also, you can use OpenSSL+SSLwrap over standard sendmail.
I disagree. Recently (over the past month or so), I put several large computers worth many millions of dollars to work on distributed.net. Specfically we're talking about multiple Sun E10K's, multiple IBM SP/2 Clusters, and a small Beowulf cluster.
While it did bump my individual stats up into the top 30-ish during the days I did this (and made me _Really_ wonder what those other "individuals" above me were running), my input was still massively outdone by the rest of distributed.net as a whole.
Based on this, I don't really think it is possible to buy (for any remotely reasonable amount of money) a general purpose hardware solution which can parallel distributed.net.
They make solid-object printers... they have a couple of competitors, but I can't remember their names off-hand.
OTOH, MySQL seems to me to lean in the direction of the life-long linuxhacker/perlcoder who doesn't really care about the latest Corporate technologies, and just wants an effective and efficient method of storing some data.
Just my view of the whole thing, of course. Overall, I like them both and I hope they both continue on side-by-side. We need both alternatives around.
You're right, Winelib is exactly what I was talking about. (I've never used Wine, forgive me). At least from an outsider perspective, nothing I've ever heard about Wine has ever led me to believe that they had anything like Winelib... maybe they should work on giving it more exposure.
Are there any projects out there aiming at providing the Win32 API as a native linux library which implements these calls in terms of calls to the kernel/glibc/X/GTK+/etc....? I would think that a "native" Win32 API implementation would be far more useful. It would mean that vendors who write Win32 software could port their product with relatively minimal effort and probably not quite as huge a performance hit. They would basically just have to undo the MSVC++ specifics of their code and then recompile under linux/g++. As stated in the other posts (re: Corel/Wine/Porting), the goal is always that the vendor would then see the light and do a truly native port later . . .