Linux-Development-Sys Digest #884, Volume #6     Fri, 25 Jun 99 13:14:23 EDT

Contents:
  Re: Why not C++ (Bruce Hoult)
  Re: TAO: the ultimate OS (The Ghost In The Machine)
  Re: Configuration as Database (was Re: TAO: the ultimate OS) (void)
  Re: TAO: the ultimate OS (Donal K. Fellows)
  Re: TAO: the ultimate OS (void)
  Re: TAO: the ultimate OS (void)
  Re: Why we are still holding on to X Windows (John McDonald, Jr.)
  Re: Why we are still holding on to X Windows (John McDonald, Jr.)
  Re: TAO: the ultimate OS (void)
  Re: Why not C++ (John Jensen)
  Re: TAO: the ultimate OS (Terry Murphy)
  Re: TAO: the ultimate OS (Terry Murphy)
  Framebuffer device why doesn't it work? - again.... (Craig Graham)
  Re: TAPOs: configurations (Alexander Viro)
  Re: Why not C++ (John E. Davis)

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (Bruce Hoult)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Sat, 26 Jun 1999 00:58:04 +1200

Forgot to include the test run output...

[bruce@sparky closure]$ ./testclosure
Values of closure variables = 135,5 and 23,2
[bruce@sparky closure]$

------------------------------

From: [EMAIL PROTECTED] (The Ghost In The Machine)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Fri, 25 Jun 1999 14:43:47 GMT

On Wed, 23 Jun 1999 17:21:57 -0600, Bill Anderson <[EMAIL PROTECTED]> wrote:
>"Vladimir Z. Nuri" wrote:
>> 
>> Christopher B. Browne ([EMAIL PROTECTED]) wrote:
>> 
>> : The advantage to the "lack" of forced support is that it doesn't force
>> : people into a particular approach by making it permeate the kernel.
>> : Supposing there was, in the Linux kernel, a record-oriented DB scheme not
>> : unlike the (boo, hiss!) "Windows Registry," people would be encouraged to
>> : push things into The Database that don't fit properly.
>> 
>> I don't understand the implied comparison of the registry to SQL or other
>> databases.. it seems to me they are fundamentally designed to accomplish
>> different means.. the registry is just "program data/parameters"..
>> databases are general purpose /high performance
>> data holders/indexers/sorters/retrievers etc.
>> 
>> also: I don't like the windows registry implementation either (have
>> had my share of its incredibly awkward interface), but I think
>> the overall idea of the OS imposing a sort of ordering on the way that
>> apps store their data is appropriate...
>
>An OS should not dictate how a random app stores it's data.

Too late; most operating systems do just that. :-)

In particular, the file system (usually part of an OS)
specifies where such things as file names, data blocks,
and other data such as permissions is stored.  Coupled
with the implementation code deep within the OS for
allocation, the OS specifies, in grotesque detail
(at least at the software level) [*] exactly where
a random app stores its data -- and the random
app doesn't care!

Similarly, the registry stores random data from an app,
which still doesn't care how it's stored -- it just goes
through the procedural interface.

Unfortunately for Windows, the central registry is A Bad Idea,
because, if the OS decides to corrupt its data, the
registry is pure binary, and NT doesn't provide
tools for fixing it.  At least with a text file,
one can go in and edit the text file with
a text editor.

(File system corruption can happen, on very rare occasions,
on Unix, if there's a bug in the file system driver -- however,
Unix now provides tools to fix corruption such as 'fsck'.
(Also, e2fs has a tool called 'debugfs' (why that and
not 'debuge2fs', I don't know) which allows for
repair of the file system, and maybe debugging of the code
in the OS managing it -- by setting up "test cases".)

(Another side issue: my understanding is that many large data
retrieval systems will eschew the file system completely, preferring
that the administrator install the database, not in a large data file,
but on its own partition.  The data retrieval system bypasses part
of the OS (it still needs the bit that actually schedules reads
and writes to the disk), and can more accurately control where data
is placed, to attempt to optimize access thereto.)

> 
>> question for you: would there be a way to implement the registry in
>> a more streamlined way in which you wouldnt "boo hiss" it.. also for what
>> reasons are you "boo hissing" it?
>
>
>A few reasons:
>o A failure of a proprietary, binary dataset results in total system
>failure. Solution: reinstall OS.
>o In order to fix it, it needs to have a running system with full a
>toolsuite.
>o Buggy
>o Instable
>o Overly Complex
>
>Just off the top.

Agreed. :-)

I do wonder why Win95 went to the All-In-One-Binary solution.
I guess too many were complaining to MS about all of those .ini
files.  :-)  (Now MS can listen to everyone complaining
about that registry. :-) )

[.sigsnip]

[*] For various complicated reasons, the OS can only specify
    the logical block number upon which a piece of data is stored.
    This LBN is fed to the I/O card or on-board interface,
    and then to the disk drive, which is free to do what it wants
    at that point (as long as the OS can fetch the same block
    later :-) ).  Many SCSI drives, for instance, allow
    remapping around a bad spot, using a pool of blocks near
    the end of the drive specifically for that purpose.
    One may lose performance, but one won't lose data.
    (I don't know if EIDE has a similar capability.)

    Many modern disks store more data on a physical cylinder
    on the outer cylinder than on the inner cylinder;
    simple geometry shows why.  Of course this bedevils
    any software that tries to optimize disk access.

    It gets even more fun because the I/O card can
    accept the LBN in (cylinder, head, sector) form
    (because of the BIOS) and the I/O card can play
    all sorts of games -- and many do! -- to work around
    the 1,024 cylinder limit present in older BIOSes.
    (I don't think that limitation is present anymore,
    but my BIOSes are not all that new. :-) )

----
[EMAIL PROTECTED]

------------------------------

From: [EMAIL PROTECTED] (void)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Configuration as Database (was Re: TAO: the ultimate OS)
Date: 25 Jun 1999 14:50:51 GMT

On Fri, 25 Jun 1999 04:59:48 GMT, Christopher B. Browne
<[EMAIL PROTECTED]> wrote:
>
>(Aside: The RISKS digest recently reported that an analysis of inaccessable
>code and objects in REGEDIT results in them finding that most of the binary
>material isn't necessary, and furthermore locates things like unused icons
>and menus that got defined multiple times by some MS IDE tool that then just
>left this code in.  If they wrote a "code shaker" like Common Lisp vendors
>do, it is entirely possible that most of the bloat in a whole lot of MS
>utilities could go away.  Of course, then Samsung, Seagate, and Western
>Digital would send in hit men to kill the manager responsible for cutting
>down on their sales :-).)

I believe it was actually regclean, not regedit -- a minor point.  About
code shakers: if that is what I think it is, it's part of the
functionality in Sun's HotJava product.

-- 
 Ben

"The world is conspiring in your favor."  -- de la Vega

------------------------------

From: [EMAIL PROTECTED] (Donal K. Fellows)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 25 Jun 1999 13:34:41 GMT

In article <7kuue9$qt5$[EMAIL PROTECTED]>,
Terry Murphy <[EMAIL PROTECTED]> wrote:
> Donal K. Fellows <[EMAIL PROTECTED]> wrote:
>> I suspect that the design->code and edit->compile->test paradigms are
>> tuned towards tackling separate problems...
>> 
>> (Has anyone developed a commercial OS yet using a proper formal design
>> technique?  Or are those only ever used in the safety-critical domain?)
> 
> As I said in a different post, VMS was developed this way, assuming it 
> was designed in the same manner DEC designed all of its other software
> (and it feels like it was too) Though it does have a pretty big niche in
> the safety-critical domain, so maybe it doesn't count.

My feeling is that d->c is more useful when the overall deliverable
system spec. is known already (safety critical systems definitely come
under this heading) whereas e->c->t is better tuned towards ensuring a
particular piece of code meets some pre-existing specification.

Unix has such semi-formal specs now (the POSIX stuff.)  It didn't
always (early versions were probably based on people's feeling for
what is a good idea and what isn't..  :^)

I know the theory of evolving *formal* specifications is not entirely
understood yet; I work with people researching in that sort of area
(though I'm more focussed towards hardware verification...)

Donal.
-- 
Donal K. Fellows    http://www.cs.man.ac.uk/~fellowsd/    [EMAIL PROTECTED]
-- The small advantage of not having California being part of my country would
   be overweighed by having California as a heavily-armed rabid weasel on our
   borders.  -- David Parsons  <o r c @ p e l l . p o r t l a n d . o r . u s>

------------------------------

From: [EMAIL PROTECTED] (void)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 25 Jun 1999 14:55:10 GMT

On 25 Jun 1999 05:06:52 GMT, Terry Murphy <[EMAIL PROTECTED]> wrote:
>
>[I]t's hard to get pointy haired managers to
>buy a systems which doesn't conform to the "P" word.

They seem to like NT well enough.

-- 
 Ben

"The world is conspiring in your favor."  -- de la Vega

------------------------------

From: [EMAIL PROTECTED] (void)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 25 Jun 1999 15:06:04 GMT

On 25 Jun 1999 05:20:20 GMT, Terry Murphy <[EMAIL PROTECTED]> wrote:
>
>Coda is totally different -- it's a university research project. It
>does not at all follow the form of ESR's software development model.
>I am not familiar with the others, but they do not sound like large 
>products.

ESR is irrelevant.  University research and open source overlap heavily
-- my favorite open codebase is BSD, and I also use X, Mach, etc.

>>Linux and linux-oriented communities are far from the be-all and end-all
>>of open source computing.
>
>Then who is? Linux is by and away the most visible.

I don't know too much about the Linux development process, but I've been
an avid observer of the FreeBSD development process for some time, and I
see no shortage of rigorous engineering.

>>Criminy, you're using Microsoft as a paradigm of software engineering?
>>That's truly perverse.
>
>I said "reasonably close". As I said in my other follow-up, most people
>think their applications are top notch, and those in products where you
>whip out VI and start hacking. Microsoft's development system amazes me
>in how fast they are able to turn out high quality and well tested products.

Well, I'll take those one by one.  Microsoft is not reasonably close to
a paradigm of good software engineering; they're reasonably close to a
paradigm of *bad* software engineering, as evidenced by the miserable
reliability, scalability, security, and (wait for it) timeliness of
their releases.

I don't know about "most people" thinking that MS's apps are top notch.
That is an unsupported assertion, and even if it is true, most people
don't know their ass from their elbow when it comes to software.

As for "high quality and well tested products" ... well, it's clear to
me that we live in entirely separate universes, or perhaps we speak
different variants of English.  That statement is irreconcilable with
what I perceive as reality, no matter how I interpret it.

-- 
 Ben

"The world is conspiring in your favor."  -- de la Vega

------------------------------

From: [EMAIL PROTECTED] (John McDonald, Jr.)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: Why we are still holding on to X Windows
Date: Fri, 25 Jun 1999 14:20:25 GMT

On 24 Jun 1999 15:22:49 -0400, [EMAIL PROTECTED] (Paul D. Smith)
wrote:


>There is no "Gnome window manager".  Gnome is, as I said, a desktop
>environment.  That is, it tries to provide a complete desktop including
>window manager, file manager, button bar thingy, configuration tools,
>screensaver/wallpaper chooser thingies, etc.  So, one of the elements of
>Gnome (and KDE) is a window manager, which is just the thing that puts
>borders around windows, lets you resize them, handles keyboard focus,
>etc.

        Now I've gotten it.  I simply wasn't making the distinction
between the desktop and the WM.  I was thinking that they were one and
the same, (as they are in Winblows.)

Groovy, baby. Thanks for clarifying!


[-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-]
 John K. McDonald, Jr.      Alcatel, USA

 [EMAIL PROTECTED]
 please remove -delete- for responses.
 --
 "I speak for me and not this company"

 TO SPAMMERS:
 Please  view   the  definitions   for 
 "telephone     facsimile    machine," 
 "unsolicted  advertisement,"  and the
 prohibition  and penalty  for sending
 unsolicited faxes before sending  Un-
 solicited  Commercial   E-mail to the 
 above   address.   Violators  WILL BE 
 PROSECUTED.   These   can   be  found
 in:
 
 The Telephone Consumer Protection Act
 of  1991,    Title   47,   Chapter 5,
 Subchapter II, Section 227.
[=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=]

------------------------------

From: [EMAIL PROTECTED] (John McDonald, Jr.)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: Why we are still holding on to X Windows
Date: Thu, 24 Jun 1999 18:38:56 GMT

On 24 Jun 1999 11:57:18 -0400, [EMAIL PROTECTED] (Paul D. Smith)
wrote:

>%% Greg de Freitas <[EMAIL PROTECTED]> writes:
>
>  gdf> I run Debian/potato w/KDE. not a problem.
>  gdf> I wish to _try_ gnome, what is gnome, where does it 'fit'? will I
>  gdf> still have Xserver? KDE? if so, _WHY_ would I want to squeeze
>  gdf> another layer in between ?  When I first heard about gnome, I
>  gdf> _thought_ it was a _replacement_ for X.  apparently, it isn't (is
>  gdf> it ?).
>
>No.  You're really confused.
        Okay.. I'm really confused too, then.
The way I figured out what was going on I felt that GNOME provided
another layer of abstraction as well. Because in actuality, I'm using
the Enlightenment WM, not GNOME. (AFAICT) The two have different
Config managers and what not, and it seems like the GNOME
configuration manager allows me to switch between other GNOME WMs
without restarting the X server.  Also, with the GNOME config manager,
I can call up any GNOME WM configuration program, but not the other
way around. 

>Gnome is a replacement, or alternative, to KDE.  It's not a replacement
>for X.  It's not a layer between KDE and X.  You would probably find all
>this info, and more, at http://www.gnome.org and be much less confused.

I realize that X is still the server, and that window managers use the
abstractions that X provides to interact with hardware.  Also, I know
that Gnome is not a layer between KDE and X.  But I was under the
impression that Gnome WAS a layer between Enlightenment and X, or any
other WMs that chose to use the GNOME tools, etc... Perhaps I should
go read the webpage, unless someone wants to explain this further.

Oh well, thanks!

[-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-]
 John K. McDonald, Jr.      Alcatel, USA

 [EMAIL PROTECTED]
 please remove -delete- for responses.
 --
 "I speak for me and not this company"

 TO SPAMMERS:
 Please  view   the  definitions   for 
 "telephone     facsimile    machine," 
 "unsolicted  advertisement,"  and the
 prohibition  and penalty  for sending
 unsolicited faxes before sending  Un-
 solicited  Commercial   E-mail to the 
 above   address.   Violators  WILL BE 
 PROSECUTED.   These   can   be  found
 in:
 
 The Telephone Consumer Protection Act
 of  1991,    Title   47,   Chapter 5,
 Subchapter II, Section 227.
[=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=]

------------------------------

From: [EMAIL PROTECTED] (void)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 25 Jun 1999 15:11:40 GMT

On Fri, 25 Jun 1999 14:43:47 GMT, The Ghost In The Machine
<[EMAIL PROTECTED]> wrote:
>On Wed, 23 Jun 1999 17:21:57 -0600, Bill Anderson <[EMAIL PROTECTED]>
>wrote:
>>
>>An OS should not dictate how a random app stores it's data.
>
>Too late; most operating systems do just that. :-)
>
>In particular, the file system (usually part of an OS)
>specifies where such things as file names, data blocks,
>and other data such as permissions is stored.  Coupled
>with the implementation code deep within the OS for
>allocation, the OS specifies, in grotesque detail
>(at least at the software level) [*] exactly where
>a random app stores its data -- and the random
>app doesn't care!

That's Mr. Anderson's point, if I'm not mistaken.  He doesn't mean that
the OS shouldn't specify the format on disk, he means that the OS should
provide a general I/O API and let the programmer choose the *logical*
formatting of the data.  Bill, correct me if I'm wrong.

-- 
 Ben

"The world is conspiring in your favor."  -- de la Vega

------------------------------

From: John Jensen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 25 Jun 1999 13:31:28 GMT

Jan Panteltje <[EMAIL PROTECTED]> wrote:
: >In article <wt4sjyngo9.fs  C++ and Java are
: >much better than C.  Dylan is much better than C++ and Java.
: >
: Well if I distill 'better' from that, then (I have not tested Dylan, liked
: some of Bops songs though), then it must be f*cking slow and bloated.

I might as well mention yet another option.  (This is getting to be my
standard blurb to let people know about TOM, if you've seen it before
please skip.)

I've also been playing with the question of what language to use for Linux
apps.  So far, I've done one simple GTK+ app in C, and a second
implementation in an OO language ... for which I chose TOM.  I'm much more
at ease writing OO, having most recenlty oriented my programming neurons
for Java.  If you'd like to see the C, TOM, and Java implementations, the
source is available at:

C:      http://www.primenet.com/~jjens/maze.c
TOM:    http://www.primenet.com/~jjens/Maze.t
Java:   http://www.primenet.com/~jjens/maze.html

Trying to do OO with C connectivity is always a compromise, but I think
TOM strikes a good balance.  It offers better OO than Java, but is built
for native compilation.  It has GC.  It offers good support for Linux
tools and shared libraries.  It offers C connectivity by letting you use
html-ish tags to include C within TOM:

<doc>from Window.t </doc>
  instance (id)
    new int window_type
  {
    pointer p;
  <c>
    p = gtk_window_new (window_type);  
  </c>
    = [[self alloc] init p];
  }

The TOM page is http://www.gerbil.org/tom

John

------------------------------

From: [EMAIL PROTECTED] (Terry Murphy)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 25 Jun 1999 05:06:52 GMT

In article <7kt0m9$pbb$[EMAIL PROTECTED]>,
Stefaan A Eeckels <[EMAIL PROTECTED]> wrote:

>The portability issue is not a fundamental feature. It stems from the fact
>that the kernel was re-written in a high-level language.

It seems that virtually every introduction to Unix will mention
its portability in the first sentence. This is one of the main things
which is used to distinguish it from OS/400, VMS, etc.

And I don't think it just stems from the high level language (which VMS
is also largely written in), but also the fact that it is much more
abstract and independent of the system (unlike VMS, which only runs on
two platforms, both by one company, and is thought to be
technologically impossible to port to any other existing platform).

>The pipe was indeed a concept that sprang from the original design. 
>Again, what's wrong with that? Are only products which didn't 
>expand their core functionality "designed"?

But the problem with pipes is that chapter one on any treatise on
the Unix Philosophy is going to be about pipes, e.g. small re-usable
tools, filters, etc., etc. True this was possible before pipes with
redirection, but it is clear that were it considered a core feature,
more thought would have been into exploiting this feature.

>It's not because DEC wrote a "book" on software engineering that they
>follow it :-) 

This book I am talking about, what not published, it was a handbook
"for internal use only", i.e. it would have been silly to produce it
and not use it.  For the project that I worked in there, we did the
whole nine yards:  requirements, architecture, unit testing, regression
testing, field tests, etc. And this was for an internal product with
perhaps 100 customers.  I am sure the process for external tools is
even more rigorous.

>Seriusly, look at OpenVMS --a mad scramble to get POSIX into
>VMS. Does that fit your requirements?

FYI, Posix was merely a product on top of VMS, it wasn't really
integrated into the system (e.g. it required a separate license).  It
has been discontinued, BTW. I am opposed to it on principle of course
(I don't want my system polluted by Posix), but it seems that was about
the only way to do it, and it's hard to get pointy haired managers to
buy a systems which doesn't conform to the "P" word.

>Sure. The Windows design process. GlobalAlloc and LocalAlloc --hacks
>to get around a 640k memory limitation without using a memory management
>chip. The MSDOS-1 FCB stuff still present in Windows98. And Word of
>course never acquired *any* new functionality since its original
>release.

Microsoft engineering was a bit patchy until recently. I don't know
how you can argue with the technical quality of their applications, e.g.
Outlook, IE, Power Point, Word, etc. All of those are massively complex 
projects, which clearly a lot of work went into.

>The hallmarks of a good design are that it 
>a) finds uses the original designers never envisaged
>b) accepts the inevitable modifications, additions and enhancements
>   that are applied to it without too many structural cracks.
>Whether it had a requirements document, or still matches the original
>or revised design spec are not relevant.

So what software system would you consider to match these criteria?

>Take care, and brace yourself for what you'll discover when you
>leave varsity ;-)

I'll try. I think a have had a bit of exposure to the bad side (my 
current employer), which is the reason I speak up in this discussion.

-- Terry

------------------------------

From: [EMAIL PROTECTED] (Terry Murphy)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 25 Jun 1999 05:10:10 GMT

In article <7kuddr$uf5$[EMAIL PROTECTED]>,
Stefaan A Eeckels <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>       [EMAIL PROTECTED] (Vladimir Z. Nuri) writes:
>> I vehemently detest the "troll" label. none of my posts fit into
>> this category. I am being labelled that merely because I am not
>> backing down from defending the article.
>If you'd read what I said instead of going off like a firecracker,
>you'd have noticed the "troll" referred to Terry's rather weird
>idea of having requirements documents for open source projects.

Your exact words were: "As for other projects, how do you know they are
not designed? Is there somehow an obligation to troll on Usenet before
starting an open source project? Or should you be asked to comment on
each and every free project?"

It sure sounds like "troll" referred to Mr. Nuri as he, after all,
is the one starting an open source project and he is the one that
posted the document to Usenet which some regarded as a troll.

Anyways...

-- Terry

------------------------------

From: Craig Graham <[EMAIL PROTECTED]>
Subject: Framebuffer device why doesn't it work? - again....
Date: Fri, 25 Jun 1999 14:42:25 +0000

I've asked this before, and still got nowhere.....anyway.

How do I get the framebuffer consoles to work (/dev/fb0, etc).
I have an S3 Virge video card, and I'm running kernal 2.2.9.

I've tried all the setup's I can think of, mknod'ed the device
(char major 29, minor 0 for fb0) - still no joy. All I get is
a device does not exist error.

It's doing my head in, as I have a real use for the fb device...

Craig.

------------------------------

From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAPOs: configurations
Date: 25 Jun 1999 12:38:07 -0400

In article <[EMAIL PROTECTED]>,
Paolo Torelli  <[EMAIL PROTECTED]> wrote:
>Alexander Viro wrote:
>> >> I assure you the OS of the future is not going to have text based
>> >> configuration files .. at least at the core. I think there is always
>> >Indeed. text files are by all means larger and harder to mantain.
>> So you never did any kind of sysadmin job, right?
>Where's the logical connection?

Trivial - ones who did (and had to recover the system after the vendor's
patch left a total havoc when applied) usually obtain a gut feeling of
the reasons why text config is *good* thing. No, nuke-n-reinstall is not
an option in the situations above. Not a desirable option, at the very
least. Especially when you have a hundred boxen scattered over several
countries (or just a few in the area you *don't* want to enter - some
microbiology research centers come to mind... idea of sitting in
quarantine for a month is *not* attractive). Text configs can be recovered.
Easily. Over telnet. *And* they are scriptable. Recovering them is possible
when system is seriously fucked up. For binary stuff you rely on much
narrower toolset and more layers of stuff that should work or you are
out of luck.

>And false, I actually *DID* some sysadmin job. not *x, tho.


-- 
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid.  Get yourself a better computer" - Dilbert.

------------------------------

From: [EMAIL PROTECTED] (John E. Davis)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 25 Jun 1999 16:15:46 GMT
Reply-To: [EMAIL PROTECTED]

On Sat, 26 Jun 1999 00:53:24 +1200, Bruce Hoult <[EMAIL PROTECTED]>
wrote:
>Not true, IMHO.  Even such simple things as // comments, declaring
>variables at first use, inline functions and const instead of #define,
>structs as type names, references, cleaned-up casting, and default
>arguments make C++ better than C.

None of these things compel me to use C++.  The C compiler, e.g., gcc,
will automatically inline small functions functions.  In addition, gcc
supports an `inline' keyword.  As far as structs as type names go, why
not use a typedef?  That is,

     typedef struct 
     {
        int whatever;
     }
     Whatever;
     
     Whatever X;

Now consider references:

     int x;
     x = 1;
     some_function (x);

what will be x's value after the call to some_function?  Will it be
altered?  In C, I know immediately know the answer to the question and
do not have to look further.  This kind of syntactic sugar disturbs me
as one who reads a lot of software that I did not write.

Regarding //, in two keystrokes, my editor puts /* */ at the end of
the current line and places the cursor in the middle.  If the comment
requires more than one line, I either hit return to continue onto the
next line, or reformat the comment as text.  I claim that very little
is achieved by using // comments.

Please note, I am not arguing that C++ is not a better language than
C.  I am just saying that the reasons that you listed do not make it a
better language.  In my opinion, the only thing that C++ has over C is
better support for data encapsulation via classes and, possibly,
exception handling.  Other features such as operator overloading I can
do without because of the potential for abuse.

-- 
John E. Davis                   Center for Space Research/AXAF Science Center
617-258-8119                    One Hampshire St., Building NE80-6019
http://space.mit.edu/~davis     Cambridge, MA  02139-4307

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list (and comp.os.linux.development.system) via:

    Internet: [EMAIL PROTECTED]

Linux may be obtained via one of these FTP sites:
    ftp.funet.fi                                pub/Linux
    tsx-11.mit.edu                              pub/linux
    sunsite.unc.edu                             pub/Linux

End of Linux-Development-System Digest
******************************

Reply via email to