Monolithware (tm)

Monolithware (tm)

Post by Terry Port » Sun, 31 Dec 1899 09:00:00



We often hear how "Monolithware" (tm) is the best thing, as oposed to the
Unix way of programs working together.

Some say they can't see why, it should be necessary to have a mail reader, a
mail fetcher and a mail poster, for instance, instead of the one app, which
does it all.

My reply is that the Monolith way is far less versatile, and the user will
suffer in the long run.

Here is a real world example for you.

DDD the "Data Didplay De*" a famous and widely used GPL app, was
designed as a GUI front end to things like GDB, the "Gnu De*", and
designed accordingly, to do just this job.
http://www.veryComputer.com/

Sdcc which is a GPL C compiler for the Intel 8051 family of microprocessors,
has a source level de*, which works with s51, a GPL 8051 simulator.

http://www.veryComputer.com/

All the above are cli driven.

Just the other day, I found that the SDCC source level de*, interfaces
with DDD, giving me a FAST, GUI, source level de* for the 8051 family
on my pc.

I needed a small code change for breakpoint compatibility, but Daniel Drotos
the author of s51, had told me what the change was, and I just did text
search and replace (like a word processor) and re compiled SDCC.

Took all of 5 minutes, and the break point facility under DDD then worked
perfectly.

For a screen pic of the result see :-
www.odyssey.apana.org.au/~tjporter/ddd_sdcc.gif
A quick description is www.odyssey.apana.org.au/~tjporter/ddd_sdcc.readme

Now I'm crusing with better tools than ever before, all GPL, all *free*.

Linux, putting the "P" back into "productivity".

Kind Regards
Terry
--

   My Desktop is powered by GNU-LINUX, and has been  
 up 5 days 16 hours 18 minutes
** Registration Number: 103931,  http://www.veryComputer.com/ **

 
 
 

Monolithware (tm)

Post by mlw » Sun, 31 Dec 1899 09:00:00



> We often hear how "Monolithware" (tm) is the best thing, as oposed to the
> Unix way of programs working together.

> Some say they can't see why, it should be necessary to have a mail reader, a
> mail fetcher and a mail poster, for instance, instead of the one app, which
> does it all.

> My reply is that the Monolith way is far less versatile, and the user will
> suffer in the long run.

Not all things are that simple. When you make a "program" out of many
programs, you have to deal with multiple processes. This is not always
an easy thing to do.
--
Mohawk Software
Windows 95, Windows NT, UNIX, Linux. Applications, drivers, support.
Visit http://www.mohawksoft.com

 
 
 

Monolithware (tm)

Post by Tim Kelle » Sun, 31 Dec 1899 09:00:00




> > We often hear how "Monolithware" (tm) is the best thing, as oposed to the
> > Unix way of programs working together.

> > Some say they can't see why, it should be necessary to have a mail reader, a
> > mail fetcher and a mail poster, for instance, instead of the one app, which
> > does it all.

> > My reply is that the Monolith way is far less versatile, and the user will
> > suffer in the long run.

> Not all things are that simple. When you make a "program" out of many
> programs, you have to deal with multiple processes. This is not always
> an easy thing to do.

That's true, but for end users, it can still be better.

Grip, for instance, is simple a combined interface to a variety
of cdripping and mp3 encoding programs ... so you get a lot of
versatility, but it is still easy to use.

--
Tim Kelley

 
 
 

Monolithware (tm)

Post by Bone » Sun, 31 Dec 1899 09:00:00



> We often hear how "Monolithware" (tm) is the best thing, as oposed to the
> Unix way of programs working together.

Ah, but thats the trick! It's not really monolithware! There are hundreds of
little libraries that augment the functionality of one little executable.
The main difference is that libraries can't be run from the command line.

The monolithic approach offers no benefit to the user over the Components
'n' Scripting approach. Both can be set up to appear to work in exactly the
same manner. The monolithic approach is specifically designed to benefit the
original developer, not the user or third party developers. It is a way to
protect intellectual properties at the expense of usefulness to the people
who actually pay for it.

----
Bones

Manual, n.:
        A unit of documentation.  There are always three or
more on a given item.  One is on the shelf; someone has the
others. The information you need is in the others.
                -- Ray Simard

 
 
 

Monolithware (tm)

Post by mlw » Sun, 31 Dec 1899 09:00:00





> > > We often hear how "Monolithware" (tm) is the best thing, as oposed to the
> > > Unix way of programs working together.

> > > Some say they can't see why, it should be necessary to have a mail reader, a
> > > mail fetcher and a mail poster, for instance, instead of the one app, which
> > > does it all.

> > > My reply is that the Monolith way is far less versatile, and the user will
> > > suffer in the long run.

> > Not all things are that simple. When you make a "program" out of many
> > programs, you have to deal with multiple processes. This is not always
> > an easy thing to do.

> That's true, but for end users, it can still be better.

> Grip, for instance, is simple a combined interface to a variety
> of cdripping and mp3 encoding programs ... so you get a lot of
> versatility, but it is still easy to use.

What was unclear about my post? "This is not always an easy thing to do"
does not mean give me an example of an easy thing to do to support your
point. Yes, sometimes it can be easy. That, quite obviously, was not my
point.

--
Mohawk Software
Windows 95, Windows NT, UNIX, Linux. Applications, drivers, support.
Visit http://www.mohawksoft.com

 
 
 

Monolithware (tm)

Post by j.. » Sun, 31 Dec 1899 09:00:00






>> > > We often hear how "Monolithware" (tm) is the best thing, as oposed to the
>> > > Unix way of programs working together.

>> > > Some say they can't see why, it should be necessary to have a mail reader, a
>> > > mail fetcher and a mail poster, for instance, instead of the one app, which
>> > > does it all.

>> > > My reply is that the Monolith way is far less versatile, and the user will
>> > > suffer in the long run.

>> > Not all things are that simple. When you make a "program" out of many
>> > programs, you have to deal with multiple processes. This is not always
>> > an easy thing to do.

>> That's true, but for end users, it can still be better.

>> Grip, for instance, is simple a combined interface to a variety
>> of cdripping and mp3 encoding programs ... so you get a lot of
>> versatility, but it is still easy to use.

>What was unclear about my post? "This is not always an easy thing to do"
>does not mean give me an example of an easy thing to do to support your
>point. Yes, sometimes it can be easy. That, quite obviously, was not my
>point.

        Programming in general is not 'easy'. So what? For as long
        as there have been GUI's, there have been GUI wrappers for
        the various character based utilties that still lingered.

        In practice, the problem doesn't seem to be as big as you
        make it out to be as evidenced by: SoundStudio, ripperX,
        gqmpeg,tk3play & XCDRoast.

        Those are just the ones I use on a regular basis. That's
        not getting into the rest of what might be lurking about
        at freshmeat or Tucows.

--

   One of the great lies of our age is the myth that      
   Microsoft has somehow managed to turn these random      
   collections of spare parts known as PC clones into            |||
   the equivalent of a Macintosh.                               / | \

 
 
 

1. Web Chat: Solstice(TM) Enterprise Manager(TM) 2.1

Mark your calendars:

Date:    Tuesday, November 25th
Time:    12:00 Noon Pacific Time

URL:     http://www.sun.com/developers/chat.html

Tune in on Tuesday, 25 November 1997, to talk with Sun engineers about
Solstice(TM) Enterprise Manager(TM) 2.1; the latest version of
InfoWorld's 1996 Network Product of the Year winner.

Solstice Enterprise Manager allows for the central monitoring of local
and distributed network devices from single or multiple consoles. The
product manages SNMP, Common Management Information Protocol, and
Remote Procedure Call agents throughout your network. If you'd like
to read more about Solstice Enterprise Manager before the chat, please
see http://www.sun.com/sem/.

Note: You must have a Java-enabled browser to participate in the Chat
and you may experience difficulties if you are behind certain
firewalls.

If you have a question about this topic, but won't be able to tune into

later* than 24 hours prior to the chat. Your questions will either be
answered during the chat (time permitting) or included in the
transcript.  Chat transcripts are posted to the archive
(www.sun.com/developers/chatarchive.html) a few days after the chat.

Want to suggest a topic or receive email notification about future

2. somebody!i740.

3. Release of Sun(tm)'s Java(tm) Development Kit Beta 1.0 for Linux

4. A Newbie Please answer Question

5. Insight(TM) -vs- Purify(TM)

6. IPX over slirp(PPP) on linux

7. AppleTalk(tm) for Linux(tm?)

8. MUX and CSU/DSU

9. OpenSource(tm)?... How about "OpenSpec(tm)"?

10. MEDIA:Sun(TM) Doubles Down on UNIX - Changes Entry-Level Server Dynamics With Solaris(TM) 9 for x86

11. REQ: Targa TM 4217 ONLD Modelines

12. Java(tm) VM Research and Technology Symposium: August 1-2,

13. A Modest Proposal for Java(tm) dependency selection among ports