Re: Fred Linux Annoyance List.

On Thu, 2003-10-16 at 12:38, Fred P. wrote:
> >I get it.  You're trolling.  You took a C++ class in school and you
> >believed everything you heard and haven't learned anything since.
> 
> I'm programming since 1991, mostly in:
> QB,VB,C,Assembly,C++,Java,Perl,PHP,JavaScript
> and also in
> Ruby,VHDL,Ada,mBed,SALT,CSH,BrainFuck and few others.
> 
> You may also include all HTML, CSS, XML, SVG, XUL
> and the like if you consider them languages...
> 
> BTW, history tells us that taking a C++ class can enhanced your ability
> to code and design proper C struct programs.

True.  I've taught it quite a few times.  But I don't try to teach my
students that C++ is the golden hammer.

> I suggest you read a book called "AntiPatterns",
> it tells you mostly what you shall NEVER do inside a big project no matter 
> the language.

My point is that most projects aren't big.  You were generalizing at the
beginning of this thread.  If you limit your statements to large
projects, they become more lucid.

> >I've been on the Internet since before we called it the Internet,
> 
> I'm on the Internet back then when it was in ANSI text mode... dialup.

Actually, the internet doesn't know anything about your user interface. 
I was referring to when there were networks like NSFNet, MFENet, and
MilNet all tied together (thus the origin of the term internet).

> >and I've seen a lot of strange stuff, but I never thought I would see the 
> >day
> >when someone with a .hotmail.com address would diss someone for having a
> >.gov address.  That has got to be a first!
> 
> >See above comment about the .gov remark (I still don't get that one...)
> 
> I realised that when I ended my email, I just tought you might have work
> on some large scale government research project... hopefully not.
> 
> > > By seeing your comment, I can tell that:
> > >
> > > 1) You hate Microsoft no matter what.
> >
> >Untrue.  I use Visio for diagramming lab setups, and we have windows 2k
> >and xp at home because my kids like the games.
> 
> Okay, but that's not the impresion you gave me in your first reply.
> 
> > > 2) You're a junior programmer that never worked on large scale 
> >production
> > > system,
> > >      I'll be scared to death maintaining it if you ever did !!!
> > >      and you have a .gov addesss HAAAAAA!
> >
> >I've never worked on a large scale production system.  You got me
> >there.  This is a national research lab.  But thanks for playing.
> 
> Linux and X11 is a large scale production system.
> 
> The problems I was mentionning won't happen for "small scale" projects, 
> hacks and stuff like that.
> 
> The problem with large scale system is that it takes years to fully get the 
> big picture,
> since you cannot read the entire code base to verify your patch.
> 
> For instance, let say you read pretty fast let say 36000 LOC per day, that's 
> 13 MLOC per year,
> which means in one year you can read lets say the entire Linux repository.
> How many times you normally read some code to verify changes? 1,2,5,10,20 
> times?
> Which means it would take on average 5 years to change let say your "rect" 
> entity.
> That's why Linus ain't alone working on the code, he can't simply follow 
> everything,
> he simply trust peers and do some small code review, which is normal.

Right.
> > > 3) You have no clue what are proper software engineering techniques,
> > >     I strongly recommend you read a lot on this field.
> >
> >No.  Actually I understand that different projects have different needs. 
> >There are probably even valid reasons to use Visual Basic for some of them. 
> >  Who knows?
> 
> Yes, I agree fully.
> VB is good for small tools, fast prototyped GUI,
> but you feel the "bottleneck" when you try to do advanced stuff,
> that's why I switch to C++ Builder: VB interface, C/C++ power.
> 
> Use proper tools for proper task.
> 
> The point is, in your case, you're telling us that we shouldn't use
> proper techniques to develop large scale system.
No, I didn't.  I said you shouldn't apply large scale techniques to all systems.
If the kernel used get/set paradigm for all data access, it would be
exceedingly slow.

> Have you ever see the coupling analysis of the Linux kernel, it's simply 
> SCARY.
> 
> Windows crash problem due to the same problem, it's just to large and 
> maintaining it is a BIG problem.
> The problem is that old assumption for Windows 16-bit don't work anymore in 
> 32-bit
> and there was tons of coupling to the C API. So they wrote another layer to 
> patch it.
> You end up with a big "stove pipe system" with lots of "lava flow" revision.
> 
> > > 4) I might be clueless for some part of *nix systems,
> > >     but I know far more than anybody I came accross to apart few *nix 
> >gurus/sysadmin.
> >
> >You are.  And you haven't been around anyone good, or you didn't
> >recognize them as such when you were.
> 
> They are some, I said "few"... no more than 20 peoples.
> 
> > > > >      - I don't understand how you can accept patches
> > > > >        that break stuff or doesn't even compile cleanly inside Linus
> > > > > kernel...
> > > >
> > > >You have GOT to be kidding.  I've installed WAY more windows updates
> > > >than Linux security patches.  Linux code is much higher quality than
> > > >microsoft code.
> > >
> > > Non issue. No matter what.
> > > Comparing Linux with microsoft is not a good way to approach such thing.
> > > Comparing Linux with "the perfect sofware goal" is much more 
> >constructive...
> >
> >Hey!  A good point!  That was refreshing.
> 
> Hey, we can agree that's a beginning.
> 
> > > >Did you happen to notice the word "test" in 2.6.test1?  It is unlikely
> > > >that the person who applied the patches could attempt to build the
> > > >kernel with all combinations of options.
> > >
> > > Never heard of regression testing, unit testing and similar?
> > > You apply a patch then you fully test it RIGHT AWAY
> > > before propagating the changes.
> >
> >Check out the .config file for your kernel.  How long would it take to
> >regression check all combinations of options?  That is the point of
> >testing.  At a company, you would do it internally.  With the Linux
> >kernel, we do it as a community.  The maintainer posts the next test
> >version, and we download it and test it on our various machines.
> 
> Ever heard of a compile farm like on Sourceforge ?
> Never heard neither that OSDL has some compile farm also?
> 
> You want to check it, don't forget even thought there's like 1000 config,
> that means that if you patch 1 file, you compile that file 1000 times
> and link the entire thing 1000 times.

Sure, but that's not the development model followed by the Linux
Kernel.  Linus even said once that he never backs up his stuff because
he uses the 'Net for backup.

> > > >That's one good reason to send
> > > >out a test version.  I'm sure that the kernel would have compiled IF 
> >you
> > > >used the same .config file as Linux uses...
> 
> Don't forget this is 2.6-test1, there was like 75 revision in 2.5...

I didn't forget.  It just isn't all that relevant.  If you couldn't
build 2.6.0, you'd have more of a point.

> > > Nope, did you check the statistic, this is daily automatic build.
> > > It was documented in some newspaper, that even at Microsoft,
> > > when someone break the "daily build" they are callable 24/7 to fix it
> > > until it compiles/test properly before the next day.
> >
> >Right.  But there is only one build.  There is no equivalent of the
> >.config file with different options and modules.  AND they are getting
> >paid to carry the pager home.
> 
> Yes, but the entire kernel build stats was for 4-5 different configuration 
> not 1000.
I don't see your point

> > > > 2) Buffer overflows
> > > > >      - Most GNU software still use char* when glibc string_t is out
> > > >there
> > > > > since years... WHY???
> > > > >      - It should be prohibited to use any unsafe str*() calls and 
> >always
> > > >use
> > > > > strn*() variant.
> > > > >      - Any C program should use get/set function to access data
> > > >structure
> > > > > like in C++ or pthread.
> > > >
> > > >C programs should not, in general, use get/set functions.  C is for use
> > > >when you want to be efficient.  Also, get/set functions are used when
> > > >you want to hide the implementation behind an interface.  That isn't
> > > >always desired.
> > >
> > > You have the mentality for the perfect maintenance nightmare!
> > > Imagine you have ~1 million LOC, take X or Linux,
> > > now imagine that everywhere in the code you do rect.x++
> > > now imagine that for some reasons you need to change rect,
> > > to add lets say "persistant object using struct", all reference to 
> >rect.x
> > > must be changed.  If you have a #define or inline function, it requires 
> >one
> > > line of change.
> > > In your case, you must audit all LOC to make sure everything works fine.
> >
> >Imagine that you are writing C code (since that was the subject).  The
> >reference to rect.x would have to be changed because the compiler won't
> >accept rect.x (that is C++).
> 
> That's C straight up.
> 
> typedef struct _rect_t
> {
>    int x,y,w,h;
> } rect_t;
> 
> rect_t rect;
> rect.x++;

D'oh!!!  I lost my mind for a second...

> Now, imagine you have a paint( rect_t* r ) function,
> but for some reasons you need to change the internal to x1,y1,x2,y2
> because you need this BADLY... let say.
> You cannot change the code because everyone use the old API.
> You end up with a stovepipe system that can't be updated...
> because you decided to badly design your system.

The Linux APIs do change.  That's why, for example, device drivers had
to be modified to work with 2.6.

> >Also imagine that your code does NOT have 1 million lines.  OOP is
> >good.  I use it when it is appropriate.
> 
> It's appropriate for medium to large scale system, for small system too.
> Not for quick scripts, shell, utilities.
> Notice perhaps that CPAN is OOP based.
> >However, it isn't always the
> >best tool for the particular job, anymore than you would use a hammer to
> >put a screw in a board.
> 
> It's called the "golden hammer" antipattern.
> 
> >There are a lot of programming languages, and
> >most of them have strengths in some area that makes them ideal for
> >certain tasks.
> 
> Absolutely, that's why I program in more than one language and mix match 
> them.
> 
> > > > > 3) #define inlining sickness
> > > > >      - Xlib comes to mine, stop using #define and use inline
> > > >functions!!!
> > > >
> > > >They both have their purpose.  Plus, Xlib is really old.  Maybe they 
> >didn't
> > > >have inline then?
> > >
> > > No, someone just taught up that it would be nice to #define them,
> > > now X maintainers are complaining about it REALLY REALLY BAD.
> > > See the X fork thread stuff.
> > >
> > > > > 4) code that use TABS => USE 2, 3 or 4 SPACE!
> > > > >      - Tabs aren't compatible, they are from 2,3,4,5,6,7,8,10,12 
> >spaces
> > > > >        they get mix up in different editors and things get messy.
> > > >
> > > >Wrong.  I always use tabs because I like using 2 space indents, but 
> >lots
> > > >of people like different sizes.  All you have to do is tell your editor
> > > >to display tabs as 2 spaces.  Surely your editor can do that!
> > >
> > > I like 2 spaces also, but if I edit a file in emacs, vim, pico/nano,
> > > editplus, notepad, MS edit,
> > > Visual Studio, Borland C++ Builder, you can be sure that any tabs in one 
> >of
> > > them will get screwed:
> > > - Unaligned comments, code, { }, etc.
> >
> >vi will let you change the size of a tab.  Personally I use SciTE.  It
> >does as well.  If you use spaces, you have to edit the code to change
> >the indents.  They only get unaligned when you use spaces sometimes and
> >tabs others, and then change the size of the tabs.
> 
> You don't get it.
> Imagine you have some code from X: using 2 space TABS intend
> but also code from Y: using 3 space TABS intend
> and code from Z: using 4 space TABS intend.
> 
> How the heck you gonna tell your editor to handle that????
> Not only your editor but all editors.
> 
> Now X send code to Y, Y change all the spacing,
> because in his editor TABS are unaligned... you get the idea.
> 
> If everybody use space, we have different indents,
> but at least I can work with many documents at the same time,
> without disalignment.

Actually YOU don't get it.  If they are all tabs (ASCI 9), then, by
definition, they always line up no matter how many spaces you use to
display them.  If you use spaces, then the problem occurs, and its even
worse if you use some tabs and some spaces.

> > > > > 5) put some comments, clear and concise name and coding in english.
> > > >
> > > >Yes.
> > > >
> > > > > 6) Use external i18n translation facilities
> > > >
> > > >That's pretty new.
> > >
> > > Anything similar will do.
> > >
> > > > > USABILITY:
> > > > >
> > > > > 1) Man pages sucks, unreadable, unusable,
> > > > >     you always get the wrong version of what your looking for,
> > > > >     you have to guess which pages is it for that C function since 
> >you
> > > >get
> > > > > that Tcl/Tk manpages.
> > > >
> > > >Try man 3 for c functions.
> > >
> > > That's a pretty geek way of solving an issue.
> >
> >Yeah, only geeks read man pages.  You smart guys can just figure it out
> >from the context.
> 
> I'm tired of trying
> man 3 xyz
> man 2 xyz
> man 1 xyz
> man 5 xyz
> to find the proper version.
> 
> > > > > 2) Some man pages are WAY too long, you scroll for years with 
> >zillions
> > > >of
> > > > > options, gcc comes to mind,
> > > > >     and you cannot find the one you REALLY want.
> > > >
> > > >Either there's too much, or there isn't enough...
> > > >
> > > > > 3) Documentation make it concise lynx compatible HTML style with a
> > > >search
> > > > > engine,
> > > > >     see http://www.qnx.com/developer/docs/
> > > > >
> > > > > 4) No standard GUI, means everybody develop for CONSOLE.
> > > > >
> > > > > 5) ncurse is unfriendly, undocumented and unusable:
> > > > >     - document it and make it friendly.
> > > > >
> > > > > 6) Most applications are simply unusable, undocumented, no proper 
> >error
> > > > > code,
> > > > >     they try to look funny, cartoonish, eye-candy, unknown RTFM
> > > > > feature-based, disturbing, etc.
> > > >
> > > >Windows apps are MUCH more likely to fit this description.
> > >
> > > Any X toolkit, Gnome icons, KDE icons, Windows XP Luna theme comes to 
> >mind.
> > >
> > > > > 7) Most applications are slick BETA version and if you're not happy,
> > > > >     your stupid or just read the damn manual, hey BTW this crapt is
> > > >free!
> > > >
> > > >Untrue.  (p.s.  There is no t in the word crap.)
> > >
> > > Most application, that means including 80% of all unpopular ones...
> >
> >Let's try limiting this to packages in widespread use.  Say those
> >distributed by RedHat, SuSE, and/or Debian.  If you count all of the
> >applications ever written, then your point is valid.  Also, remember,
> >that any package under active development WILL have a Beta version.  But
> >it will also have a stable version as well.
> 
> Hey, even OpenOffice STABLE has known bugs and issues (I wasn't talking 
> about that one tought)
> but most other apps have broken stuff around or usability issues.

and XP had 64000 known bugs when it was released.  

> > > > > 8) First thing you should all know:
> > > > >     If you ever read a software manual,
> > > > >     the application usability interface is broken by definition. 
> >QED.
> > > > >     It should be intuitive for anybody,
> > > > >     even someone who never used a computer before.
> > > > >     Help should be provided without being "invasive" like a clip 
> >thingy,
> > > > >     use beige bubble help, status bar and F1 key.
> > > > > 9) Application should have different user mode:
> > > > >      - Newbie
> > > > >      - Normal
> > > > >      - Expert
> > > > >      - User specify
> > > > >
> > > > > 10) Application should be installed/uninstalled
> > > > >     like ActivePerl console based or Windows add/remove programs.
> > > > >     One click or expert mode, straight-forward usage.
> > > > >     Automatic dependancy resolver.
> > > > >
> > > > > 11) There are tons of version of different applications, but the one 
> >you
> > > > > need doesn't exist,
> > > > >     you get one feature here, one feature there, but most apps don't
> > > >have
> > > > > everything you need.
> > > > >     Some super-duper extremely popular applications are getting 
> >there
> > > > > perhaps.
> > > > >
> > > > > 12) Lost in the wood problem => GNOME/KDE.
> > > > >
> > > > > 13) Most Unix command line are really obscure and clueless, I mean 
> >DOS
> > > >was
> > > > > simple:
> > > > >     copy, del, dir, backup, restore, chdir, rmdir, mkdir, echo, rem,
> > > > > diskcopy
> > > > >
> > > > >     Now ask a newbie what the following means WITHOUT thinking at 
> >all
> > > >(Homer
> > > > > simpsons after 6 beers):
> > > > >     dd, df, ln, ls, su, uname, ld, ldd, xxd, sg, shar
> > > > >
> > > > >     Now ask a newbie what the following alias means without thinking 
> >at
> > > >all:
> > > > >     diskcopy, diskusage, filelink, dir, chuser, printsysinfo, 
> >linker,
> > > > > dllinfo, hexdump, execgroup, shellarchive
> > > > >
> > > > >     Too long to type?
> > > > >     Alias the other way around!!!!
> > > > >     Having a alias dd='diskcopy' that would make way more sense.
> > > > >     BAD BAD BAD UNIX design...
> > > >
> > > >We like it that way.  You can remember the ones you use, and it's no 
> >fun
> > > >to type long commands.
> > >
> > > You don't like long commands, then use alias, I have no problem with 
> >that.
> > > How come all my friends never remember if it's df, dd, du, etc to do 
> >what
> > > they need
> > > even if they did it a weekago, because it's hard to remember! voila.
> >
> >Actually, you don't like short commands, so YOU use alias.  We already
> >have the short commands and we like them very much, thank you.  Unix was
> >designed to be easy to use after you learn it.
> 
> IT'S NOT EASY TO USE, even AFTER you learn it.
> If your head is under the soil and you can't figure that out, let me know.

It's easy for me and for lots of other people.  It's not easy for you. 
But you mostly use Windows.  Windows isn't easy for me.  I'm not used to
it (and its behaviour appears to be just random enough to drive me
insane.  I can't deal with an OS that stops working and you have to
reboot it.  My main linux box at home ran for > 250 days without
rebooting until we had a power failure that lasted longer than my UPS. 
I've never had a windows box run for as long as a month without needing
a reboot).

> >If you optimize the
> >design for people who don't know how to use it, then once they learn,
> >they will be unhappy.
> 
> They won't be unhappy, they'll customize it to fit there needs,
> and they can always rely on the easy long solution of typing extra 
> characters
> if they forgot which alias it was...

If you were right, someone would have written a Unix shell with long
commands a long time ago.  For some reason, that never happened. 
Perhaps you could make that your contribution!

> >It's better this way.  Trust me:-)
> 
> Okay, I gave you an F for Usability 101.
> 
> The client is always right, the programmer is always wrong.
> Make the client happy, unless it doesn't make sense or it's impossible to 
> fabricate.

Actually, the client is often clueless.  That is what makes systems
design so difficult.  The customer thinks he knows what he wants
(duplicate the current functionality), but later becomes certain that he
will know what he wants as soon as he sees it.

> > > >Did you ever use VMS?
> > >
> > > That's a flamebait, saying hey there's WORST, why aren't you happy?
> > > You're not happy with your broken car, hey in my time we used to walk
> > > 3miles in the snow without boots every morning!
> >
> >No, it's an example of just what you proposed.  It is a very well
> >thought-out, consistent, command syntax that uses descriptive names for
> >all of the commands.
> 
> Okay, I never used VMS.
> 
> >Unfortunately, you do a lot of typing.  I prefer
> >the short commands because it's quicker.  But when I switched, I was
> >unhappy with Unix commands for a short time because they were cryptic.
> 
> See? They ARE cryptic, therefore, difficult to learn.
> That's a bad design. You could have a standard set of alias on every Linux 
> system
> for ultra-geeks or the other way around for newbies.

Feel free to create that and make it available.  If people like it
they'll use it.  If not, they won't.  That will tell you the answer to
this question.  I maintain that the fact that no such system exists
after 20+ years of people complaining about the cryptic commands tells
us that they are really OK, once you learn them.  Besides, having a
command named after someone's dog (biff) is cool!

> > > >You could always
> > > >understand what the command would do, it was extremely consistent, but
> > > >it took FOREVER to type long commands.
> > >
> > > Most guru use tons of alias and shell script anyway, so having 10 mores 
> >to
> > > save you typing ain't an issue.
> > >
> > > Hey, I got 300 aliases on my .cshrc and 300 batch file in DOS.
> >
> >And you, being a guru, would know.  I used to do that myself, about 15
> >years ago.  But the problem is that you learn your own personal
> >customized environment, and then when you go to a new machine (not
> >yours) you can't use it because you don't have your 300 line alias
> >file.
> 
> That's why FTP, CD and floppy exists... if not rely on the long command.

That's a pain, but you can do it.  Again, feel free.  But, sadly, there
IS no long command...

> >Most experienced people I know don't have many aliases for this
> >reason.  It is the same reason that I still know vi.  No matter where I
> >go, there is always vi.  I prefer SciTE, but not many other people have
> >it on their machines.
> 
> Now, I know who you are... you're a vi freak, that's why you're so borned.
> vi is completely unusable, trust me.

What does borned mean?  If vi was unusable, noone would use it.  The
fact that lots of people use it means it is usable.  BTW, didn't I say
that I prefer SciTE twice already?

> I rely on pico, else some GUI editor, else emacs else vi.

I used pico back when I used pine for email.  I never learned to like
emacs, not even on VMS (its a REALLY old editor).

> > > > > 1) Unmarketable software, most paying software
> > > > >     are low success see StarOffice vs OpenOffice and similar,
> > > > >     since there is a highly "must get a free clone"
> > > > >     mentality and "paying fee" is wrong.
> > > > >     Therefore, most software lacks good programmers or lobbyist
> > > > >     and most software company are discouraged to produce
> > > > >     applications/games for such platform, where free clone is the 
> >way to
> > > >go.
> > > > >     "Thank you to produce such good software but sorry
> > > > >     I won't give you a dime for using it..." mentality.
> > > >
> > > >I use OpenOffice.  It works for me.
> > >
> > > Not in all case, see StarOffice vs OpenOffice comparision.
> > >
> > > Last time, I tried OO 2 years ago, the excel equivalent was SO unusable.
> >
> >Try it again.  OOo 1.1.0 is much improved.  I hear that the spreadsheet
> >is quite good now (I've never actually used a spreadsheet myself).  If
> >you don't like that one, try gnumeric.  I use OO Writer for papers, OO
> >Draw for diagrams, and OO Impress for presentations.  They all work
> >quite well.
> 
> I'll stick to MS Office, thank you,
> it seems to also works through Wine or something like that.

enjoy it.  Office is good software.

> > > > > 6) Finding what is the damn parameter for that application inside a
> > > >config
> > > > > file is a nightmare.
> > > >
> > > >But you understand the Windows Registry in depth, know what all of the
> > > >parameters are for, and can easily fix it when it gets corrupted.
> > >
> > > In most case, it's straight-forward.
> > > In most case, you don't need any regedit, just use Tools->options...
> > > If you need regedit, it's mostly in HKLM->Software->Company->app
> >
> >But when the registry breaks, you often have to reinstall all of your
> >software or even the entire OS + software packages.
> 
> You never EXPORT regedit the entire registry on C:\backup\yyyymmjj.reg ?
> If it BREAKS you can fall back using DOS, forget WinXP.

Yeah, but I've actually never had that work.  I used to back the
registry up each time I installed software, but it never worked when the
system wouldn't boot and I tried to use the backup registry, so I quit
doing it a couple of years ago.

> >That is the beauty
> >of the config files.  You can always just edit the config file.  You can
> >also boot something like knoppix and mount your disks and fix them that 
> >way.
> 
> You can also boot DOS and fix it also, again WinXP DOS is more primitive 
> than DOS 1.0

They call it DOS, but it's not.
> > > > > 7) Trying to find what's the man page for that damn obscure 
> >parameter
> > > > >      for that application inside a config file is a nightmare.
> > > > >
> > > > > 8) Trying to find all the DLL dependancy for that application,
> > > > >      so I can kill it safely... and reload it is a nightmare.
> > > > >
> > > > > 9) Having more than one DLL version on one system without breaking 
> >all
> > > > > application.
> > > > >
> > > > > 10) Where is it!? /usr/local/bin /usr/bin /bin /opt /opt/bin /home 
> >/var
> > > >/etc
> > > > > /etc/rc.d/
> > > >
> > > >whereis APP or type APP will tell you where it is.  Also try locate 
> >APP.
> > >
> > > Admit, it's stupid. I know the origin of this tree.
> > >
> > > /bin = boot minimum
> > > /usr = mounted server
> > > /usr/local = local mount
> > > /opt = optional mounting stuff
> >
> >You don't like it, but it isn't stupid.  It's just not what you are used
> >to.  I don't care where the app goes.  I put my stuff in the /usr/local
> >tree.  Redhat likes to put everything in /usr.  SuSE puts a lot of stuff
> >in /opt.  I can live with either one.
> 
> The problem is that there should be a standard and all distro use that 
> standard.

There is one.  Not all distros use it.  I believe that SuSE does.

> > > > > 11) In 6 years, I never got one ./configure && make && make install
> > > >working
> > > > > at all.
> > > > >     Mostly fails at configure or make with pages of errors and
> > > >undescribable
> > > > > messages.
> > > > >     It needs to be compiled ==> means I'm screwed if there's no
> > > >package...
> > > >
> > > >Perhaps you are clueless:-)  (sorry, I just couldn't resist).  If you
> > > >don't have the right versions of support packages, that can happen.
> > >
> > > That can happen too many times you mean.
> > > It's like last time I tried to compile Postgres the lastest STABLE 
> >release,
> > > couldn't get it compile, same thing with Perl CPAN module with C stuff.
> >
> >I've done both recently.  I had no problems.  So did you post your
> >errors to the relevant lists?  Both projects have excellent support.
> 
> Couldn't join anybody by IRC/email, btw, it's still broken.

Were you as rude in that case as you have been in this thread?  If so,
that's why you didn't get an answer.

> > > >I usually have a relatively recent RedHat version, and the only 
> >packages
> > > >that I have problems with are new KDE apps, because RH doesn't ship
> > > >recent versions of KDE.
> > >
> > > > > 12) All Linux distribution should be EASY to install, like Knoppix.
> > > > >     It boots, it works, it's configured. No hassle.
> > > > >
> > > > > 13) Most problem with Linux distro including Knoppix,
> > > > >     is that you need BADLY that application unsupported at all on 
> >your
> > > > > distro.
> > > > >     Knoppix cannot really be installed on hard disk... =(
> > > >
> > > >Wrong.  google for this one.  there are a couple of easy ways to do it.
> > >
> > > It's not supported by default, it's a geek-hack, read the website.
> >
> >This is a strange attitude for someone claiming to be a guru
> >programmer...  You have to type  knx-hdinstall and answer a few
> >questions.  That sounds pretty simple to me.
> 
> The latest Knoppix CD, I burn said explicitly in the documentation
> that hdinstall is not supported. anyway, i'll reverify...

There is "supported" and then there is "supported".  Whether you choose
to use it or not, it still works.

> > > > > 14) Application should be easy to configure, intuitive,
> > > > >       self-describing panels like Windows 9x or Mac OS X.
> > > > >     You see it for the first time in your life, and you know
> > > > >     what is what, what does what, and what changes what,
> > > > >     without reading any help files, manuals, documentations or
> > > >whatever...
> > > > >
> > > > >
> > > > > FLEXIBILITY:
> > > > >
> > > > > 1) Micro-kernel like dependancy:
> > > > >     a) update/patch your kernel without rebooting just
> > > > >         (reload it in few microseconds: stop/start like a service)
> > > > >     b) update/patch your device driver without recompiling any 
> >kernel
> > > >source
> > > > > (stop/start)
> > > > >     c) update/patch any library (stop/start)
> > > > >
> > > > >     # kernel --reload  kernel-2.6.0-test6.bin
> > > > >     # kernel --reload  glibc-x.x.x
> > > > >     # kernel --reload  scsi-driver-x.x.x
> > > > >     # kernel --stop    lan-driver-x.x.x
> > > > >     # kernel --start   modem-driver-x.x.x
> > > > >     # kernel --display driver
> > > >
> > > >Most of this is already there.  If you have a driver in a module, you
> > > >can unload it and load the new one (unless it's being used).  Reloading
> > > >a kernel, now that would be a good trick.  I think you are just going 
> >to
> > > >have to reboot for that one.  If you use modules for your drivers, you
> > > >can list them with lsmod.  If you install a new glibc, the programs 
> >that
> > > >are already running will still be linked to the old one, but new
> > > >invocations will use the new one.
> > >
> > > Old invocations will still use the old one,
> > > even though there's a security breach in the library for instance...
> > > and that's why you installed the new version in the first place.
> > > Now you might have apps that break if you use the new version,
> > > again regression testing...
> >
> >So restart the application.  While it would be possible for the
> >application to reload shareable objects before using them on the
> >off-chance that a newer version has been loaded, that isn't a real
> >efficient method.
> 
> Having a mechanism to reload such would be useful,
> especially for highly coupled apps depending on other applications.
> 
As I said, you CAN code your application that way.

> > > > > 2) Have a friendly I/O interface: Game port, Parallel port, Serial 
> >port,
> > > > > Keyboard, Mouse
> > > > >     without ROOT in/out assembly privileges or terrible TTY 
> >interface.
> > > > >     It's horribly complicated in C, now imagine in assembly...
> > > > >
> > > > >     Think /dev/port limited to these with a root:port 770 privilege:
> > > > >       /dev/gameport
> > > > >       /dev/serport
> > > > >       /dev/parport
> > > > >       /dev/kbdport
> > > > >       /dev/mouseport
> > > > >
> > > > >       /dev/sndport
> > > > >       /dev/lanport
> > > > >       /dev/hdport
> > > > >       /dev/fdport
> > > > >
> > > > >     Moreover, it may be nice to assign ACL privilege in the future.
> > > > >     You may want an application to write to parport/serport without
> > > >being
> > > > > root,
> > > > >     for security reasons.
> > > > >
> > > > > 3) Message passing within threads like QNX
> > > > >     (badly needed to replace those UNIX signals crapt).
> > > >Message passing has been a part of linux for many years.  Where have 
> >you
> > > >been?
> > >
> > > Where's your URL link with C code and documentation ?
> >
> >Surely you, being a guru, have read Unix Network Programming, by Stevens
> >(published in 1990).  It's probably the best Unix programming book ever
> >written.  The examples are a bit dated now, as POSIX has been updated,
> >and we don't use K&R C anymore.
> 
> I read those:
> 
> W. Richard Stevens,
> Unix Network Programming: Networking APIs: Sockets and XTI,
> 2nd ed., Vol. 1,
> Prentice-Hall,
> ISBN 0-13-490012-X.
> 
> W. Richard Stevens,
> TCP/IP Illustrated, Volume 1 The Protocols,
> Addison-Wesley Publishing Company,
> ISBN 0-201-63346-9
> 
> W. Richard Stevens,
> TCP/IP Illustrated, Volume 2 The Implementation,
> Addison-Wesley Publishing Company,
> ISBN 0-201-63354-X
> 
> NOT NETWORK PROGRAMMING, NOT PIPE, NOT SOCKETS,
> I'm talking about message passing like in QNX4/6.
> 
> The only thing I could find for Linux is MPI which is a MESS.

You want transparent message passing between different machines?  Try
MOSIX.  There have been many flavors of that over the years, e.g. PVM,
Linda, MPI.  There are also massively parallel machines which use real
shared memory.  MPI works quite well, actually.  You just have to know
what you are doing when you write parallel apps.  It's not as simple as
single-threaded apps.  If you want the app to scale to large systems,
you invariably (unless the problem is trivial, like calculating PI) end
up writing the code for a specific OS/Hardware combination, because they
all work differently.  I assume that's what you mean by a mess.  It is,
however, a fact of life with current technology.

> Sincerely yours,
> Fred.
> 
> _________________________________________________________________
> Protect your PC - get McAfee.com VirusScan Online  
> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> 
> _______________________________________________
> annoyances mailing list
> [email protected]
> http://michelangelo.renaissoft.com/mailman/listinfo/annoyances
-- 
    Lawrence MacIntyre     865.574.8696     [email protected]
               Oak Ridge National Laboratory
High Performance Information Infrastructure Technology Group

_______________________________________________
annoyances mailing list
[email protected]
http://michelangelo.renaissoft.com/mailman/listinfo/annoyances

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA/jtleCNjP8rawCW4RAjUwAJwPYEJwXexthZSYhMMLinGa03W6QACfVj23
KIQqJdDEpMZqSqqzVnyRT4s=
=Pvci
-----END PGP SIGNATURE-----