Linux-Development-Sys Digest #879, Volume #6 Fri, 25 Jun 99 00:14:40 EDT
Contents:
Re: TAO: the ultimate OS (Christopher Browne)
Re: Why we are still holding on to X Windows (Tristan Wibberley)
Re: You can now use Winmodems in Linux!!!!!!! ("jp")
Re: Run in background (Greg de Freitas)
Re: Why we are still holding on to X Windows (Tristan Wibberley)
Re: Why we are still holding on to X Windows ("Stefan Monnier "
<[EMAIL PROTECTED]>)
Re: Why we are still holding on to X Windows (Tristan Wibberley)
Re: TAO: the ultimate OS (Jim Richardson)
Re: Why we are still holding on to X Windows (Mario Klebsch)
Re: Why we are still holding on to X Windows (Daniel Robert Franklin)
Re: Why not C++ (Bruce Hoult)
Help: Module dependencies (pzdev)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Reply-To: [EMAIL PROTECTED]
Date: Fri, 25 Jun 1999 00:35:06 GMT
Sometimes people write things that I really wish I had. Eugene's was
one of those posts...
On Wed, 23 Jun 99 18:01:13 GMT, Eugene O'Neil <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Vladimir
>Z. Nuri) wrote:
>>the strong hostility to my essay is evidence of something much
>>deeper in the psychology of hackers...
...
>>the new priority: THE END USER. everything needs to revolve around
>>the end user, rather than the programmer. EASY TO PORT== favoring
>>the programmer.
>
>New? That priority is as old as Capitalism. People were blathering that "the
>customer is always right" long before computers were invented. We might call
>our customers "users", but the basic idea is still exactly the same.
...
Indeed.
And for those that think *this* century is the source of "massive
societal transformations," there is a clear case for an accusation of
ignorance of history. Case in point would be to regard the difference
in times between 1840 and 1860. During that time, telegraphs,
railroads, and steamships became commercially available, thereby
allowing messages and goods to be delivered throughout the developed
world on predictable schedules, which was as wrenching a societal
transformation as anything this century.
>Linux did not get where it is today by pandering to the lowest common
>denominator, like Microsoft does. For years Linux was laughed at, ridiculed,
>or simply ignored because it did not conform to the accepted user-centric
>model of the universe. THEY were the ones who were filled with hubris, and WE
>are the ones who exposed the flaws in their dominant paradigm, not the other
>way around.
...
>Now that our radical programmer-friendly approach is gaining too much
>momentum to be dismissed as a fluke, everyone is trying to get on the
>bandwagon. I find it ironic that many people who are fleeing the
>wreckage of Windows are now begging us, nay, ORDERING us to make the
>same short-sighted user-centric mistakes that made Windows such a mess
>the first place. Vague threats about users beating our doors down will
>not intimidate us. On the contrary, it only shows that we have something
>they want very badly: that hardly puts them in a position to demand
>anything.
Could I reword the latter bit as:
"We *must* not permit vague threats about users beating our doors down
to intimidate us. In *that* direction lies the disasters encountered
with Windows."
That manifests the reason to refuse such demands.
>I am not saying that Linux can or should remain user-hostile as a goal in
>itself.
Active hostility is not good, and should not be a goal at all.
Deliberately making things "hard to use" is not appropriate. If someone
is writing a MTA today, they should not deliberately create a macro
system that is as difficult to work with as sendmail.cf, for instance.
The point is that there is *always* some compromise that occurs when
making decisions about design parameters, and the question is of what
priority to take.
- A proposed change may be "friendly" to some users, at the cost of
making the system less powerful. Moderate lies in this direction,
although this *can* represent an acceptable compromise.
- A proposed change may be "friendly" to some users, at the cost of
compromising the integrity of the system design. Such changes must be
resisted at all costs.
>There is a perfectly respectable role for end-users to play in Linux,
>but it is not the priviledged position of supreme importance they have
>grown so accustomed to in Windows.
I have to disagree with this, somewhat. End-users are not of "supreme
importance" in the MSFT world; they are sheep to be fleeced, and are
expected to upgrade to whatever version of MS Office that the MSFT
marketing department have released most recently.
>Users must learn that Priviledge can only be
>earned in Linux, purely on the basis of merit. If the customer is so damned
>right, he can PROVE it by writing better code! Otherwise, he should not get in
>the way of the programmers who are actually getting things done. Give us the
>time to do things properly, and we will do more than just make our programs a
>little easier: we will make them fundamentally BETTER.
Can I spin this a bit differently?
In order to directly influence software production, the only method
available is to write code yourself. If you cannot do so, then you
must find a way to influence developers.
It is usual for *forcible* form of such influence to result from
influencing flows of money; that is commonly not the case for free
software, which denies that form of economic control.
As a result of the lack of economic control, control must be attained
via *persuasion,* and, when you have no more visceral methods to do
this, you must establish the merit of your ideas in they eyes of other
developers.
- The strongest merit may be found in a working implementation of the
idea. Someone that codes a new journalling filesystem and gets it
working has a *clear* proof of the validity of the idea.
- A prototype represents a weaker, but typically acceptable, proof of
merit.
- Weaker, but nonetheless clear, merit may be found in a clear design
specification that provides guidance to the structure of the
implementation.
- Still weaker, but sometimes sufficiently convincing, is a general
description of the system.
- Of the weakest merit is the vague description of some desirable
system properties.
With other approaches, these differing degrees of merit get overruled
by the economic merits of:
- "I'll give you a pile of money if you try to implement this," or
- "I'll fire you if you don't do what I say."
which are the true implications of "The Customer Is Always Right."
--
"End users are just test loads for verifying that the system works, kind of
like resistors in an electrical circuit." - Kaz Kylheku in c.o.l.d.s
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/freeecon.html>
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
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 01:53:48 +0100
Reply-To: [EMAIL PROTECTED]
Greg de Freitas wrote:
>
> "John McDonald, Jr." wrote:
> >
> > 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
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ :-) GLAD it's _not_ just me then,
>
> So, I can run X and anonwm, get an xterm up, kill anonwm (deco disappears, shame
> :-) and run otherwm&
> So what do i need gnome for ???
Gnome is a set of libraries and utilities that sit there and provide
pre-written functionality which an application may make use of - no
matter what is on your system, no matter what else you're using. It just
sits there, except for the utilities which put stuff on the screen.
There are some specifications for operating with gnome, which an app
(any app) may use, and gnome will listen to it. Gnome input and
graphical output libraries (gtk and glib) draw to the x server. They
also use other standard libraries that are on your system, same as any
application or library.
Window managers don't really have anything to do with KDE and gnome,
except that they could be written with the ability to talk with apps
that use gnome libs and apps that use KDE libs.
In summary:
Gnome does not stop you doing things, it is simply a thing which is
there for people who want to use it (and apps that would like to use
it's functionality).
Gnome provides code for stuff that lots of applications like to do, so a
gnome app can be many times smaller than it might otherwise have been,
and it can interoperate with any other gnome app. It also provides a
number of protocols which means things can interoperate with any gnome
apps that might wish to interoperate if they happen to be there at the
time.
Gnome and KDE are well written, and are very passive. So they sit there
without complaining or disturbing anyone, and they do whatever an
application might ask them to do for it.
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
From: "jp" <[EMAIL PROTECTED]>
Subject: Re: You can now use Winmodems in Linux!!!!!!!
Date: Thu, 24 Jun 1999 18:54:30 -0500
If the LinModem application will be in a PDA or laptop, consider building a
Cellular LinModem first.
It doesnt even need a digitizer. Just pure software and a serial cable from
someone like TDK, Inc. (global-pulse serial cable), or another method would
be to get some pcmcia modem vendor involved. I could help with that if
someone has the inside scoop with some struggling pcmcia vendor. The trick
is to cut out all the V.42, etc that has bogged down modem progress and
start a-new.
Medical Electronics Lab wrote in message
<[EMAIL PROTECTED]>...
>Jonathan A. Buzzard wrote:
>>
>> In article <[EMAIL PROTECTED]>,
>> Medical Electronics Lab <[EMAIL PROTECTED]> writes:
>>
>> [SNIP]
>>
>> > The winmodem is just a digitizer that does DMA into a buffer. The
>> > processor has to convert the audio bits to multiple tone data, and
>> > then to data bits. It's straight forward data manipulation. There
>> > is no reason we can't write a driver for any winmodem.
>> >
>>
>> What an absolute load of rubbish. The vast majority of winmodems have
>> DSP that do all the modulation etc. What they don't provide is a
>> standard serial interface and an AT command interprator. Try reading
>> some of the literature for winmodem chipsets. The Lucent Mars chipset,
>> used in Toshiba and Compaq laptops would be a good place to start.
>
>I've got a PCTel chip. It's just a digitizer. It uses HSP - host
>signal processing. *ALL* the dsp work is done by the host. I don't
>have to talk to Lucent, I have to talk to PCTel. Now, will they talk
>to me?
>
>Take your rubbish to the curb boy!
>
>Patience, persistence, truth,
>Dr. mike
------------------------------
From: Greg de Freitas <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Run in background
Date: Fri, 25 Jun 1999 01:39:59 +0100
Reply-To: [EMAIL PROTECTED]
Marc Mutz wrote:
>
> ellis wrote:
> >
> > >Try following you executable with an '&'
> >
> > That still leaves the process in the shell's process group.
> >
> If you are using bash, take a look at the 'disown' builtin.
>
> Marc
nohup command [args...] &
:-?
--
Ciao 4 now, Greg.
# Email : mailto:[EMAIL PROTECTED] #
# Email : mailto:[EMAIL PROTECTED] #
# To Live, To Love, To Learn, To Leave A Legacy. #
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: Thu, 24 Jun 1999 02:12:00 +0100
Reply-To: [EMAIL PROTECTED]
Michael Gu wrote:
>
> Inform myself about what? How X works? How technically advanced it is? How
> good it SHOULD be? How many hours I need before understanding its power?
X is a thing that lets any application on the network draw on your
screen (after getting permission), and ask to be told what input device
events occur.
Anything else an app wishes to do can still be done, the whole point of
X is that all drawing/GUI input events can be done using it. Any thing
else you wish to do can be done using something else.
X was designed to not preclude anything, _there_are_NO_ limitations, all
you need is an extension or another server (eg EsounD is a server that
sits next to your X server on your machine waiting for an application to
tell it to play a sound - the X Window System does *not* stop it). All
your existing apps will still work. If people really want anti-aliased
font support that badly, then an extension will be hashed out and will
become a part of X. This is why X is so great, and need not (nay,
shouldn't be) replaced. It is also why there are no serious competitors,
nothing has been written yet which comes close to being as good (though
Berlin will beat crap out of anything that has come before (IMHO) - and
can even be extended to provide the X protocol - so X survives, and all
those apps people have payed �1000s for will not have been wasted).
Vive la well designed architectures!
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
From: "Stefan Monnier <[EMAIL PROTECTED]>"
<[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: Why we are still holding on to X Windows
Date: 24 Jun 1999 21:59:09 -0400
>>>>> "Daniel" == Daniel Robert Franklin <[EMAIL PROTECTED]> writes:
> However, IMO GNOME has a number of design flaws which still need to be
> worked out.
Care to mention those `design flaws' ?
To me `design flaw' and `to be worked out' are mostly mutually exclusive.
> It is certainly prettier than KDE but in my experience not as stable.
I hope you don't consider `no stability' as a `design flaw'.
> which I cannot live without, such as a single-click to open
> files/directories,
You're talking major design flaw here !
Stefan "who doesn't use either of them"
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
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 01:38:00 +0100
Reply-To: [EMAIL PROTECTED]
Doug DeJulio wrote:
>
> In article <[EMAIL PROTECTED]>,
> David Fox <d s f o x @ c o g s c i . u c s d . e d u> wrote:
> >What sound has to do with X is that X applications running remotely
> >should be able to make sounds - some sort of protocol is needed. Of
> >course, this has nothing to do with whether X is inferior Win32, which
> >it isn't.
>
> There's a *little* bit more to it than that.
>
> Often sound and visual operations are supposed to be the same "event"
> in a user experience (eg. a button clicks when you press it). So,
> it's important to be able to synch sound events and other GUI events.
> If you're using two totally distinct subsystems that aren't aware of
> each other, like X11 and a network sound service, this is harder
> (though on fast enough hardware you often won't notice any problems).
> If you use a well crafted X extension for sound, it becomes easier to
> ensure that you don't hear a click and *then* see the button get
> pushed in, or vice versa.
Better than adding support for every user interface concept into the X
protocol somehow, just for the sake of syncronisation, simply add some
general syncronisation support.
With either approach, when networking, there are inherent problems. You
should *never* wait for loads of data to be sent over a network before
telling the user that the computer has noticed their operation. So you
shouldn't syncronise sounds with the graphical signal past a few (10
ish) milliseconds. You need to be able to specify what not to do after
that time, and what priority to give what.
Because of network traffic issues, any syncronised stuff needs to be
sent fully across to the machine with the server before playing, and the
protocol used doesn't matter.
The sound capability doesn't need to be (and shouldn't be) included in
X, but provide a server side IPC protocol to let two servers which have
support for syncronisation syncronise. (They could actually be in the
same process, but there's no reason to not have a separate protocol on a
separate stream for the sound).
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
From: [EMAIL PROTECTED] (Jim Richardson)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Thu, 24 Jun 1999 18:29:06 -0700
Reply-To: [EMAIL PROTECTED]
On 24 Jun 1999 10:18:49 GMT,
Stefaan A Eeckels, in the persona of <[EMAIL PROTECTED]>,
brought forth the following words...:
>In article <7ks7iu$ju2$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Terry Murphy) writes:
>> In article <7krkmo$li9$[EMAIL PROTECTED]>,
>> Stefaan A Eeckels <[EMAIL PROTECTED]> wrote:
>>
>>>Your portraying of the situation is too polarized. It's
>>>impossible to just open vi and start coding --you'd at least
>>>need to know what you're going to code.
>>
>> Perhaps, but I very rarely see design documents or requirements
>> documents for anything that comes out of the free software community.
>Agreed. What you describe is a typical "commercial" document. I've
>been on enough commercial prjects to know that such a document is
>hardly ever an accurate description of the final product, and more
>often than not it's left to rot (or to be perused by the auditors).
Or as is often the case, the "design document" gets written afterwords
to document what you did, not what you planned to do...
--
Jim Richardson
Anarchist, pagan and proud of it
WWW.eskimo.com/~warlock
Linux, because life's too short for a buggy OS.
------------------------------
From: Mario Klebsch <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: Thu, 24 Jun 1999 19:41:49 +0200
mlw <[EMAIL PROTECTED]> writes:
>Michael Gu wrote:
>>If Microsoft is a monopoly, X Windows acts more like a monopoly in the
>>Unix world.
>>
>>Let's face it. X Windows is a really premitive base for modern GUI,
>>terrible font support breaks GUI all the time, no sound capability, ....
>>If Linux is going to desktops to compete with Microsoft, it got to come
>>up with something much better then X.
>>
>>So, why don't we drop the X and innovate?
>X is at least 5 to 10 years ahead of anything Microsoft has going. They
Well, it is 5 to 10 years ahead and probably over 10 years behind at
the same time.
>are working like crazy to get terminal server and Citrix to be reliable.
>We have what they are trying to do already.
This is one aera, where XC is ahead. :-)
>With X, I can run a program anywhere on any machine, Windows can't touch
>that.
>As for Audio, what the hell does a GUI have to do with audio? Yes, Linux
>needs a standard networked streaming audio spec, but that is not "X."
It has nothing to do with X, but with the users session. When I have a
session sitting in front of display xxx, I expect my sound to creap out
of the speakers standing next to that display, and not entertaining the
sysop in the computer room. :-)
>You may be confusing X with the Window manager. X is conceptually a
>display driver/interface. The Window manager is more of the GUI
>component. The way the applications look and the way the system feels,
>is part of the WIndow manager. The act of drawing primitives and getting
>mouse and keyboard data is where X is.
And you seem to confuse look&feel with a window manager. Surely, on a
text window (like xterm), the window manager is the only visable thing,
so it seems like look. But the feel depends much more on the widget set
used, but on the window manager.
>If you want to look at a good Window manager / Desktop system, take a
>look at KDE.
Well, it is quiet nice, but far from being standard. Let's face it,
windows really is ahead of X, when it comes to the widgets and more
important consistency among the applications.
X only includes Xaw, and it can't compete with windows. You can argue
about Motif, but who the hell does use it? Especially Linux normaly
does not include Motif.
And when it comes to consitency, the UNIX people alway dream about the
ability to choose amound hundreds of widget sets (Xaw, Xaw3d, Motif,
Lesstif, Gtk, Qt, ...), but in reality almos no one can choose. Only
the author of a program can choose, the user of a program cannot. He
has to live with the design decision, the autor took. And since each
author does his own decision, there is not much consistency among
different applications.
There even isn't a standard api, since several pupular widget sets
even do not use the Intrinsics.
So, there still is a long way to go...
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Daniel Robert Franklin)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: Why we are still holding on to X Windows
Date: 25 Jun 99 02:43:44 GMT
"Stefan Monnier <[EMAIL PROTECTED]>"
<[EMAIL PROTECTED]> writes:
>>>>>> "Daniel" == Daniel Robert Franklin <[EMAIL PROTECTED]> writes:
>> However, IMO GNOME has a number of design flaws which still need to be
>> worked out.
>Care to mention those `design flaws' ?
>To me `design flaw' and `to be worked out' are mostly mutually exclusive.
Why? It is sufficiently modular for the missing bits to be added. These
are still (IMHO) design flaws.
>> It is certainly prettier than KDE but in my experience not as stable.
>I hope you don't consider `no stability' as a `design flaw'.
No. But it is a serious problem, considering that it was pushed out
through RH 6.0 as "The Linux Desktop"...
>> which I cannot live without, such as a single-click to open
>> files/directories,
>You're talking major design flaw here !
True enough, at least according to most of the fifty or so users I've
asked to trial KDE and GNOME. The near-universal opinion has been "We love
KDE, GNOME is cool but inconsistent and generally harder to use than KDE".
Anyway, this is getting very OT, so lets truncate it here (or move to
c.o.l.a...
> Stefan "who doesn't use either of them"
No-one says you have to - but I have had generally very positive responses
(particularly amongs new / inexperienced users, but also with experienced
Linux people) when we added the options "KDE" and "Gnome" to our wdm
login screen. KDE was definitely the winner. Personally, I like KDE, since
it looks good and behaves consistently. GNOME still has problems.
- Daniel
--
******************************************************************************
* Daniel Franklin - Postgraduate student in Electrical Engineering
* [EMAIL PROTECTED]
******************************************************************************
------------------------------
From: [EMAIL PROTECTED] (Bruce Hoult)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Fri, 25 Jun 1999 15:03:47 +1200
In article <[EMAIL PROTECTED]>, "Thomas Steffen"
<[EMAIL PROTECTED]> wrote:
> apart from that, C++ might not be a very elegant language, but it is
> fast. at least compared to other OO languages. and still has about
> every feature you can expect.
You might want to check out Dylan. It's much simpler and easier to learn
than C++, and yet is more powerful than C++ -- for example Dylan supports
dynamic dispatch on more than just one argument of a function, plus Dylan
has things such as lexically scoped local functions, anonymous functions,
and closures, none of which C++ has. C++ has a mish-mash of features.
Often, you have to choose whether what you want to do is best done using
overloaded functions, template functions or virtual functions. Dylan has a
single function dispatch mechanism that covers *all* those C++ function
types. Plus Dylan is designed to be as fast as C++. C++ and Java are
much better than C. Dylan is much better than C++ and Java.
You can have a look at <http://www.gwydiondylan.org> for a free Linux
compiler. It's not a finished product yet -- it needs some more
libraries, the interface to C has to be perfected, the compiler itself
needs to be made faster, and it could do with a few more optomisations in
the generated code -- but it's stable (e.g. it happily compiles itself)
and is plenty good enough to learn the language and even write production
command-line/filter programs with.
-- Bruce
------------------------------
From: pzdev <[EMAIL PROTECTED]>
Subject: Help: Module dependencies
Date: Fri, 25 Jun 1999 02:30:45 GMT
I'm writing a driver for Linux in module form which basically consists
of two parts. Part A presents access to part B, a library, through a
TTY driver interface. Part A is small compared to part B -- on the
order of 100 times smaller.
What I want to do is to make parts A and B into two different modules.
Module A will load at boot time, where it receives a dynamic major
device number. Part B is loaded when a descriptor is open on the device
created by part A, and is unloaded when the open descriptor count falls
to zero. This way, the large amount of memory used by part B is only
used when the device presented by A is actually in use.
The problem is that because module A makes calls into the functions
exported my module B, I can't install module A by itself because there
are unresolved symbols. I can load A if B is already loaded, of course,
but that defeats the purpose!
Can anyone suggest a way around this? If I could use a fixed major
device number then kerneld could load and unload the whole thing as
necessary, but I want to avoid this since it's not a device in common
use. Any ideas?
pzdev
--
pzdev-AT-pgz-DOT-org
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
