Re: Total loss with 2.4.0 (release)
> > > > > I think that your linux's partition has not been overwritten, but only the MBR > > > of your disk, so you probably just need to reinstall lilo. Insert your > > > installation bootdisk into your pc, then skip all the setup stuff, but the > > > choose of the partition where you want to install and the source from where > > > you want to install, then select just the lilo configuration (bootconfiguration > > > I mean), complete that step and reboot your machine, lilo will'be there again. Oopts I did this last week (fdisk /mbr doesnt do lilo any good :P) Insert Debian boot cd, boot to install, press Alt f2 Create mountpoint, Mount /dev/hda1, CD to that directory chroot to it, cd into /root and ./.profile (prolly not needed but can be useful sometimes) run lilo. All fixed (except by the time i rebooted my motherboard had commited suicide on me for being so stupid. Im about to go collect the replacement right now :) > > I hate to tell you this, but you couldn't be more wrong. My MBR was > > fine. Lilo was fine and ran fine. The kernel even booted. The problem > > was my ext2 partition was scrambled but good (over 4 hours trying to fix > > it and answer all the questions that fsck threw out). The ext2 drive > > lost a lot of data and suddenly had windows stuff all over it (yes, just > > like Mike, I had ttf fonts and other such things). Argh... Window$, ya gotta love it! > Nobody seems to have discovered the problem yet. It is likely some > race produced by those who have been working on finer-ganularity > locking. If i boot my laptop to windows I have to do a total shutdown befire booting back into windows or else gpm goes all crazy. It occurs to me that maybe OTHER things are going crazy too but are just not doing it as loudly :) I think it would be a good polacy to NOT boot from windows immediatly into Linux without a shutdownn in between (a pain in the ass for sure :) > "Memory is like gasoline. You use it up when you are running. Of > course you get it all back when you reboot..."; Actual explanation > obtained from the Micro$oft help desk. :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Total loss with 2.4.0 (release)
I think that your linux's partition has not been overwritten, but only the MBR of your disk, so you probably just need to reinstall lilo. Insert your installation bootdisk into your pc, then skip all the setup stuff, but the choose of the partition where you want to install and the source from where you want to install, then select just the lilo configuration (bootconfiguration I mean), complete that step and reboot your machine, lilo will'be there again. Oopts I did this last week (fdisk /mbr doesnt do lilo any good :P) Insert Debian boot cd, boot to install, press Alt f2 Create mountpoint, Mount /dev/hda1, CD to that directory chroot to it, cd into /root and ./.profile (prolly not needed but can be useful sometimes) run lilo. All fixed (except by the time i rebooted my motherboard had commited suicide on me for being so stupid. Im about to go collect the replacement right now :) I hate to tell you this, but you couldn't be more wrong. My MBR was fine. Lilo was fine and ran fine. The kernel even booted. The problem was my ext2 partition was scrambled but good (over 4 hours trying to fix it and answer all the questions that fsck threw out). The ext2 drive lost a lot of data and suddenly had windows stuff all over it (yes, just like Mike, I had ttf fonts and other such things). Argh... Window$, ya gotta love it! Nobody seems to have discovered the problem yet. It is likely some race produced by those who have been working on finer-ganularity locking. If i boot my laptop to windows I have to do a total shutdown befire booting back into windows or else gpm goes all crazy. It occurs to me that maybe OTHER things are going crazy too but are just not doing it as loudly :) I think it would be a good polacy to NOT boot from windows immediatly into Linux without a shutdownn in between (a pain in the ass for sure :) "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Coding Style
Ralf Baechle wrote:
>
> On Sun, Jan 21, 2001 at 03:00:05AM +0100, Matthias Andree wrote:
>
> > > int function(int x)
> > > {
> > > body of function// correctly braced and commented :)
> > > }
> >
> > So you claim // is a correct C comment? Poor guy :)
>
> Current drafts of C9X implement // comments; virtually every halfway
> current C compiler I've used during the last years implements it.
>
> Ralf
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
Any plane vanilla C compiler that doesnt support // as a coment is
probably at least 10 years old :) His point wasnt that it wouldnt work,
he was pointing out that this cmmenting style is frowned upon in C.
It is alot neater tho :P~
// even for multi line comments
// no visual clutter over there -->
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Partition IDs in the New World TM
On a system with nothing but linux installed does partitioning slow things down? I have... /dev/hda1 93309 27520 60972 32% / /dev/hda3 2885812 1042304 1696916 39% /usr /dev/hda5 4806904 1989612 2573108 44% /home /dev/hda6 4806904913044 3649676 21% /var /dev/hda7 4806904 1345696 3217024 30% /home/ftp /dev/hda8 4806904 2170136 2392584 48% /home/ftp/debian/dists/potato /dev/hda9 4806904 1352776 3209944 30% /home/ftp/debian/dists/woody /dev/hda10 2284880904832 1263980 42% /home/ftp/debian/pool /dev/hdb1 3844584721632 2927656 20% /home/shared /dev/hdb2 3844616 4092 3645224 1% /home/ftp/debian/dists/sid plus hdb3 not yet mounted anywhere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
Stephen Satchell wrote:
>
> One goal of language designers is to REMOVE the need for comments. With a
this is a crock of (deleted). You are chaising rainbows dood, you will
NEVER remove teh need for comments but its obvious you remove teh
comments.
> good fourth-generation or fifth-generation language, the need for comments
> diminishes to a detailed description of the data sets and any highly
> unusual operations or transforms on the data.
sorry but i could not disagree more
>
> I've even gone so far as to "invent" my own languages, and the parsers to
> go with them, to reduce the need to comment by making the code easy for
> humans to read. Not only are such systems easier to debug (with good
> language design) but are highly maintainable and usually not all that
> difficult to extend when necessary.
no lprogramming anguage can describe describe the design of the
applications written in it. you NEED to comment your code. 100% Self
commenting code is a falacy. 50% self commenting code is almost
impossible to achieve. COMMENT IT!
>
> Remember, the line-by-line commenting requirement was mandatory in
> assembler programming, because the nature of assembler made you outline
> each step by tiring step.
You talk like you dislike assembler as much as i dislike c :)
> When I worked for Rockwell, I was granted a
> partial wavier when I showed them my assembler-language commenting
> style: pseudo-code at the top of each block of assembler code.
very ugly. The S4 meter from landys and gyr (now siemens) actually uses
c code above each assembler routine as a form of commeting. using code
to comment code is fine as long as you COMMENT the comments!
> Comments do NOT make code maintenance easier. Too many comments obscure
> what is really going on.
well... i disagree, years of consulting work and having to deal with
hunks of legacy code with no comments and huge functions etc etc et
(every coders worst nightmare) has taught me that comments are very much
needed (even bad comments are preferable to none at all)
> Linus' style actually increases the
> maintainability of the code, because if the code doesn't accurately show
> how it implements the goal specified in the block comment, the coder hasn't
> done his/her job.
TRUE. Code should be written well enough that it isnt naturally
obfuscated but this does NOT remove the need for comments.
> Want to improve the maintainability of C code? Consider the following:
>
> 1) Keep functional parts small. If the code won't fit in a hundred lines
> or so of code, then you haven't factored the problem well
> enough. Functional parts != functions.
> A program with thousands of
> well-encapsulated function parts strung together into a single function is
> easier to maintain than a "well-factored" program with its parts spread all
> over hell.
Cram a gazillion simple operations into a single function and you end up
with chaos, totally unfactored code is almost impossible to read.
> Diagnostic programmers have learned the hard way that factoring
> a program can make it difficult to ensure test coverage and even more
> difficult to determine if a part of the code is buggy or whether it found a
> hardware error that it was looking for.
then they dont know how to test a program. period
> In my ANSI C code, you will see the following a lot:
>
> #define DO /*syntactic sugar */
>
> DO {
> }
>
> DO {
>}
>
>
> 2) Reduce visual complexity where possible. Instead of using nested
> if-then-else statements, consider unrolling the nested
> statement. Example: {if (a && c)...; if (b && c)...; instead of {if (c)
> {if (a)...; if(b)...;}
which is simpler...
(x + y) ^ 2
or...
(x ^2) + (Y ^2) + 2xy
> 3) Make creative use of a run-on if statement to improve error detection
> and recording. One of my tricks is to code the following statement in
> application programs:
>
> if( (err = "input file can't be opened", in = fopen(filename,
> "rb"), in == NULL)
> || (err = "output file can't be opened", out = fopen(oname, "wb"),
> out = NULL)
> ...
> )
use clever little tricks in your c so as to confuse people ? You are
obviously a very advanced c coder who knows well the intracasies of the
language. The person who has to maintain your code 10 years after you
have left may not be.
>{
>/* report the error that occurred, using the char * variable "err"
> to indicate the exact error. */
>}
granted, the above block of code was not that difficult to understand,
even tho I have never seen that particular trick used before but the
above statement still stands. (nice trick btw :)
> 4) The functional part should be contained in a reasonable number of
> lines. Large while and for loops should call functions instead of having
> bloated bodies. Large case statements should call functions instead of
> running on
Re: [OT?] Coding Style
Stephen Satchell wrote:
One goal of language designers is to REMOVE the need for comments. With a
this is a crock of (deleted). You are chaising rainbows dood, you will
NEVER remove teh need for comments but its obvious you remove teh
comments.
good fourth-generation or fifth-generation language, the need for comments
diminishes to a detailed description of the data sets and any highly
unusual operations or transforms on the data.
sorry but i could not disagree more
I've even gone so far as to "invent" my own languages, and the parsers to
go with them, to reduce the need to comment by making the code easy for
humans to read. Not only are such systems easier to debug (with good
language design) but are highly maintainable and usually not all that
difficult to extend when necessary.
no lprogramming anguage can describe describe the design of the
applications written in it. you NEED to comment your code. 100% Self
commenting code is a falacy. 50% self commenting code is almost
impossible to achieve. COMMENT IT!
Remember, the line-by-line commenting requirement was mandatory in
assembler programming, because the nature of assembler made you outline
each step by tiring step.
You talk like you dislike assembler as much as i dislike c :)
When I worked for Rockwell, I was granted a
partial wavier when I showed them my assembler-language commenting
style: pseudo-code at the top of each block of assembler code.
very ugly. The S4 meter from landys and gyr (now siemens) actually uses
c code above each assembler routine as a form of commeting. using code
to comment code is fine as long as you COMMENT the comments!
Comments do NOT make code maintenance easier. Too many comments obscure
what is really going on.
well... i disagree, years of consulting work and having to deal with
hunks of legacy code with no comments and huge functions etc etc et
(every coders worst nightmare) has taught me that comments are very much
needed (even bad comments are preferable to none at all)
Linus' style actually increases the
maintainability of the code, because if the code doesn't accurately show
how it implements the goal specified in the block comment, the coder hasn't
done his/her job.
TRUE. Code should be written well enough that it isnt naturally
obfuscated but this does NOT remove the need for comments.
Want to improve the maintainability of C code? Consider the following:
1) Keep functional parts small. If the code won't fit in a hundred lines
or so of code, then you haven't factored the problem well
enough. Functional parts != functions.
A program with thousands of
well-encapsulated function parts strung together into a single function is
easier to maintain than a "well-factored" program with its parts spread all
over hell.
Cram a gazillion simple operations into a single function and you end up
with chaos, totally unfactored code is almost impossible to read.
Diagnostic programmers have learned the hard way that factoring
a program can make it difficult to ensure test coverage and even more
difficult to determine if a part of the code is buggy or whether it found a
hardware error that it was looking for.
then they dont know how to test a program. period
In my ANSI C code, you will see the following a lot:
#define DO /*syntactic sugar */
DO {
/* first functional part, with owned variables */
}
DO {
/* next functional part, with its owned variables */
}
2) Reduce visual complexity where possible. Instead of using nested
if-then-else statements, consider unrolling the nested
statement. Example: {if (a c)...; if (b c)...; instead of {if (c)
{if (a)...; if(b)...;}
which is simpler...
(x + y) ^ 2
or...
(x ^2) + (Y ^2) + 2xy
3) Make creative use of a run-on if statement to improve error detection
and recording. One of my tricks is to code the following statement in
application programs:
if( (err = "input file can't be opened", in = fopen(filename,
"rb"), in == NULL)
|| (err = "output file can't be opened", out = fopen(oname, "wb"),
out = NULL)
...
)
use clever little tricks in your c so as to confuse people ? You are
obviously a very advanced c coder who knows well the intracasies of the
language. The person who has to maintain your code 10 years after you
have left may not be.
{
/* report the error that occurred, using the char * variable "err"
to indicate the exact error. */
}
granted, the above block of code was not that difficult to understand,
even tho I have never seen that particular trick used before but the
above statement still stands. (nice trick btw :)
4) The functional part should be contained in a reasonable number of
lines. Large while and for loops should call functions instead of having
bloated bodies. Large case statements should call
Re: Coding Style
Ralf Baechle wrote:
On Sun, Jan 21, 2001 at 03:00:05AM +0100, Matthias Andree wrote:
int function(int x)
{
body of function// correctly braced and commented :)
}
So you claim // is a correct C comment? Poor guy :)
Current drafts of C9X implement // comments; virtually every halfway
current C compiler I've used during the last years implements it.
Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Any plane vanilla C compiler that doesnt support // as a coment is
probably at least 10 years old :) His point wasnt that it wouldnt work,
he was pointing out that this cmmenting style is frowned upon in C.
It is alot neater tho :P~
// even for multi line comments
// no visual clutter over there --
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Coding Style
500 lines of code case 2: // at this point ALL context for the ... 500 lines of code // switch is lost. I.E. unreadable! } Even if its only 9 or 10 lines of code you STILL lose context on the switch statement. Poorly factored code is difficult to read. Very few C coders know how to factor their code well. Chapter 5: Commenting Comments are good, the more you comment your code the better. These comments are not for you, they are for the poor schmuck that has to deal with your scratching later. Never underestimate the stupidity of this guy, don't leave anything to chance. Never assume that HE will understand your logic simply because YOU do. Rationale. If you have thunked about your code enough to comment it then you have thunked about it enough to CODE IT! Chapter 6: You've made a mess of it Just read what Linus wrote. Oh... Linus, its AN infinite number not A infinite number... and erm... what's emacs ?? Chapter 7: Configuration-files Read what Linus wrote here, its a classic example of how to be totally inconsistent. Indentation should be 3 here but 2 there and 8 over there and 10 in this file but don't go over 29 in this file here... DOH! --- Ok.. So I'm a heretic... I admit it! I have never really liked the C language, it seems to me that it has a habit of making ANY idiot think he/she can be a coder. C is an easy language to learn but to be a good C coder takes years of hard study and a TRUE artistic flair for programming. This means that 99% of all C code is JUNK code. Before you all go running for your 1911 45 ACP's and 30-06's Linux is most defiantly in the 1% here, I just don't like the source format :P~ Comments and flames are welcome Mark I Manning IV [EMAIL PROTECTED] ---
Coding Style
es of code case 2: // at this point ALL context for the ... 500 lines of code // switch is lost. I.E. unreadable! } Even if its only 9 or 10 lines of code you STILL lose context on the switch statement. Poorly factored code is difficult to read. Very few C coders know how to factor their code well. Chapter 5: Commenting Comments are good, the more you comment your code the better. These comments are not for you, they are for the poor schmuck that has to deal with your scratching later. Never underestimate the stupidity of this guy, don't leave anything to chance. Never assume that HE will understand your logic simply because YOU do. Rationale. If you have thunked about your code enough to comment it then you have thunked about it enough to CODE IT! Chapter 6: You've made a mess of it Just read what Linus wrote. Oh... Linus, its AN infinite number not A infinite number... and erm... what's emacs ?? Chapter 7: Configuration-files Read what Linus wrote here, its a classic example of how to be totally inconsistent. Indentation should be 3 here but 2 there and 8 over there and 10 in this file but don't go over 29 in this file here... DOH! --- Ok.. So I'm a heretic... I admit it! I have never really liked the C language, it seems to me that it has a habit of making ANY idiot think he/she can be a coder. C is an easy language to learn but to be a good C coder takes years of hard study and a TRUE artistic flair for programming. This means that 99% of all C code is JUNK code. Before you all go running for your 1911 45 ACP's and 30-06's Linux is most defiantly in the 1% here, I just don't like the source format :P~ Comments and flames are welcome.... Mark I Manning IV [EMAIL PROTECTED] ---
