Linux-Development-Sys Digest #875, Volume #6 Thu, 24 Jun 99 18:15:19 EDT
Contents:
Re: NT kernel guy playing with Linux (Holden McGroin)
Re: Why we are still holding on to X Windows (Michael Gu)
Looking for an analogue... ("Tom Emerson")
Re: Run in background (Marc Mutz)
Re: Why not C++ ("Stefan Monnier "
<[EMAIL PROTECTED]>)
Re: TAO: the ultimate OS (Vladimir Z. Nuri)
Re: TAO: the ultimate OS (Vladimir Z. Nuri)
Re: Why not C++ ([EMAIL PROTECTED])
Re: TAO: the ultimate OS (Vladimir Z. Nuri)
Re: Need help porting DOS app that uses parallel port (Part II) (Dave Platt)
Re: Linux uid limits! (James Youngman)
Re: Why we are still holding on to X Windows (Paul D. Smith)
Re: TAO: the ultimate OS (Vladimir Z. Nuri)
Re: TAO: the ultimate OS (Vladimir Z. Nuri)
Re: Why we are still holding on to X Windows (Pete Zaitcev)
Need a.out compiler ("Aaron Thompson")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Holden McGroin)
Subject: Re: NT kernel guy playing with Linux
Date: Thu, 24 Jun 1999 17:38:57 GMT
On Wed, 23 Jun 1999 15:48:26 +1000, scottxb <[EMAIL PROTECTED]>
wrote:
>
>
>> Rubini says there's a global semaphore that
>> is grabbed every time a process enters the kernel.
>
>Although this is true in reasonably current kernels,
>it is not a fundamental limitation because the transition
>to finer grained locking of the kernel can be carried
>out hierarchically, by substituting one semaphore with
>several others which cover an increasingly small area
>of the Linux kernel.
Don't have rubini in front of me, but it sounds like you just copied
his excuse word for word here. Semaphores still aren't good even if
you use lots of them. Suppose you have two instances of the same
process trying to run on smp. they would be using the same parts of
the kernel and eventually hitting the same semaphores, thus hozing the
smp benefit to them.
>
>> Only one processor (BP) can handle interrupts in SMP too. So if a
>> process is in the kernel in another processor, interrupts are not
>> handled?
>
>Interrupts will be handled by the BP at any time unless the
>currently executing process has blocked interrupts.
Another msg says interrupts are now distributed across SMP. So this is
much better.
>
>> Also, Rubini doesn't say much about threads in the kernel. Maybe
>> they're in 2.2.xx ??
>
>The kernel knows only of tasks, and these can be processes or
>threads , the only difference being that threads share the same
>virtual address space. The kernel can create processes and it can
>control the page table so you can do anything you could do
>with threads.
hmm. rather not be concerned with the page table. I get the impression
that daemons are used alot to provide a controlled thread context to
kernel drivers. ie, load daemon. daemon privately calls into it
accompanying driver. driver blocks it on a queue. Then when driver
needs to do real work at the request of other apps, driver can block
other apps, wakeup its daemon thread and don't worry, be happy...
>
>> He mentions PThread's, but says these are manufactured threads in the
>> process and the kernel still sees one process. Therefore if a pthread
>> does something in the kernel, the other threads in the process don't
>> run.
>
>If one pthread is blocked after calling a system call, all other pthreads
>
>of that process are free to run. Note that the pthread implementation
>is in development and previous limitations may not be current.
>
kool
>
>> the IRP model.
>
>Yes, I know NT uses a complicated layered model for drivers.
>The essential things you say here about the NT driver architecture
>are also true for Linux,
>1. Linux drivers can perform asynchronous interrupt processing
> by using 'bottom half's' and other techniques.
>2. Linux drivers can make calls into other Linux drivers.
well there were several other essential things I was saying about NT
besides the basic 2 above, but I don't want to get into an NT/Linux
death spiral here so...
>
>> completely reentrant and preemptible.
>
>Actually, NT has to perform kernel level locking also, so
>it is not completely preemptible.
Can you give me an example other than where it'd be necessary for any
OS?
>There is a significant overhead to fine grain kernel locking
>and this is most noticed on single processor systems.
>In the past the Linux kernel was optimised for single
>processor systems and currently and in the future it is
>being given better SMP support so it is capable of
>running well on single and multiple processor environments.
understood. thanx
------------------------------
From: Michael Gu <[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 13:19:52 -0700
Matthias Warkus wrote:
> It was the Wed, 23 Jun 1999 13:29:17 -0700...
> ..and Junyang Gu <[EMAIL PROTECTED]> wrote:
> > If Microsoft is a monopoly, X Windows acts more like a monopoly in the
> > Unix world.
>
> Blech. There are several independent implementations of X11, some by
> commercial vendors in direct competition, some by non-profit
> organisations.
>
Are they doing stuff conform to X or something completely new?
>
> > Let's face it. X Windows is a really premitive base for modern GUI,
>
> How so?
Simply put, it doesn't have enough functionality, and standardizations of
advanced features like widgets are important to guarantee a common look on
multi-platforms.
>
> > terrible font support breaks GUI all the time,
>
> My XFree86 server supports about every kind of font under the sun, how
> does that break any GUI?
>
> > no sound capability, ....
>
> How is that needed in X? EsounD works just fine.
>
Sorry, I didn't know I need that to get sound. Sould it come along?
>
> > 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?
>
> Please, inform yourself. The Frequently Rehashed Topics list could be
> a good starting point.
>
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?
After all, you may argue that Linux/X is designed for computer professionals
only, then I will have nothing more to say.
>
> mawa
> --
> "The 6 remaining corporations [world-wide] have shown great interest
> in merging with each other [...] Clearly, the stage is being set for
> the creation of UniCorp, a $92 trillion corporation that produces
> every product on earth, from canned yams [...] to poison gas."
------------------------------
From: "Tom Emerson" <[EMAIL PROTECTED]>
Subject: Looking for an analogue...
Date: Thu, 24 Jun 1999 12:42:18 -0700
The primary system I use at work is an HP3000 "business" computer [as
opposed to the 9000-series "unix" computers] On this system we have an IPC
facillity known as "message files" which have some characteristics of named
pipes and message queues, but it seems they go beyond this in subtle ways --
I'd like to know if there are any "closer" ananlogues to what the HP
considers a message file and what's available in linux/unix.
On the HP, a message file has the following characteristics:
1) it's a named physical file on the system and must be created either by a
system command or options specified in the FOPEN call [directly equivelent
to a named pipe -- using mkfifo or popen() -- so far so good]
2) files on the HP are [typically] pre-built with some maximum number of
records, known as the FLIMIT. The current EOF of a file, especially message
files, is often less than this FLIMIT, but (obviously) can be the SAME as
the FLIMIT [at which point the file is considered to be "full"]
3) writes to the file are appended to the end of the file and will only
BLOCK when the file is FULL
4) reads from the file are taken from the front ONLY [i.e., no "directed"
reads to, say, record #3]; at the completion of the read, the record read is
removed from the file
4a) with a special call to the MPE equivelent of fcntl, a program may
perform a "non-destructive" read, or "peek" at the next record to be read --
i.e., at the completion of the read the record is NOT removed from the file
and the next read posted against this file will return the same record.
So far, with the possible exception of 4a, this is identical to a named pipe
and/or message queue [or even an AF_UNIX socket, I suppose], but here are
some characteristics that DON'T appear to be similar:
5) one or more processes may WRITE to the file WITHOUT blocking even though
there are NO readers of the file. As mentioned in #3, the only time a
process BLOCKS is when the file becomes physically FULL. I suppose this is
would be equivalent to a named pipe IF the message file had an FLIMIT of one
record.
6) multiple processes may write and CLOSE the file without loss of data --
records remain "in" the message file until
some process READS them
7) processes READING from the file will either BLOCK or return an error
[EOF] if the file is EMPTY. The specific action taken depends upon certain
criteria, and can be modified via fcntl-like calls. In particular, the
process READING from the file will BLOCK if (a) another proccess has the
file open for writing [normal operation] or (b) no process has opened the
file for writing AND this is "the first read"
As I said, these differences are subtle, but important. Where we use these
is for data synchronization between two systems -- we have a program on
system "A" that writes to a message file. A program on system "B", using an
NFS-like access to the file on system "A", reads this file. When system "B"
is taken down [for maintenance, backup, etc.], the program(s) on "A"
continue to write to this file without stopping. Since we want to continue
processing on "A" without blocking "because system "B" is being backed up",
the size of these files can be a million records or more. When system "B"
starts back up again, it picks up where it left off and "drains" the file
from system "A".
>From what I read about named pipes, message queues, and AF_UNIX sockets,
here is what I understand:
1) the WRITING process WILL block if there are NO readers on the other end
2) the WRITING process WILL block on the SECOND write to the file if the
READING process has not yet read from the file
3) there are theoretical maximums to the size of the record that can be
written [something like 4k] as well as the number of "outstanding" writes
from multiple processes [16k, I think I read]
4) it's undefined [to me, at least] as to what happens if a process WRITES
to the file THEN closes it while a corresponding READ process simply opens
and closes the file [i.e., no actual "read" is performed] -- will the next
open-for-read actually retrieve this "record-in-limbo"?
------------------------------
Date: Thu, 24 Jun 1999 21:30:05 +0200
From: Marc Mutz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Run in background
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
------------------------------
From: "Stefan Monnier <[EMAIL PROTECTED]>"
<[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 24 Jun 1999 17:02:09 -0400
>>>>> "Ralph" == Ralph Glebe <[EMAIL PROTECTED]> writes:
> [...]
Wring question. The question should be:
Why C++ ?
-- Stefan
------------------------------
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
From: [EMAIL PROTECTED] (Vladimir Z. Nuri)
Subject: Re: TAO: the ultimate OS
Date: Thu, 24 Jun 1999 20:56:37 GMT
Christopher Browne ([EMAIL PROTECTED]) wrote:
: As a common "for instance," in DBMS-oriented applications, I have
: quite regularly heard users ask for the ability to modify the primary
: key to a DB table, which is one of those basic things that by
: necessity *cannot* be fiddled with. I *can't* modify the application
: to allow what they want; the system *forbids* this, and that was in
: fact the original intent.
there should be no restriction on this if the new primary key
is unique, imho. give the user whatever they want that is not
logically impossible.
another example: the end user wants to increase the space
for their linux partition and decrease space on their windows
partition. without reformatting. how many zillions of hours
have been spent in this operation by end users? only because
programmers haven't written the code to move around partitions
on a hard drive? a clear cut case where programmer convienience
was chosen at huge sacrifice to user convenience.
: >but imho it is largely responsibility
: >of programmer to anticipate what users want without requiring them
: >to articulate it explicitly. true? the greatest designer gives you
: >something you didn't even know you wanted!! and you realize, only
: >upon seeing it, that you can't live without it<g>
: Clearly the writings of someone who has signed off on a lot of
: computer system design specifications. Not.
your jab eludes me, sorry..?? what is your point?
--
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
"in theory, there's no difference [EMAIL PROTECTED]
between theory and practice, mad genius research lab
but in practice there is!" http://www8.pair.com/mnajtiv/
------------------------------
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
From: [EMAIL PROTECTED] (Vladimir Z. Nuri)
Subject: Re: TAO: the ultimate OS
Date: Thu, 24 Jun 1999 21:01:14 GMT
Terry Murphy ([EMAIL PROTECTED]) wrote:
: To be fair, Unix was more of an exploratory/reseach project and not
: really intended to be a product, and this sort of engineering is
: necessary. But, of course, projects like these need to be engineered
: into workable products, and not just put out in unfinished form. I
: see open source as more exploratory- than product-oriented, and I'm
: not even sure many would disagree with that.
amen.. and the reason linux is gaining widespread support & interest
is that it is becoming more product-oriented. product-oriented
involves new kinds of discipline that "exploratory" lacks.
the more linux becomes product-oriented, the more successful &
mainstream it will become. to the extent that developers resist
this, linux will hit diminishing marginal returns & crest off.
that point has not yet come, but I can easily see in the near
future a lot of handwringing by the community about why their
penetration has not increased after a peak saturation point.
: There are many of us who would argue that open source is not
: successful (technically) at all. The main successful Open Source
: projects are simply implementations of well understood systems, such as
: the Linux kernel or Apache, and tend to require minimal API or user
: interface design, and are tested by brute force methods (e.g. release
: to a lot of users and see if it works for them).
exactly. Unix is one of the most well understood &
standardized OSes on the planet.
I don't see this model
: being extended to original, high quality, and innovative products, such
: as say IE5 (c.f. Mozilla as a failure as far as that goes). There are
: SOME exceptions: the GIMP and GNOME, for example, are turning out
: REASONABLY well, but those exceptions are few and far between, and
: really do not compare to high quality, commerical applications.
exactly.. the next notch up is not mere replication, but INNOVATION.
--
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
"in theory, there's no difference [EMAIL PROTECTED]
between theory and practice, mad genius research lab
but in practice there is!" http://www8.pair.com/mnajtiv/
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Thu, 24 Jun 1999 20:11:46 GMT
In article <[EMAIL PROTECTED]>,
Johan Kullstam <[EMAIL PROTECTED]> wrote:
> "Ralph Glebe" <[EMAIL PROTECTED]> writes:
[&<]
>
> yes. the C part is very mature. the code produced is solid.
>
> the C++ standard keeps changing. for example, i had to recode a lot
> of my applications in my transition from gcc-2.7.2.* to egcs. the
> egcs libstdc++ seems highly volatile. i'd rather keep as little
> dependent upon it as possible. at least, now, if C++ libs break, i
> can at least recompile what i have without the catastrophe of
> missing/broken libc.
The C++ standard is no longer changing, period. The compilers and
library implementations are changing because they are still catching up,
but the standard has been finished for over a year.
Please be careful not to fud.
Jack
[&<]
> --
> johan kullstam
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
From: [EMAIL PROTECTED] (Vladimir Z. Nuri)
Subject: Re: TAO: the ultimate OS
Date: Thu, 24 Jun 1999 20:50:12 GMT
Anonymous ([EMAIL PROTECTED]) wrote:
: Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote:
: > most of above are subject to the evolutionary pressures of extinction.
: > - programmers who do not understand how users think will go
: > extinct.
: Not every programmer needs to be a UI guru (I interpret your use of "user"
: as end-user).
revealing another bias that merely being concerned with the UI is
the realm of those who deal with users.. bzzzzzzt.. everyone designing
the OS, from top down, needs to be concerned with user requirements.
some very highlevel requirements (e.g. need to be virus proof)
are driven by user demand.. & just good sense
: The founders of Linux do not design the UI and I'm glad that they aren't
: stuffing the OS core with such peripheral, however central to end-user
: computing experience, parts.
I am asserting the point that the entire OS and not merely the UI
needs to be reoriented around the user.. I believe an attempt to
put a friendly GUI on linux will ultimately fail in the long run
to achieve ease-of-use or end-user-friendly goals.. but not
very soon. its a dead end I don't think will be recognized for many
years. this is not to say the GUI work is being wasted. it could
be used on top of another OS.
: You cannot dumb down a computer below a certain level without sacrificing
: its functionality.
moot point. the computer can demonstrably simplified tremendously
beyond what unix supplies users.
--
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
"in theory, there's no difference [EMAIL PROTECTED]
between theory and practice, mad genius research lab
but in practice there is!" http://www8.pair.com/mnajtiv/
------------------------------
From: [EMAIL PROTECTED] (Dave Platt)
Subject: Re: Need help porting DOS app that uses parallel port (Part II)
Date: Thu, 24 Jun 1999 18:56:52 GMT
In article <[EMAIL PROTECTED]>,
Chris A. Henesy <[EMAIL PROTECTED]> wrote:
>So it sounds to me like the best thing for me to do is grab a copy of
>"Linux Device Drivers" and "port" the "function library" into a device
>driver. The hard part is done really. The C code detailing the
>communications protocol with the card is provided. I just have to add the
>code to make it a kernel module, and to have it talk through the
>appropriate kernel interfaces to the parallel port and not directly
>to the hardware. How close am I here? Anyone have any suggestions as to
>which kernel modules I should use as an example? What kernel code I
>should look at to start with?
If you don't require blindingly-fast access to the port, and if you're
willing to write a little set-user-ID-root wrapper program, then
there's a much easier way.
Write a wrapper program which is installed suid-root. It would do
three things:
- use the ioperm() call to gain read/write access to the parallel
port's ports (#cough#).
- use setuid() or a similar call to give up root privilege, and
return the process to the real user-ID of the user running it.
- use exec() or a similar call to invoke your actual program.
The actual program would be able to use the function library. It
would use the inb() and outb() or similar functions (compiled with the
-O2 option) to generate real input and output instructions.
Each port access will fault, because the port I/O instructions are
privileged. The kernel will check the port address against the port
numbers which had been enabled via ioperm(), see that there's a match,
execute the I/O from within the kernel, and then return to the user
program.
This method doesn't allow rapid back-to-back port I/Os in the way that
a device driver does, but it'll probably be fast enough for your
purposes, and doesn't require writing any kernel/driver code.
--
Dave Platt [EMAIL PROTECTED]
Visit the Jade Warrior home page: http://www.radagast.org/jade-warrior/
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
------------------------------
From: James Youngman <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: Linux uid limits!
Date: 19 Jun 1999 00:06:45 +0100
James Hewitt <[EMAIL PROTECTED]> writes:
> Okay, what is the "correct" way to specify an integer of a specific
> size so that code can be cross-platform? If there isn't an ANSI
> standard, is there at least a convention for Linux?
Yes, use Autoconf.
--
ACTUALLY reachable as @free-lunch.demon.(whitehouse)co.uk:james+actually
------------------------------
From: [EMAIL PROTECTED] (Paul D. Smith)
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 15:22:49 -0400
Reply-To: [EMAIL PROTECTED]
%% [EMAIL PROTECTED]
jm> The way I figured out what was going on I felt that GNOME provided
jm> another layer of abstraction as well. Because in actuality, I'm
jm> using the Enlightenment WM, not GNOME. (AFAICT) The two have
jm> different Config managers and what not, and it seems like the
jm> GNOME configuration manager allows me to switch between other
jm> GNOME WMs without restarting the X server. Also, with the GNOME
jm> config manager, I can call up any GNOME WM configuration program,
jm> but not the other way around.
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.
There are at least two window managers which are "Gnome compliant"; that
is, they have some innate knowledge of the Gnome desktop and respond to
it. One of these is Enlightenment. The other is IceWM. Maybe there
are others, I'm not sure. The latest development snapshots of FVWM also
support Gnome in this way. Any window manager _can_, if the code is
added.
You can certainly use other, non-"fixed" window managers and it will
work, but some of the extra integration features may not be there.
Likewise, the Gnome desktop is really constructed of lots and lots of
individual apps, but they all use a common widget set and guidelines so
they, in theory, work well together. You can use these without using
the rest; for example I know a number of people who run the Gnome panel,
but don't run much else of Gnome.
KDE is the same, although KDE does actually come with its own window
manager. But again, you don't have to use it, you can use something
else. And again, you can swap out individual parts although you may
lose some of the tight integration. As I mentioned, efforts are ongoing
to make Gnome and KDE apps play together more seemlessly.
jm> I realize that X is still the server, and that window managers use
jm> the abstractions that X provides to interact with hardware.
Every X application does. One of the important differences between X
and Windows is that window managers are just another application. They
perform certain functions and there are standards as to how they're
supposed to behave, etc. but you can stop/start/change them at
will... you can even use X without a window manager at all!
jm> Also, I know that Gnome is not a layer between KDE and X. But I
jm> was under the impression that Gnome WAS a layer between
jm> Enlightenment and X, or any other WMs that chose to use the GNOME
jm> tools, etc...
No. Enlightenment is a window manager. Gnome is a desktop environment,
one component of which is a window manager--and Enlightenment is the
"default" WM that most Gnome distributions use.
You can run Enlightenment without the rest of Gnome, and you can run
Gnome with some WM other than Enlightenment.
No layers involved--more like interlocking parts :).
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
From: [EMAIL PROTECTED] (Vladimir Z. Nuri)
Subject: Re: TAO: the ultimate OS
Date: Thu, 24 Jun 1999 21:14:58 GMT
Stefaan A Eeckels ([EMAIL PROTECTED]) wrote:
: Pray tell me how UNIX would have been any better if pipes and 'C'
: would have been invented in 1969, or if the original ideas would
: have been abandoned in 1974 when it was recoded in 'C'?
: Requiring *all* the concepts to be invented (stumbled upon) before
: a line of code is written is just plain impossible. Limiting yourself
: to what you've originally committed to paper is just plain stupid
: (but it might be a contractual requirement, in which case I refrain
: from commenting).
I agree, but after a few new & useful things have been pasted on top, it
helps to revisit the entire design and figure out how they can
be integrated into the core.
: intrinsic value of the "everything is a file" concept.
I feel very strongly that future OSes will revolve more around
"everything is an object"..
--
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
"in theory, there's no difference [EMAIL PROTECTED]
between theory and practice, mad genius research lab
but in practice there is!" http://www8.pair.com/mnajtiv/
------------------------------
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
From: [EMAIL PROTECTED] (Vladimir Z. Nuri)
Subject: Re: TAO: the ultimate OS
Date: Thu, 24 Jun 1999 20:53:42 GMT
Stefaan A Eeckels ([EMAIL PROTECTED]) wrote:
: > my own requirements document.. but unix programmers do not
: > think in terms of the above. instead we have, as ESR
: > glorifies,
: >
: > code -> release -> code -> release -> code -> release
: Are you perchance a PHB? Don't forget that what ESR describes
: is the "prototype -> beta -> release" part of your
: description of a "good development", not the "requirements ->
: design" part, which has been done by the original author
: *before* code is released.
notice you emphasize a sort of "rugged individualist"
approach to design that doesn't involve collaboration. i.e.
single programmer makes all the design choices early on.
but surely collaboration can be introduced into the requirements/
design process, with good benefits. in fact perhaps this
would be a significant improvement worth seriously pursuing
on the worlds next open source OS..?
p.s. what is a PHB
--
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
"in theory, there's no difference [EMAIL PROTECTED]
between theory and practice, mad genius research lab
but in practice there is!" http://www8.pair.com/mnajtiv/
------------------------------
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
From: [EMAIL PROTECTED] (Pete Zaitcev)
Date: Thu, 24 Jun 1999 19:58:40 GMT
>From: Junyang Gu <[EMAIL PROTECTED]>
>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?
Go right ahead pal. Innovate. Do something. If it's good, others will
follow. This is how our Free Software world works.
Until you wrote something worthwhile, I shall hold to my X11. Thanks.
--Pete
------------------------------
From: "Aaron Thompson" <[EMAIL PROTECTED]>
Subject: Need a.out compiler
Date: Thu, 24 Jun 1999 15:01:47 -0500
I need help compiling a.out binaries. I have an a.out assembler and linker,
i just don't have the compiler. If anyone has the neccessary files
"/usr/lib/gcc-lib/i386-linuxaout/*", please let me know. You can email them
to me at [EMAIL PROTECTED]
------------------------------
** 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
******************************
