There is a saying, that "anyone can build a bridge that stands, but only engineers can build a bridge that barely stands".
1000 hp is not a feat of engineering. Even 5000 hp isn't. Anyone can build high horsepower cars. It is called "brute force". The question is, how do you do it?
It is all the attributes other than the horsepower that makes the difference between "feat of engineering" or not.
i.e. things like: How much oil does it use? How long does it run between maintenances? How quiet is the engine? How much space does it take? How much tuning does it take to run it efficiently?
Finally, it's the most important question: how much can you predict in advance, that how much power it makes, and all the attributes mentioned above, using sound calculations?
"Knowing the approximate results in advance" vs "Just do it and then take measurements" is the biggest difference between something built by engineering and something built by overapplying brute force.
>will Bugatti be responsible as to whom they >sell the cars to and also add as many safety >features as they can?
Of course it will. Bugatti is owned by VW, a German carmaker that gives its econoboxes like the Golf traction-controll goodies (e.g. ASR, which is also available on Mercedes and Audi).
Windows machine: 1. Windows update 2. Gvim 3. Mozilla Firebird 4. IrfanView32 5. Sun's Java VM 6. WinAmp 7. VNC Viewer 8. IM client 9. FrHed (Hex Editor) 10. Half-Life + CounterStrike
Linux Machine (provided that it has the basic GNU packages): 1. Kernel update and drivers 2. Curl or Wget 3. X and drivers 4. Mozilla Firebird 5. KDE 6. Gvim 7. Sun's Java VM 8. Gaim 9. XMMS 10. Wine and Windows games (see above)
I doubt that it can even recognize a ROT-13 Mp3 attachment renamed "readme.txt".
It has a lot of catchups to do when students start sending encrypted traffic through ordinary channels. (an easy example, IM file transfer of a password-protected ZIP file)
In most cases, it's the quantity, not speed, that matters anyway. The mantra is, keep everything in memory to minimize disk I/O since even the slowest memory is faster than the fastest disk.
If I have to choose between 512MB of Dual Channel RAM and 1GB of Single Channel for my PC, I'd pick 1GB. Choice is easy.
I don't see it, your performance argument is totally hypothetical because nobody has seen any multithreading performance numbers with PostgreSQL.
Such comparison only makes sense if you can use the same database, turn on and then off multithreading, and perform the same test.
In our environments (GBs of data) we do not see any performance hit due to the lack of multithreading.
As for comparing the multithreaded performance from MySQL and the multiprocess performance of PostgreSQL, you do realize that PostgreSQL is doing much more than MySQL, right?
I highly suspect that, by the time MySQL accomplishes 80% of PostgreSQL's feature list, it'll totally lose its only advantage: higher performance on read-only operations.
Upgrade to at least 7.3. It has online vacuuming, which means vacuuming can happen concurrently with normal database operations, so put it in your cron and do it every hour. Coupled with a high enough fsm pages and the only downtime you'll be looking at are backups. If you run a replicator you don't even have to shut down your master database for backup, so it'll be truly 24/7.
Postgres can trivially handle 200 connected users running small selects. Something must be seriously wrong with your postgresql.conf. Take a look at it, or replace your DBA.
Either the Kernel or the major Distros have to make decisions to COMPLETELY CUT OSS support, kill it. Done. Finished. No more backwards compatibility. (Well, ALSA can be configured to emulate OSS anyway)
Some modern distribitions begin to see the light and use ALSA exclusively for sound, CUPS exclusively for printing, etc. When it comes to managing your devices, more options certainly is NOT better.
Even "the idiot in the next cubicle" can write code that is fast in C++, without optimization, without tweaking, debugging on, etc. There are a million ways to make a program fast and a few ways to make it slow.
In Java you at least HAVE to think about making things fast in order for it to happen. No such requirement for C or C++. There are a million ways to make a program slow and some manual optimization effort is required to make it fast.
WHO still runs 386 these days except for nostalgic reasons? Did you run 286 in 2001?
With low CPU prices these days, running anything but the simplest programs on a 386 (especially if you want performance out of it) will probably cost MORE than say, a Pentium.
5) If a prior art is discovered after the patent is granted, the applicant will lose the patent as well as pay a small fine, which increases linearly for repeated offenders.
Slashdot Mirror
There is a saying, that "anyone can build a bridge that stands, but only engineers can build a bridge that barely stands".
1000 hp is not a feat of engineering. Even 5000 hp isn't. Anyone can build high horsepower cars. It is called "brute force". The question is, how do you do it?
It is all the attributes other than the horsepower that makes the difference between "feat of engineering" or not.
i.e. things like: How much oil does it use? How long does it run between maintenances? How quiet is the engine? How much space does it take? How much tuning does it take to run it efficiently?
Finally, it's the most important question: how much can you predict in advance, that how much power it makes, and all the attributes mentioned above, using sound calculations?
"Knowing the approximate results in advance" vs "Just do it and then take measurements" is the biggest difference between something built by engineering and something built by overapplying brute force.
It's the driver, not the car. A driver who kills someone in 3 seconds is going to do it anyway even in a Geo Metro.
>will Bugatti be responsible as to whom they
>sell the cars to and also add as many safety
>features as they can?
Of course it will. Bugatti is owned by VW, a German carmaker that gives its econoboxes like the Golf traction-controll goodies (e.g. ASR, which is also available on Mercedes and Audi).
Windows machine:
1. Windows update
2. Gvim
3. Mozilla Firebird
4. IrfanView32
5. Sun's Java VM
6. WinAmp
7. VNC Viewer
8. IM client
9. FrHed (Hex Editor)
10. Half-Life + CounterStrike
Linux Machine (provided that it has the basic GNU packages):
1. Kernel update and drivers
2. Curl or Wget
3. X and drivers
4. Mozilla Firebird
5. KDE
6. Gvim
7. Sun's Java VM
8. Gaim
9. XMMS
10. Wine and Windows games (see above)
Someone has to ask this question.
Does it export layouts to TeX code?
IANAL, but after reading the license it is created to compete with GPL:
1. It chooses the name "Common" Public Licence hoping that a lot of developers will use it.
2. It forces source code of the derived work to be licensed by the CPL. i.e you cannot fork a CPL project under the GPL.
Basically, I see it as the "forced BSD" or "anti-GPL".
Just another company trying to make a quick buck.
I doubt that it can even recognize a ROT-13 Mp3 attachment renamed "readme.txt".
It has a lot of catchups to do when students start sending encrypted traffic through ordinary channels. (an easy example, IM file transfer of a password-protected ZIP file)
In most cases, it's the quantity, not speed, that matters anyway. The mantra is, keep everything in memory to minimize disk I/O since even the slowest memory is faster than the fastest disk.
If I have to choose between 512MB of Dual Channel RAM and 1GB of Single Channel for my PC, I'd pick 1GB. Choice is easy.
Largest area covered by bloody splat ever achieved by a falling human being
I don't see it, your performance argument is totally hypothetical because nobody has seen any multithreading performance numbers with PostgreSQL.
Such comparison only makes sense if you can use the same database, turn on and then off multithreading, and perform the same test.
In our environments (GBs of data) we do not see any performance hit due to the lack of multithreading.
As for comparing the multithreaded performance from MySQL and the multiprocess performance of PostgreSQL, you do realize that PostgreSQL is doing much more than MySQL, right?
I highly suspect that, by the time MySQL accomplishes 80% of PostgreSQL's feature list, it'll totally lose its only advantage: higher performance on read-only operations.
Upgrade to at least 7.3. It has online vacuuming, which means vacuuming can happen concurrently with normal database operations, so put it in your cron and do it every hour. Coupled with a high enough fsm pages and the only downtime you'll be looking at are backups. If you run a replicator you don't even have to shut down your master database for backup, so it'll be truly 24/7.
Postgres can trivially handle 200 connected users running small selects. Something must be seriously wrong with your postgresql.conf. Take a look at it, or replace your DBA.
>there is no law that says that threaded applications are inherently less stable.
There is also no law that says that not being multithreaded will limit the performance of a program.
Your point is?
Renaming PostgreSQL to YourSQL
Exactly.
Either the Kernel or the major Distros have to make decisions to COMPLETELY CUT OSS support, kill it. Done. Finished. No more backwards compatibility. (Well, ALSA can be configured to emulate OSS anyway)
Some modern distribitions begin to see the light and use ALSA exclusively for sound, CUPS exclusively for printing, etc. When it comes to managing your devices, more options certainly is NOT better.
Take a look at these:
0 3/ Paulin/DensityEstimation.pdf
http://graphics.stanford.edu/papers/rtongfx/
http://artis.imag.fr/~Nicolas.Holzschuch/061020
People have been (although fairly recently) toying with the idea of using GPU to accelerate global illumination for a while.
Props must go to nVidia tho for combining and putting all these ideas into a nice package.
Does it mean "Develop applications rapidly" or "Develop rapid applications"?
If Mozilla itself is any example, Mozilla and XUL can only be used for rapid development of antirapid (i.e. sluggish) applications.
0) emacs
And see how they react.
Even "the idiot in the next cubicle" can write code that is fast in C++, without optimization, without tweaking, debugging on, etc. There are a million ways to make a program fast and a few ways to make it slow.
In Java you at least HAVE to think about making things fast in order for it to happen. No such requirement for C or C++. There are a million ways to make a program slow and some manual optimization effort is required to make it fast.
The problem is, writing functors makes code longer, and harder to understand.
:-(
No true lambda ==
4294967296 - 4285199774 = 9767522 pages to overflowage. Go Go Go!
If we can safe 80% of energy, does it mean that using the same amount of energy we'll be able to make 5 times the horsepower?
So a measly 60 hp motor will become a monster 300 hp on the same amount of fuel?
If so, I'll be first in line for the next car that uses the motor.
However, from Tom's reviews, it seems that nVidia's new chip suffers from shader quality problems.
I'll bite.
WHO still runs 386 these days except for nostalgic reasons? Did you run 286 in 2001?
With low CPU prices these days, running anything but the simplest programs on a 386 (especially if you want performance out of it) will probably cost MORE than say, a Pentium.
May I add:
5) If a prior art is discovered after the patent is granted, the applicant will lose the patent as well as pay a small fine, which increases linearly for repeated offenders.