I am very much an advocate of simple methods. However, I am not sure if the Indian model (or the Diebold machines for that matter) would handle the practicalities involved in a typical US election.
Yes. Allow an overcomplicated procedure to develop, design a system to implement the procedure, act all amazed when system does not work. Describes a lot of things besides the US election system.
Why is it again that elections can only be held once every four years and every possible decision must be made at the same time?
"Having said that, it looks like the guys doing the testing got their CFLAGS wrong. Gentoo's performance should never be worse than Mandrake -- I reckon they forgot omit-frame-pointer."
That's a big reason why I'd not switch from a binary-distributed OS (I happy with Red Hat, YMMV) to a source-distributed one. Not only is it more convenient to get ready-to-run binaries, but I can actually trust the vendor to have tried to choose a good set of compiler options and to have tested the results, so I don't have to.
Any programmer worth being called one could tell you that -O2 -march=i686 isn't even the beginning of looking for the best optimisation for any piece of software. Dozens of flags affect the output, sometimes there are choices to be made between size vs speed, sometimes "optimize for size" actually produces the fastest code, and so on and so on. And some combinations actually produce buggy results. It's a huge amount of work to find the optimum setting, and the CPU model specific scheduling tweaks enabled by -march=i686 rarely make any difference at all.
I'll stick with binaries someone has tested to work, thanks. Only when I have linking problems or a feature I want had not been included at compile-time do I touch source code.
I've set up several critical server systems to various places using what are now called "consumer-level" Red Hat releases (5.2, 6.2, 7.1, 7.3, none with 8.0 yet), and will probably continue to do so in the future (though not necessarily always when I might have done that before). Here's why:
There's a big difference between a Linux deployment, and a, say Windows 2000 Server or Solaris deployment - Linux is free. Because the software license cost is zero (or at least low in comparison), it often makes sense to deploy two lower-cost machines instead of one bigger, more expensive system, and gain some redundancy in the process.
Now, once you have that redudancy, you can use it to your benefit even while upgrading. Worried that a major Red Hat upgrade, that you have to do because of upcoming EOL, is going to cause problems? No worries. Take one machine offline, test the upgrade there, and continue when you've cleared any problems.
Fact is, it's almost as easy to severely disrupt a business function with a Microsoft service pack installation as it is with a Red Hat major release upgrade. It always boils down to whether you can afford an online backup system or not.
To me, the xfthack results (based on the posted screenshots) look clearly inferior to RH8's stock Xft2 functionality (set to slight hinting, subpixel RGB rendering, to match my LCD panel).
Why? Look at the vertical lines of the fonts: they're not sharp. In fact, the results look more like hinting completely disabled! That I can do myself with a click in the font prefs.
I don't think Xft2 is quite there yet either - some diagonal lines, such as the drop line in 'y' at some sizes of Times New Roman, gets rendered so thinly that it's difficult to see at all. Perhaps that's because I haven't rebuilt Freetype with the bytecode hinter enabled.
Hinting is a difficult issue, and very much related to the resolution of your display. Single words or short phrases (such as titles) always look better without hinting, because (especially with subpixel rendering enabled) the character shapes and spacing is more correct. However, large bodies of text become difficult to read because individual characters are blurred. That's where hinting helps: it subtly changes character spacing and shapes to reduce blur (improve contrast). Text becomes more readable - unless the uneven spacing bugs you more than blurry shapes.
What about JSP? Jetty uses Jasper, like Tomcat, and Jasper has, as far as I've understood, been one of the major roadblocks to Tomcat performance (and the reason Resin is brought up as an alternative). However, I see Jetty 4.1 is using a new Jasper version. What is the performance benefit?
Usually I wouldn't care if an open-source program can be considered an "MS-replacement" or whether it runs on Windows or not, but this time is different, for exactly one reason:
Evolution offers everything Outlook and Eudora does, so switching to it would not be a problem to anyone so inclined. And, it supports encrypted email (PGP/MIME) better than all other email software, so if my friends on Win/Mac could use it too, I wouldn't need to send them plaintext mail.
Ie, this program is not just "as-functional-but-free", but MORE functional than software available on other platforms.
Now, if only it read Outlook calendaring messages without major pain at the Outlook end...
perhaps it's not a lot "in this business", but face it, it is a helluva sum of money. I fail to grasp how NASA can manage to spend $12 million on a "duck-tape" mission. it's not as if they could have refueled the probe or anything, so all that money has went to radio contact, mission planning and reprogramming. Now, assuming that's the cost of the mission since October 1999, when the main mission ended, it's half a million dollars for every month of the continued existence of the probe. Where has it gone? $1000 floppy disks? 50 person full-time ground crew?
Not that I actually need to care since it wasn't me paying for it.
This time, Mundie's analysis is straight on..
on
Mundie Responds
·
· Score: 1
..the problem is, this is the sideline, and the message to the public in the speech itself was about something entirely different.
However, now Mundie writes: "the GPL is intended to build a strong software community at the expense of a strong commercial software business model", and exactly captures the reason why RMS created the GPL in the first place: to create software, business be damned.
Now, why this would be a problem for Microsoft in particular is not explained by Mundie, since nothing forces Microsoft to release their software under the GPL. The point remains that MS is afraid their money-maker (software) is threatened. Not that they wouldn't be able to compete against free software - with their resources, absolutely they can, but because they have no way to crush free software like earlier commercial competition, and not being able to crush the competition forces MS to spend more resources actually competing (ie, spend more money on development and get less revenue from the result) than if free software was not around. That would obviously bother any business executive.
Why it should bother the customer is left unclear.
Fine piece of analysis, too bad the original was flawed.
Huh. There are other update services already, and have been for a long time. autorpm is the first I saw (and tried) - and Ximian's Red Carpet is also perfectly able to provide update services for Red Hat Linux.
http://rpmfind.net/linux/rpm2html/search.php?que ry =autorpm
http://www.ximian.com/apps/redcarpet.php3
VMware lets you consolidate your "got-to-have-these-because-of-MS-licensing" NT/2000 servers into common hardware. You can even host the whole thing on Linux to allow you to more tightly monitor the individual NT processes.
The program supports around a dozen different mailbox formats, easily user selectable with an ~/.imaprc file. Some are just legacy stuff, but a few are clearly suitable in different situations.
I think UW recommends the "mbx" format for most situations - fast, safe in concurrent-access situations, etc. Clearly unlike either UNIX mbox or Qmail maildir.
Of course, if what you REALLY care about is fast IMAP access instead of being able to bypass the IMAP server with client-side solutions, you should look at Cyrus IMAP server as well.
Colin Plumb's shred(1) is part of GNU fileutils 4.0, standard install on Red Hat 6.2. From the info page:
"This uses many overwrite passes, with the data patterns chosen to maximize the damage they do to the old data. While this will work on floppies, the patterns are designed for best effect on hard drives. For more details, see the source code and Peter Gutmann's paper `Secure Deletion of Data from Magnetic and Solid-State Memory', from the proceedings of the Sixth USENIX Security Symposium (San Jose, California, 22-25 July, 1996)."
Then you can use light sails for applications where getting there fustest-with-the-mostest isn't the top priority -- say, ferrying stuff around the asteroid belt.
Actually, depending on the range needed, a sail configuration may end up being the fastest method. That's because a big sail can not only produce more push than an ion drive, it will never run out of fuel - so you can accelerate all the way to the halfway point, and then turn around to decelerate (or, on an interstellar trip, perhaps use a magnetic sail to decelerate faster, as someone else pointed out). An ion drive will invariably run out of fuel at some point and then you'll be coasting forever.
The advantage of an ion drive is that it's much smaller - thus easier to deploy (there are several theoretical deployment designs for unfurling sails by rotation, mostly, but such designs add weight, and you want it to be as lightweight as possible to use the push for the cargo, not for the sail), and also independent of remote sources of power (for a solar sail, you lose push and risk destabilizing the sail configuration if your orbit takes you in a shadow of a planet - for microwave mesh sails, you need the microwave transmitter aimed and powering the sail all the time).
Since more than half the score 2+ comments at the time I write this (pretty early into the thread) have totally confused who's who, let's try to explain:
MR GOLD: The plaintiffs' (MPAA/studios) lawyer
MR GARBUS: The defendants' (2600, DeCSS) lawyer, who MPAA has tried to get thrown off the case
Since more than half the score 2+ comments at the time I write this (pretty early into the thread) have totally confused who's who, let's try to explain: MR GOLD: The plaintiffs' (MPAA/studios) lawyer MR GARBUS: The defendants' (2600, DeCSS) lawyer, who MPAA has tried to get thrown off the case MR SCHUMANN: A witness for MPAA. Hopefully, now that you know this much, please also realize that lawyers, even smart, good lawyers that might be on YOUR side, don't necessarily know each detail about, for instance, how Linux DVD device drivers interact with the hardware, or that sort of thing. They don't need to, either. What they need to be able to do is to argue their point to a judge who doesn't know that either, and convince him/her that they are right. Thus, it isn't necessarily a failure that they might not get each and every technical detail completely right. And as to trying to get MPAA's witness to provide his computer for evidence, you can bet that the other side would try to do the exact same thing - so why would it not be a valid move for the defendants?
"they"? FYI, the "they" you refer to, the party asking for the hard drive entered as evidence, is Martin Garbus, the defendants' lawyer. Mr. Schumann, the witness being interviewed, is MPAA's witness trying to testify that DeCSS is a piracy tool.
From your attitude and comments I'd guess you think DeCSS shouldn't be under a lawsuit right now. If that's true, your reading of the transcript was TOTALLY off track. If stuff like this is too hard for you to understand, please don't even try, because obviously it only serves to further confuse the issue and cause you to spread misinformation.
Thanks for your efforts benchmarking Java - it was very interesting to me, and I've been thinking of doing similar benchmarks myself. You beat me to the punch!
I ran your code through some tests on my Linux laptop (Mobile Pentium II 400MHz, 128 MB RAM, Red Hat 6.2) using Sun's (Blackdown) JDK 1.2.2 and the 1.3 preview releases from Sun (utilizing HotSpot) and IBM (with their high-performance JIT).
Overall results: compared to un-optimized GCC baseline, IBM's JVM ran 22% faster (while full GCC optimization was only 17% faster than the baseline!). Sun's "stable" 1.2.2 release was 72% slower, and the 1.3 preview (with HotSpot) 17% slower. Interestingly enough, the 1.3 classic JVM was 5 times slower than the 1.2.2 release, so there's probably a huge amount of debugging code in the preview release. Full release might be a totally different story.
Anyhow, bottom line is that the IBM 1.3 JVM runs faster than C, given the type of code in the benchmarks - which, incidentally, is probably algorithmic optimization wise pretty much like most code out there: written in a hurry, and "good enough".
Slashdot Mirror
Yes. Allow an overcomplicated procedure to develop, design a system to implement the procedure, act all amazed when system does not work. Describes a lot of things besides the US election system.
Why is it again that elections can only be held once every four years and every possible decision must be made at the same time?
So, where's the .bmp I can link to my web site that makes IE5 remotely execute Mozilla Firefox installer?
"Having said that, it looks like the guys doing the testing got their CFLAGS wrong. Gentoo's performance should never be worse than Mandrake -- I reckon they forgot omit-frame-pointer."
That's a big reason why I'd not switch from a binary-distributed OS (I happy with Red Hat, YMMV) to a source-distributed one. Not only is it more convenient to get ready-to-run binaries, but I can actually trust the vendor to have tried to choose a good set of compiler options and to have tested the results, so I don't have to.
Any programmer worth being called one could tell you that -O2 -march=i686 isn't even the beginning of looking for the best optimisation for any piece of software. Dozens of flags affect the output, sometimes there are choices to be made between size vs speed, sometimes "optimize for size" actually produces the fastest code, and so on and so on. And some combinations actually produce buggy results. It's a huge amount of work to find the optimum setting, and the CPU model specific scheduling tweaks enabled by -march=i686 rarely make any difference at all.
I'll stick with binaries someone has tested to work, thanks. Only when I have linking problems or a feature I want had not been included at compile-time do I touch source code.
I've set up several critical server systems to various places using what are now called "consumer-level" Red Hat releases (5.2, 6.2, 7.1, 7.3, none with 8.0 yet), and will probably continue to do so in the future (though not necessarily always when I might have done that before). Here's why:
There's a big difference between a Linux deployment, and a, say Windows 2000 Server or Solaris deployment - Linux is free. Because the software license cost is zero (or at least low in comparison), it often makes sense to deploy two lower-cost machines instead of one bigger, more expensive system, and gain some redundancy in the process.
Now, once you have that redudancy, you can use it to your benefit even while upgrading. Worried that a major Red Hat upgrade, that you have to do because of upcoming EOL, is going to cause problems? No worries. Take one machine offline, test the upgrade there, and continue when you've cleared any problems.
Fact is, it's almost as easy to severely disrupt a business function with a Microsoft service pack installation as it is with a Red Hat major release upgrade. It always boils down to whether you can afford an online backup system or not.
To me, the xfthack results (based on the posted screenshots) look clearly inferior to RH8's stock Xft2 functionality (set to slight hinting, subpixel RGB rendering, to match my LCD panel).
Why? Look at the vertical lines of the fonts: they're not sharp. In fact, the results look more like hinting completely disabled! That I can do myself with a click in the font prefs.
I don't think Xft2 is quite there yet either - some diagonal lines, such as the drop line in 'y' at some sizes of Times New Roman, gets rendered so thinly that it's difficult to see at all. Perhaps that's because I haven't rebuilt Freetype with the bytecode hinter enabled.
Hinting is a difficult issue, and very much related to the resolution of your display. Single words or short phrases (such as titles) always look better without hinting, because (especially with subpixel rendering enabled) the character shapes and spacing is more correct. However, large bodies of text become difficult to read because individual characters are blurred. That's where hinting helps: it subtly changes character spacing and shapes to reduce blur (improve contrast). Text becomes more readable - unless the uneven spacing bugs you more than blurry shapes.
Since we ARE talking about RH8.. RH8 does not have XftConfig, because it's based on fontconfig and uses /etc/fonts/fonts.conf (XML format) instead.
What about JSP? Jetty uses Jasper, like Tomcat, and Jasper has, as far as I've understood, been one of the major roadblocks to Tomcat performance (and the reason Resin is brought up as an alternative). However, I see Jetty 4.1 is using a new Jasper version. What is the performance benefit?
Usually I wouldn't care if an open-source program can be considered an "MS-replacement" or whether it runs on Windows or not, but this time is different, for exactly one reason:
Evolution offers everything Outlook and Eudora does, so switching to it would not be a problem to anyone so inclined. And, it supports encrypted email (PGP/MIME) better than all other email software, so if my friends on Win/Mac could use it too, I wouldn't need to send them plaintext mail.
Ie, this program is not just "as-functional-but-free", but MORE functional than software available on other platforms.
Now, if only it read Outlook calendaring messages without major pain at the Outlook end...
perhaps it's not a lot "in this business", but face it, it is a helluva sum of money. I fail to grasp how NASA can manage to spend $12 million on a "duck-tape" mission. it's not as if they could have refueled the probe or anything, so all that money has went to radio contact, mission planning and reprogramming. Now, assuming that's the cost of the mission since October 1999, when the main mission ended, it's half a million dollars for every month of the continued existence of the probe. Where has it gone? $1000 floppy disks? 50 person full-time ground crew?
Not that I actually need to care since it wasn't me paying for it.
..the problem is, this is the sideline, and the message to the public in the speech itself was about something entirely different.
However, now Mundie writes: "the GPL is intended to build a strong software community at the expense of a strong commercial software business model", and exactly captures the reason why RMS created the GPL in the first place: to create software, business be damned.
Now, why this would be a problem for Microsoft in particular is not explained by Mundie, since nothing forces Microsoft to release their software under the GPL. The point remains that MS is afraid their money-maker (software) is threatened. Not that they wouldn't be able to compete against free software - with their resources, absolutely they can, but because they have no way to crush free software like earlier commercial competition, and not being able to crush the competition forces MS to spend more resources actually competing (ie, spend more money on development and get less revenue from the result) than if free software was not around. That would obviously bother any business executive.
Why it should bother the customer is left unclear.
Fine piece of analysis, too bad the original was flawed.
Huh. There are other update services already, and have been for a long time. autorpm is the first I saw (and tried) - and Ximian's Red Carpet is also perfectly able to provide update services for Red Hat Linux.
e ry =autorpm
http://rpmfind.net/linux/rpm2html/search.php?qu
http://www.ximian.com/apps/redcarpet.php3
VMware lets you consolidate your "got-to-have-these-because-of-MS-licensing" NT/2000 servers into common hardware. You can even host the whole thing on Linux to allow you to more tightly monitor the individual NT processes.
The program supports around a dozen different mailbox formats, easily user selectable with an ~/.imaprc file. Some are just legacy stuff, but a few are clearly suitable in different situations.
I think UW recommends the "mbx" format for most situations - fast, safe in concurrent-access situations, etc. Clearly unlike either UNIX mbox or Qmail maildir.
Of course, if what you REALLY care about is fast IMAP access instead of being able to bypass the IMAP server with client-side solutions, you should look at Cyrus IMAP server as well.
Colin Plumb's shred(1) is part of GNU fileutils 4.0, standard install on Red Hat 6.2. From the info page:
"This uses many overwrite passes, with the data patterns chosen to maximize the damage they do to the old data. While this will work on floppies, the patterns are designed for best effect on hard drives. For more details, see the source code and Peter Gutmann's paper `Secure Deletion of Data from Magnetic and Solid-State Memory', from the
proceedings of the Sixth USENIX Security Symposium (San Jose, California, 22-25 July, 1996)."
Oh yeah. It only uses 70MB after startup, vs. 140MB for Mozilla M16 and 14MB for Netscape Communicator 4.73. ;)
Seriously though, I find Mozilla slightly more responsive than Galeon on my 128MB P2 laptop.
Actually, depending on the range needed, a sail configuration may end up being the fastest method. That's because a big sail can not only produce more push than an ion drive, it will never run out of fuel - so you can accelerate all the way to the halfway point, and then turn around to decelerate (or, on an interstellar trip, perhaps use a magnetic sail to decelerate faster, as someone else pointed out). An ion drive will invariably run out of fuel at some point and then you'll be coasting forever.
The advantage of an ion drive is that it's much smaller - thus easier to deploy (there are several theoretical deployment designs for unfurling sails by rotation, mostly, but such designs add weight, and you want it to be as lightweight as possible to use the push for the cargo, not for the sail), and also independent of remote sources of power (for a solar sail, you lose push and risk destabilizing the sail configuration if your orbit takes you in a shadow of a planet - for microwave mesh sails, you need the microwave transmitter aimed and powering the sail all the time).
Since more than half the score 2+ comments at the time I write this (pretty early into the thread) have totally confused who's who, let's try to explain:
MR GOLD: The plaintiffs' (MPAA/studios) lawyer
MR GARBUS: The defendants' (2600, DeCSS) lawyer, who MPAA has tried to get thrown off the case
MR SCHUMANN: A witness for MPAA.
Since more than half the score 2+ comments at the time I write this (pretty early into the thread) have totally confused who's who, let's try to explain: MR GOLD: The plaintiffs' (MPAA/studios) lawyer MR GARBUS: The defendants' (2600, DeCSS) lawyer, who MPAA has tried to get thrown off the case MR SCHUMANN: A witness for MPAA. Hopefully, now that you know this much, please also realize that lawyers, even smart, good lawyers that might be on YOUR side, don't necessarily know each detail about, for instance, how Linux DVD device drivers interact with the hardware, or that sort of thing. They don't need to, either. What they need to be able to do is to argue their point to a judge who doesn't know that either, and convince him/her that they are right. Thus, it isn't necessarily a failure that they might not get each and every technical detail completely right. And as to trying to get MPAA's witness to provide his computer for evidence, you can bet that the other side would try to do the exact same thing - so why would it not be a valid move for the defendants?
"they"? FYI, the "they" you refer to, the party asking for the hard drive entered as evidence, is Martin Garbus, the defendants' lawyer. Mr. Schumann, the witness being interviewed, is MPAA's witness trying to testify that DeCSS is a piracy tool.
From your attitude and comments I'd guess you think DeCSS shouldn't be under a lawsuit right now. If that's true, your reading of the transcript was TOTALLY off track. If stuff like this is too hard for you to understand, please don't even try, because obviously it only serves to further confuse the issue and cause you to spread misinformation.
Thanks for your efforts benchmarking Java - it was very interesting to me, and I've been thinking of doing similar benchmarks myself. You beat me to the punch!
I ran your code through some tests on my Linux laptop (Mobile Pentium II 400MHz, 128 MB RAM, Red Hat 6.2) using Sun's (Blackdown) JDK 1.2.2 and the 1.3 preview releases from Sun (utilizing HotSpot) and IBM (with their high-performance JIT).
Overall results: compared to un-optimized GCC baseline, IBM's JVM ran 22% faster (while full GCC optimization was only 17% faster than the baseline!). Sun's "stable" 1.2.2 release was 72% slower, and the 1.3 preview (with HotSpot) 17% slower. Interestingly enough, the 1.3 classic JVM was 5 times slower than the 1.2.2 release, so there's probably a huge amount of debugging code in the preview release. Full release might be a totally different story.
Anyhow, bottom line is that the IBM 1.3 JVM runs faster than C, given the type of code in the benchmarks - which, incidentally, is probably algorithmic optimization wise pretty much like most code out there: written in a hurry, and "good enough".