Unofficial Onceoff FAQ to COLDA ;-)
E Pilogue
Learn a powerful editor.
If I could offer you only one tip for the future, learning a
good editor would be it.
The long-term benefits of getting to grips with vim(1) or
emacs(1) have have been demonstrated by hackers and wizards
telnetting in over barbed wire. Mind you, the rest of my advice
isn't too bad either.
I will dispense this advice now.
Don't call your program test. There already exist a standard
program called test. Its name and purpose make perfect sense,
though it does not print output.
Oh, never mind. You will only understand the use of test once
you start using shell scripts.
But trust me, in 20 months time, you'll read c.o.l.d.a and
smile as the new crop of newbies asks why their test program
does not work. If you find another name for your program,
realize that your current working directory is not usually in
your $PATH, so use ./program_name to run it if your shell can
not find it. Alternatively add an export PATH=$PATH:. to your
~/.bashrc or ~/.bash_profile, but be aware of its risks if you
share your box with hostile users.
Don't use IDEs. Or use IDEs but know that most software for
linux gets developed with an editor, gcc, a Makefile and
couple of utilities. This process has worked well and produced
reliable, compact and readable code. Code tied to a particular
IDE can be difficult to read, debug, make contributions to,
distribute, license and maintain especially if the IDE is
redesigned or goes away. Besides, if you want to be taken
seriously when developing for linux, you might as well do it
properly.
Include math.h and link against the library (append a -lm to
the compile/link command) if you use functions like sin().
Read the file COPYING
Don't ignore compiler warnings in your code. Don't put up with
people whose code generates warnings.
-Wall
Don't waste your time on pascal or basic. Usually you'll code
in C, sometimes in shell or lisp. Writing real life software is
tricky and, in the end, you won't want to use a language with
training wheels.
Remember companies who release GPLed code. Forget those whose
licenses don't meet the Debian Free Software Guidelines.
Ignore java. If we succeed in doing this Scott will be hopping
mad.
Keep interesting usenet posts. Throw away your commercial
software.
strace(1)
Don't worry if you can't figure out how to do a task for the
first time. The path to wizardhood involves reading as much
documentation as possible. Consult the manual pages (look in
/usr/man/man3 for clues), the info pages (especially the C
library documentation), the HOWTOs, the RFCs, /usr/doc, old
usenet posts and, most importantly, the source.
Chances are that the bug is in your program and not the
compiler.
Use co -l to keep stable versions around and symlink your RCS
directory into a separate disk. You'll miss your code when its
gone.
Maybe you hold a computing degree, maybe you don't. Maybe you
come from a windoze background, maybe you don't. Maybe you are
new to computers, maybe you have been designing your own VLSI
circuits before breakfast.
Whatever background you come from, be prepared to absorb new
concepts. Linux has benefitted much from the clean design of
unix. Appreciate its beauty.
Enjoy your shell. Use it in every way you can. Don't be afraid
of reading its manual page or of what other people say of it.
It is the greatest human-computer interface built thus far.
Contribute to a linux project, even if it is only an update
to a manual page - it is as easy as mailing a diff(1) to
the author. If you contribute to a project, respect its
conventions, design and coding style, even if you would do it
differently.
Do not read PC magazines, they will only make you feel sick.
Get to know the linux users in your town. You'll never know -
one day they might just offer you a job.
Be nice to your CPU - don't write code which sits in a busy
waiting loop such as while(!kbhit()), it damages multiuser
performance, wastes power and makes you look stupid. Use
select(3) or wait in a blocking read(2) or fread(3) instead.
Avoid signals if you can, and do as little as possible in a
signal handler if you can't.
You probably don't need to use threads.
Understand the advantages of using abstraction libraries such
as ncurses(3). True wizards have several old text terminals at
home and will curse you if you hardcode ANSI escapes into your
output. Consider salvaging some old text terminals of your own.
They are cheap, quiet and invaluable if your X server falls
over.
Work hard to write portable code. Don't assume that an int is
32 bits wide everywhere. Use htons(3) and htonl(3) if you send
binary data across the network or if you write it to disk. Even
better, exchange data in plain text format. Some of the most
widely used protocols like HTTP and FTP operate in plain text.
Check for error return codes. free(3) every bit of memory you
malloc(3), even if your program exits on the next line.
Use a debugger as a last resort, but stop before you forget how
to fix a program by inspection.
Use a fancy software development methodology occasionally, but
stop lest you forget how to program entirely.
Employ people whose work has made it into linux distributions,
avoid those with vendor certifications, especially phony
engineers.
Accept certain inalienable truths:
The Gartner Group's predictions won't materialize. RMS
is wiser than you think. Journalists don't have a clue.
Be careful whose hardware you buy, support those vendors who
provide complete programming documentation. Read the comments in
the driver source to see what the driver author thinks of the
hardware. The biggest brands often build the nastiest hardware.
OZ0GFw6Ik1E
But trust me on the editor.
Robert J. Sprawls
>Lady and gentleman newbies of c.o.l.d.a
[snip]
> Don't ignore compiler warnings in your code. Don't put up with
> people whose code generates warnings.
Then we should all go back to windows. Do you know how many warnings
there are on a kernel recompile? More than I can count on my fingers
and toes. Yet it still works.
> Don't waste your time on pascal or basic. Usually you'll code
> in C, sometimes in shell or lisp. Writing real life software is
> tricky and, in the end, you won't want to use a language with
> training wheels.
C++ is good too, even though for my apps I use ANSI C.
> Remember companies who release GPLed code. Forget those whose
> licenses don't meet the Debian Free Software Guidelines.
Sheeez. Let me state my .02 worth. If a person wishes to sell their
work, that is their choice. If they wish to give it away with source,
that is their choice. To advocate the overthrow of capitalism is
wrong. People have a right to make money off of their hard work, just
like they have the right to donate to the public good. Your just as
bad as B. Gates. You just think in opposite terms. You want to keep
others from making a business developing software for the public and
protecting their work.
And before you flame, I'm working on a matrix and linear algebra
funtions for C/C++ that I intend to release under the GPL. But it is
by choice, not because it is "the proper thing to do". I'm also
working on a client/server game for the public that will be closed
source and sold for profit( the commecial version of the game that is,
and air time on the server ). That is my right.
[snip]
> Do not read PC magazines, they will only make you feel sick.
I read MaximumPC these day. It is an excellent mag. Occasionally they
speak of Linux as an alternative to Windows.
> Employ people whose work has made it into linux distributions,
> avoid those with vendor certifications, especially phony
> engineers.
I'd love to, but everyone wants me to give it away. No one wants to
make money.
Robert
Toby Haynes
> On Thu, 25 Nov 1999 13:06:02 +0000, E Pilogue <pi...@pinet.xx> wrote:
>
>
>
> > Don't ignore compiler warnings in your code. Don't put up with
> > people whose code generates warnings.
>
> there are on a kernel recompile? More than I can count on my fingers
> and toes. Yet it still works.
>
Err - Robert... You may have missed that 'winkey' in the title, and
it's just possible you missed out on a recent single in various charts
with the title of 'Sunscreen' or the book which the single takes its
lyrics from, so you may have missed the fact that this was not
entirely serious. Although the name of the author might have given
that away too...
Smile ...
Cheers,
Toby Hyanes
P.S. Trust me about the editor too ;-)
--
Toby Haynes
The views and opinions expressed in this message are my own, and do
not necessarily reflect those of IBM Canada.
Robert J. Sprawls
>spra...@worldnet.att.net (Robert J. Sprawls) writes:
>> On Thu, 25 Nov 1999 13:06:02 +0000, E Pilogue <pi...@pinet.xx> wrote:
>>
>>
>>
>> > Don't ignore compiler warnings in your code. Don't put up with
>> > people whose code generates warnings.
>>
>> there are on a kernel recompile? More than I can count on my fingers
>> and toes. Yet it still works.
>>
>
>Err - Robert... You may have missed that 'winkey' in the title, and
>it's just possible you missed out on a recent single in various charts
>with the title of 'Sunscreen' or the book which the single takes its
>lyrics from, so you may have missed the fact that this was not
>entirely serious. Although the name of the author might have given
>that away too...
I saw the smiley after I posted and wondered if I had jumped the
gun. As far as the "Sunscreen" I'm afraid I'm not familiar with
that. Oh wait, yes, I think I have heard that. The man who is giving
advise while a melody plays in the background. Never found out the
title or artists name. Well, I guess that'll teach me to post with my
head:(
Robert
David M. Cook
I think your "FAQ" is too opinionated and too free of factual information to
be a true FAQ. For instance, you shouldn't tell people not to use IDEs, you
should just map out the pros and cons of using them.
I see no reason to steer people away from Pascal or Java. The above applies
here.
Dave Cook