Re: Re: The vi editor causes brain damage
Words by Marc Perkel [Sun, Aug 19, 2007 at 06:22:37AM -0700]: > > --- Willy Tarreau <[EMAIL PROTECTED]> wrote: > > > On Sun, Aug 19, 2007 at 09:15:22AM +0200, Jiri Slaby > > wrote: > > > Marc Perkel napsal(a): > > > > Let me give you and example of the difference > > between > > > > Linux open source world brain damaged thinking > > and > > > > what it's like out here in the real world. > > > > > > > > Go to a directory with 10k files and type: > > > > > > > > rm * > > > > > > > > What do you get? > > > > > > > > /bin/rm: Argument list too long > > > > > > What does this have to do with rm command? > > > > Nothing, and no more with linux development. Marc > > confuses shell and rm. > > Under DOS, when he types "del *", the shell calls > > the builtin function > > "del" and passes it only one argument "*". The del > > function is then > > responsible for iterating through the files using > > getfirst/getnext. > > > > This is also why mostly only builtin shell commands > > support "*", while > > most external commands do not support it, since they > > have to re-implement > > the same code to iterate through the files (try > > "debug c*.com", it will > > not work). > > > > Under unix, the shell resolves "*" and passes the > > 1 file names to > > the "rm" command. Now, execve() may fail because > > 1 names in arguments > > can require too much memory. That's why find and > > xargs were invented! > > > > The solution is easy : find . -maxdepth 1 | xargs rm > > > > So this has nothing to do with rm, nor with rm being > > open-source, and > > even less with rm being written with vi, and Marc's > > rant is totally > > wrong and off-topic. Maybe he was drunk when > > posting, or maybe someone > > used his keyboard to make him look like a complete > > fool. Or maybe he > > really is. > > > > Willy > > (please do not follow up on this OT thread, > > responses to /dev/null) > > > > The important point that you are missing here is that > the Linux world is willing to live with an rm command > that is broken and the Windows and DOS world isn't. > This isn't about the rm command it's about programming > standards. It's about that the Linux community isn't > committed to getting it right. > Yuhu! The rm command isn't broken (nothing is broken related to this). Have you been reading? Can you even (read)? Fscking troll. -- Jose Celestino http://www.msversus.org/ ; http://techp.org/petition/show/1 http://www.vinc17.org/noswpat.en.html "And on the trillionth day, Man created Gods." -- Thomas D. Pate - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: The vi editor causes brain damage
Words by Marc Perkel [Sun, Aug 19, 2007 at 06:22:37AM -0700]: --- Willy Tarreau [EMAIL PROTECTED] wrote: On Sun, Aug 19, 2007 at 09:15:22AM +0200, Jiri Slaby wrote: Marc Perkel napsal(a): Let me give you and example of the difference between Linux open source world brain damaged thinking and what it's like out here in the real world. Go to a directory with 10k files and type: rm * What do you get? /bin/rm: Argument list too long What does this have to do with rm command? Nothing, and no more with linux development. Marc confuses shell and rm. Under DOS, when he types del *, the shell calls the builtin function del and passes it only one argument *. The del function is then responsible for iterating through the files using getfirst/getnext. This is also why mostly only builtin shell commands support *, while most external commands do not support it, since they have to re-implement the same code to iterate through the files (try debug c*.com, it will not work). Under unix, the shell resolves * and passes the 1 file names to the rm command. Now, execve() may fail because 1 names in arguments can require too much memory. That's why find and xargs were invented! The solution is easy : find . -maxdepth 1 | xargs rm So this has nothing to do with rm, nor with rm being open-source, and even less with rm being written with vi, and Marc's rant is totally wrong and off-topic. Maybe he was drunk when posting, or maybe someone used his keyboard to make him look like a complete fool. Or maybe he really is. Willy (please do not follow up on this OT thread, responses to /dev/null) The important point that you are missing here is that the Linux world is willing to live with an rm command that is broken and the Windows and DOS world isn't. This isn't about the rm command it's about programming standards. It's about that the Linux community isn't committed to getting it right. Yuhu! The rm command isn't broken (nothing is broken related to this). Have you been reading? Can you even (read)? Fscking troll. -- Jose Celestino http://www.msversus.org/ ; http://techp.org/petition/show/1 http://www.vinc17.org/noswpat.en.html And on the trillionth day, Man created Gods. -- Thomas D. Pate - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: [announce] Intel announces the PowerTOP utility for Linux
Words by Matt Mackall [Fri, May 11, 2007 at 09:39:05PM -0500]:
> On Sat, May 12, 2007 at 02:40:52AM +0100, Jose Celestino wrote:
> > Words by Matt Mackall [Fri, May 11, 2007 at 07:17:19PM -0500]:
> > > On Fri, May 11, 2007 at 04:07:18PM -0700, Arjan van de Ven wrote:
> > > >
> > > > What's eating the battery life of my laptop? Why isn't it many more
> > > > hours? Which software component causes the most power to be burned?
> > > > These are important questions without a good answer... until now.
> > >
> > > I get:
> > >
> > > No detailed statistics available; please enable the CONFIG_TIMER_STATS
> > > kernel option
> > >
> >
> > Must run as root (rw to /proc/timer_stats is needed).
>
> That file doesn't exist, despite CONFIG_TIMER_STATS being in
> /proc/config.gz.
>
Then again, perhaps you have /proc/tstats instead.
If so apply this (well, you get the idea):
--- powertop/powertop.c 2007-05-12 05:01:15.0 +0100
+++ powertop_new/powertop.c 2007-05-12 05:08:46.0 +0100
@@ -212,8 +212,8 @@
void stop_timerstats(void)
{
FILE *file;
- file = fopen("/proc/timer_stats","w");
- if (!file) {
+ if (!(file = fopen("/proc/timer_stats","w")) &&
+ !(file = fopen("/proc/stats","w")) ) {
nostats = 1;
return;
}
@@ -223,8 +223,8 @@
void start_timerstats(void)
{
FILE *file;
- file = fopen("/proc/timer_stats","w");
- if (!file) {
+ if (!(file = fopen("/proc/timer_stats","w")) &&
+ !(file = fopen("/proc/stats","w")) ) {
nostats = 1;
return;
}
@@ -388,7 +388,7 @@
i = 0;
totalticks = 0;
if (!nostats)
- file = popen("cat /proc/timer_stats | sort -n | tail
-190", "r");
+ file = popen("cat /proc/timer_stats 2>>/dev/null|| cat
/proc/tstats | sort -n | tail -190", "r");
while (file && !feof(file) && i<190) {
char *count, *pid, *process, *func;
int cnt;
--
Jose Celestino
http://www.msversus.org/ ; http://techp.org/petition/show/1
http://www.vinc17.org/noswpat.en.html
"And on the trillionth day, Man created Gods." -- Thomas D. Pate
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [announce] Intel announces the PowerTOP utility for Linux
Words by Matt Mackall [Fri, May 11, 2007 at 07:17:19PM -0500]: > On Fri, May 11, 2007 at 04:07:18PM -0700, Arjan van de Ven wrote: > > > > What's eating the battery life of my laptop? Why isn't it many more > > hours? Which software component causes the most power to be burned? > > These are important questions without a good answer... until now. > > I get: > > No detailed statistics available; please enable the CONFIG_TIMER_STATS > kernel option > Must run as root (rw to /proc/timer_stats is needed). -- Jose Celestino http://www.msversus.org/ ; http://techp.org/petition/show/1 http://www.vinc17.org/noswpat.en.html "And on the trillionth day, Man created Gods." -- Thomas D. Pate - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [announce] Intel announces the PowerTOP utility for Linux
Words by Matt Mackall [Fri, May 11, 2007 at 07:17:19PM -0500]: On Fri, May 11, 2007 at 04:07:18PM -0700, Arjan van de Ven wrote: What's eating the battery life of my laptop? Why isn't it many more hours? Which software component causes the most power to be burned? These are important questions without a good answer... until now. I get: No detailed statistics available; please enable the CONFIG_TIMER_STATS kernel option Must run as root (rw to /proc/timer_stats is needed). -- Jose Celestino http://www.msversus.org/ ; http://techp.org/petition/show/1 http://www.vinc17.org/noswpat.en.html And on the trillionth day, Man created Gods. -- Thomas D. Pate - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: [announce] Intel announces the PowerTOP utility for Linux
Words by Matt Mackall [Fri, May 11, 2007 at 09:39:05PM -0500]:
On Sat, May 12, 2007 at 02:40:52AM +0100, Jose Celestino wrote:
Words by Matt Mackall [Fri, May 11, 2007 at 07:17:19PM -0500]:
On Fri, May 11, 2007 at 04:07:18PM -0700, Arjan van de Ven wrote:
What's eating the battery life of my laptop? Why isn't it many more
hours? Which software component causes the most power to be burned?
These are important questions without a good answer... until now.
I get:
No detailed statistics available; please enable the CONFIG_TIMER_STATS
kernel option
Must run as root (rw to /proc/timer_stats is needed).
That file doesn't exist, despite CONFIG_TIMER_STATS being in
/proc/config.gz.
Then again, perhaps you have /proc/tstats instead.
If so apply this (well, you get the idea):
--- powertop/powertop.c 2007-05-12 05:01:15.0 +0100
+++ powertop_new/powertop.c 2007-05-12 05:08:46.0 +0100
@@ -212,8 +212,8 @@
void stop_timerstats(void)
{
FILE *file;
- file = fopen(/proc/timer_stats,w);
- if (!file) {
+ if (!(file = fopen(/proc/timer_stats,w))
+ !(file = fopen(/proc/stats,w)) ) {
nostats = 1;
return;
}
@@ -223,8 +223,8 @@
void start_timerstats(void)
{
FILE *file;
- file = fopen(/proc/timer_stats,w);
- if (!file) {
+ if (!(file = fopen(/proc/timer_stats,w))
+ !(file = fopen(/proc/stats,w)) ) {
nostats = 1;
return;
}
@@ -388,7 +388,7 @@
i = 0;
totalticks = 0;
if (!nostats)
- file = popen(cat /proc/timer_stats | sort -n | tail
-190, r);
+ file = popen(cat /proc/timer_stats 2/dev/null|| cat
/proc/tstats | sort -n | tail -190, r);
while (file !feof(file) i190) {
char *count, *pid, *process, *func;
int cnt;
--
Jose Celestino
http://www.msversus.org/ ; http://techp.org/petition/show/1
http://www.vinc17.org/noswpat.en.html
And on the trillionth day, Man created Gods. -- Thomas D. Pate
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Reiser4. BEST FILESYSTEM EVER.
Words by [EMAIL PROTECTED] [Sat, Apr 07, 2007 at 09:13:32PM -0700]: > Teddy, > > It is a pity you don't address the full set of results, when you make > your snide comments. > > Now since you have them,... why don't you make reasoned comment about > them. > > You can read more here: > John, it is not because you keep posting the same numbers over and over again (or is this your new signature?) that they will be more substantiated (hint: cpu usage). Just more annoying each time. I'll remember to use reiser4 for my 90-percent-zero-files-no-need-for-proven-robustness-and-plenty-of-cpu-to-spare boxes. Thank you. > http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm > > .-. > | FILESYSTEM | TIME |DISK | > | TYPE |(secs)|USAGE| > .-. > |REISER4 lzo | 1938 | 278 | > |REISER4 gzip| 2295 | 213 | > |REISER4 | 3462 | 692 | > |EXT2| 4092 | 816 | > |JFS | 4225 | 806 | > |EXT4| 4408 | 816 | > |EXT3| 4421 | 816 | > |XFS | 4625 | 779 | > |REISER3 | 6178 | 793 | > |FAT32 |12342 | 988 | > |NTFS-3g |10414 | 772 | > .-. > > > Column one measures the time taken to complete the bonnie++ benchmarking > test (run with the parameters bonnie++ -n128:128k:0) > > Column two, Disk Usage: measures the amount of disk used to store 655MB > of raw data (which was 3 different copies of the Linux kernel sources). > > OR LOOK AT THE FULL RESULTS: > > .-. > |File |Disk |Copy |Copy |Tar |Unzip| Del | > |System |Usage|655MB|655MB|Gzip |UnTar| 2.5 | > |Type | (MB)| (1) | (2) |655MB|655MB| Gig | > .-. > |REISER4 gzip | 213 | 148 | 68 | 83 | 48 | 70 | > |REISER4 lzo | 278 | 138 | 56 | 80 | 34 | 84 | > |REISER4 tails| 673 | 148 | 63 | 78 | 33 | 65 | > |REISER4 | 692 | 148 | 55 | 67 | 25 | 56 | > |NTFS3g | 772 |1333 |1426 | 585 | 767 | 194 | > |NTFS | 779 | 781 | 173 | X | X | X | > |REISER3 | 793 | 184 | 98 | 85 | 63 | 22 | > |XFS | 799 | 220 | 173 | 119 | 90 | 106 | > |JFS | 806 | 228 | 202 | 95 | 97 | 127 | > |EXT4 extents | 806 | 162 | 55 | 69 | 36 | 32 | > |EXT4 default | 816 | 174 | 70 | 74 | 42 | 50 | > |EXT3 | 816 | 182 | 74 | 73 | 43 | 51 | > |EXT2 | 816 | 201 | 82 | 73 | 39 | 67 | > |FAT32| 988 | 253 | 158 | 118 | 81 | 95 | > .-. > > > Each test was preformed 5 times and the average value recorded. > Disk Usage: The amount of disk used to store the data (which was 3 > different copies of the Linux kernel sources). > The raw data (without filesystem meta-data, block alignment wastage, > etc) was 655MB. > Copy 655MB (1): Copy the data over a partition boundary. > Copy 655MB (2): Copy the data within a partition. > Tar Gzip 655MB: Tar and Gzip the data. > Unzip UnTar 655MB: UnGzip and UnTar the data. > Del 2.5 Gig: Delete everything just written (about 2.5 Gig). > > > To get a feel for the performance increases that can be achieved by > using compression, we look at the total time (in seconds) to run the > test: > > bonnie++ -n128:128k:0 (bonnie++ is Version 1.93c) > > .---. > | FILESYSTEM | TIME | > .---. > |REISER4 lzo | 1938| > |REISER4 gzip| 2295| > |REISER4 | 3462| > |EXT4| 4408| > |EXT2| 4092| > |JFS | 4225| > |EXT3| 4421| > |XFS | 4625| > |REISER3 | 6178| > |FAT32 | 12342| > |NTFS-3g |>10414| > .---. > > > > On Sat, 7 Apr 2007 22:56:32 -0400, "Theodore Tso" <[EMAIL PROTECTED]> said: > > On Sat, Apr 07, 2007 at 05:44:57PM -0700, [EMAIL PROTECTED] > > wrote: > > > To get a feel for the performance increases that can be achieved by > > > using compression, we look at the total time (in seconds) to run the > > > test: > > > > You mean the performance increases of writing a file which is mostly > > all zero's? Yawn..... > > > > - Ted > -- > > [EMAIL PROTECTED] > > -- > http://www.fastmail.fm - IMAP accessible web-mail > > - > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jose Celestino http://www.msversus.org/
Re: Reiser4. BEST FILESYSTEM EVER.
Words by [EMAIL PROTECTED] [Sat, Apr 07, 2007 at 09:13:32PM -0700]: Teddy, It is a pity you don't address the full set of results, when you make your snide comments. Now since you have them,... why don't you make reasoned comment about them. You can read more here: John, it is not because you keep posting the same numbers over and over again (or is this your new signature?) that they will be more substantiated (hint: cpu usage). Just more annoying each time. I'll remember to use reiser4 for my 90-percent-zero-files-no-need-for-proven-robustness-and-plenty-of-cpu-to-spare boxes. Thank you. http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm .-. | FILESYSTEM | TIME |DISK | | TYPE |(secs)|USAGE| .-. |REISER4 lzo | 1938 | 278 | |REISER4 gzip| 2295 | 213 | |REISER4 | 3462 | 692 | |EXT2| 4092 | 816 | |JFS | 4225 | 806 | |EXT4| 4408 | 816 | |EXT3| 4421 | 816 | |XFS | 4625 | 779 | |REISER3 | 6178 | 793 | |FAT32 |12342 | 988 | |NTFS-3g |10414 | 772 | .-. Column one measures the time taken to complete the bonnie++ benchmarking test (run with the parameters bonnie++ -n128:128k:0) Column two, Disk Usage: measures the amount of disk used to store 655MB of raw data (which was 3 different copies of the Linux kernel sources). OR LOOK AT THE FULL RESULTS: .-. |File |Disk |Copy |Copy |Tar |Unzip| Del | |System |Usage|655MB|655MB|Gzip |UnTar| 2.5 | |Type | (MB)| (1) | (2) |655MB|655MB| Gig | .-. |REISER4 gzip | 213 | 148 | 68 | 83 | 48 | 70 | |REISER4 lzo | 278 | 138 | 56 | 80 | 34 | 84 | |REISER4 tails| 673 | 148 | 63 | 78 | 33 | 65 | |REISER4 | 692 | 148 | 55 | 67 | 25 | 56 | |NTFS3g | 772 |1333 |1426 | 585 | 767 | 194 | |NTFS | 779 | 781 | 173 | X | X | X | |REISER3 | 793 | 184 | 98 | 85 | 63 | 22 | |XFS | 799 | 220 | 173 | 119 | 90 | 106 | |JFS | 806 | 228 | 202 | 95 | 97 | 127 | |EXT4 extents | 806 | 162 | 55 | 69 | 36 | 32 | |EXT4 default | 816 | 174 | 70 | 74 | 42 | 50 | |EXT3 | 816 | 182 | 74 | 73 | 43 | 51 | |EXT2 | 816 | 201 | 82 | 73 | 39 | 67 | |FAT32| 988 | 253 | 158 | 118 | 81 | 95 | .-. Each test was preformed 5 times and the average value recorded. Disk Usage: The amount of disk used to store the data (which was 3 different copies of the Linux kernel sources). The raw data (without filesystem meta-data, block alignment wastage, etc) was 655MB. Copy 655MB (1): Copy the data over a partition boundary. Copy 655MB (2): Copy the data within a partition. Tar Gzip 655MB: Tar and Gzip the data. Unzip UnTar 655MB: UnGzip and UnTar the data. Del 2.5 Gig: Delete everything just written (about 2.5 Gig). To get a feel for the performance increases that can be achieved by using compression, we look at the total time (in seconds) to run the test: bonnie++ -n128:128k:0 (bonnie++ is Version 1.93c) .---. | FILESYSTEM | TIME | .---. |REISER4 lzo | 1938| |REISER4 gzip| 2295| |REISER4 | 3462| |EXT4| 4408| |EXT2| 4092| |JFS | 4225| |EXT3| 4421| |XFS | 4625| |REISER3 | 6178| |FAT32 | 12342| |NTFS-3g |10414| .---. On Sat, 7 Apr 2007 22:56:32 -0400, Theodore Tso [EMAIL PROTECTED] said: On Sat, Apr 07, 2007 at 05:44:57PM -0700, [EMAIL PROTECTED] wrote: To get a feel for the performance increases that can be achieved by using compression, we look at the total time (in seconds) to run the test: You mean the performance increases of writing a file which is mostly all zero's? Yawn. - Ted -- [EMAIL PROTECTED] -- http://www.fastmail.fm - IMAP accessible web-mail - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jose Celestino http://www.msversus.org/ ; http://techp.org/petition/show/1 http://www.vinc17.org/noswpat.en.html And on the trillionth day, Man created Gods. -- Thomas D. Pate - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
