The Future of FreeBSD...
Martin Birgmeier
being one of them (i.e. FreeBSD aficionado), during the past year or
so I got the very strong impression that the FreeBSD effort is most
likely going to die, for at least two reasons:
1) For whatever reasons, Linux has a much larger user *and* developer
base than FreeBSD, and therefore can provide *high quality*
software at a much faster rate.
2) FreeBSD developers are more or less reinventing the wheel, and even
that wheel is basically from the stone-age of OSs as well... I
understand that there is going a large amount of effort into making
FreeBSD an advanced Unix system (unified buffer cache comes to mind),
but basically it's still the same old story.
Therefore, also during the past months, several ideas sprang up in my
mind, which I would like to share with the rest of the net community:
1) In order to separate FreeBSD from the rest of the free Unix efforts,
merge with Lites as developed by Johannes Helander *as soon as
possible* (though I admit I don't know how possible this is at all,
comparing with the state of affairs regarding the two BSD camps).
This, in my opinion, would give FreeBSD the necessary edge over its
competitors to stay alive and healthy; it might also help Lites to
gain a wider user base.
The remaining ideas might not be so important, but here they go anyway:
2) Reorganize the sup tree such that it is not ordered by subdirectories,
but rather by functionality groups. With the current setup, you
basically can fetch either everything or nothing, except maybe for
the games and ports sections.
3) Introduce the ELF binaries format. I don't know much about it, but it
seems to be the way of the future for various reasons.
4) Try to reach an agreement with the NetBSD developers on as common a
source tree as possible, such that mutual fertilization can be
achieved more easily. In my opinion it would be best to really have
a physically common tree, with mirrors to the development groups.
This is just my two cents... and please don't tell me that I may just step
forward and implement my proposals myself - I don't have the time for that,
although I'd certainly like to do it. Besides - I don't know how well
known is the book by Antoine de Saint Exupery, `The Little Prince', but
anyways, the major message of that book is that you are responsible for
the persons whom you have made to believe/rely on you. In the same vein
I dare to say that the FreeBSD developers are in a way responsible for
their product on which many people rely/which many people enjoy.
As a humble contributor of a tiny piece of *BSD code,
Martin
--
Martin Birgmeier Martin.B...@nt.tuwien.ac.at
Technische Universitaet Wien mbir...@email.tuwien.ac.at
Institut fuer Nachrichtentechnik und Hochfrequenztechnik
Jordan K. Hubbard
Martin Birgmeier <mar...@hal.nt.tuwien.ac.at> wrote:
>being one of them (i.e. FreeBSD aficionado), during the past year or
>so I got the very strong impression that the FreeBSD effort is most
>likely going to die, for at least two reasons:
I don't see either of these arguments as being very on-target..
Sure, Linux has a large developer/user base, but then so does SCO
and you don't see people crying that SCO is going to destroy FreeBSD
any day now. There is plenty of room for BOTH systems, in reality,
and if anything I think Linux has *helped* FreeBSD by drawing more attention
to the viability of free software. There was a time not too long ago
when commercial interests wouldn't touch free software with a stick,
but the FSF and Linux have gone a fair way towards changing that and
this can't be anything but a good thing.
>2) FreeBSD developers are more or less reinventing the wheel, and even
> that wheel is basically from the stone-age of OSs as well... I
> understand that there is going a large amount of effort into making
> FreeBSD an advanced Unix system (unified buffer cache comes to mind),
> but basically it's still the same old story.
VM/CMS is from the stone age. RSTS is from the stone age. 4.4 Lite
is hardly from the stone age, my friend! Progress on the BSD code
base still continues at a very healthy pace and sometimes you WANT code
that's had a chance to mature. The fact that our networking code has had
almost 10 years to stabilise and work in MANY different strange and
stressful networking scenarios has in fact helped us considerably.
I don't buy this point.
>1) In order to separate FreeBSD from the rest of the free Unix efforts,
> merge with Lites as developed by Johannes Helander *as soon as
> possible* (though I admit I don't know how possible this is at all,
> comparing with the state of affairs regarding the two BSD camps).
We talk to Johannes fairly frequently and support his project, but
do you really think that all of our ISP "customers" would suddently jump
up and down over something that wasn't even of obvious utility to them?
I think not. You're clearly of an academic mindset where "newer and
cooler" is equivalent to "better", and that's just not the case in the
commercial world. In fact, many members of the project would LEAVE
were we to suddenly jump on the Mach bandwagon since universal agreement
on microkernel technology is hardly here, and there are in fact a number of
detractors alive and well in the UNIX camp.
>This, in my opinion, would give FreeBSD the necessary edge over its
>competitors to stay alive and healthy; it might also help Lites to
>gain a wider user base.
HOW would it give it an edge? You're long on rhetoric and short on details
here.. I see no substantive argument as to WHY Lites will save our
collective butts and bring happiness to our user base, and I won't accept
"because it's new and it's the way forward" as an argument. We need more
concrete examples of what a new technology will buy us before we sign on
and take the significant hit in testing and re-certifying our OS for
stability, and I think our users wouldn't have it any other way.
Like I said, I do support Johannes and his project as it makes a good
*alternative* for those with more experimental mindsets and alternatives
are good in general, but a mainstream technology? You'll need to be
significantly more convincing..
>2) Reorganize the sup tree such that it is not ordered by subdirectories,
> but rather by functionality groups. With the current setup, you
> basically can fetch either everything or nothing, except maybe for
> the games and ports sections.
I don't see this at all. Have you *looked* at the interdependencies
within the source tree? What good would it do to get gcc without any
of its include files? Or all the file munging tools without the libraries
they depend on?
>3) Introduce the ELF binaries format. I don't know much about it, but it
> seems to be the way of the future for various reasons.
We're going to do that someday, yes, but we're waiting for the compiler tools
to mature a little where ELF is concerned.
>4) Try to reach an agreement with the NetBSD developers on as common a
> source tree as possible, such that mutual fertilization can be
> achieved more easily. In my opinion it would be best to really have
> a physically common tree, with mirrors to the development groups.
We do this as best we can now and any further commonality will simply
have to wait until more people are working in common with both groups.
You can lead a horse to water, but shoving his head under isn't a good
way of making him drink. All things in good time..
I don't mean to quash what was probably a well-intended set of points,
but if you're going to preface a set of suggestions with "this is what
I think FreeBSD needs to do or it's dead" then you'd better put a LOT
more thought into those suggestions and perhaps try to be a little
less naive about the realities of this market.
Jordan
Peter da Silva
Martin Birgmeier <mar...@hal.nt.tuwien.ac.at> wrote:
> 2) FreeBSD developers are more or less reinventing the wheel, and even
> that wheel is basically from the stone-age of OSs as well... I
> understand that there is going a large amount of effort into making
> FreeBSD an advanced Unix system (unified buffer cache comes to mind),
> but basically it's still the same old story.
FreeBSD *is* an advanced UNIX system.
> 1) In order to separate FreeBSD from the rest of the free Unix efforts,
> merge with Lites as developed by Johannes Helander *as soon as
> possible*
I would rather not. FreeBSD runs in 4M of RAM. It's totally solid and fast
with X in 16M. Going to Lites will probably double the kernel size and make
a serious impact on memory requirements.
--
Peter da Silva (NIC: PJD2) `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Har du kramat din varg idag?"
Mike Haertel
Martin Birgmeier <mar...@hal.nt.tuwien.ac.at> wrote:
>1) In order to separate FreeBSD from the rest of the free Unix efforts,
> merge with Lites as developed by Johannes Helander *as soon as
> comparing with the state of affairs regarding the two BSD camps).
>
>competitors to stay alive and healthy; it might also help Lites to
>gain a wider user base.
I think this is a bad idea. Mach is SLOW. As of right now, there
is only one reason I can imagine to do this: to support multiprocessors.
But, better (more efficient) to support them with a conventional kernel.
So I think a better idea would be: rework the kernel to support
multiprocessors, and maybe kernel multithreading. (When you've
got one, it's pretty easy to do the other.)
In a few years I'd like to be running FreeBSD on my 4-processor P6 box... :-)
>2) Reorganize the sup tree such that it is not ordered by subdirectories,
> but rather by functionality groups. With the current setup, you
> basically can fetch either everything or nothing, except maybe for
> the games and ports sections.
Bad idea. IMHO one of the big problems with the Linux community is the
chaos involved in getting the sources. It's partially caused by the
"package" mentality associated with the major Linux distributions, where
you pick and choose what to install. I really like the FreeBSD
all-or-nothing approach in the binaries, and I think it is similarly
appropriate to apply that to the sources.
>3) Introduce the ELF binaries format. I don't know much about it, but it
> seems to be the way of the future for various reasons.
Your best suggestion so far. Especially if FreeBSD supports binary
compatibility with Linux and/or SVR4, it should thrive even if it's
not the most popular system.
Matthe...@cs.cmu.edu
Future of FreeBSD... Jordan K. Hubbard@violet (5085)
> In fact, many members of the project would LEAVE were we to suddenly
> jump on the Mach bandwagon since universal agreement
> on microkernel technology is hardly here, and there are in fact a number
> of detractors alive and well in the UNIX camp.
To my mind, the microkernel is the way of the future. With increasingly
diverse processor architectures available, this is one technology that
will keep things manageable. With microkernels, a development effort
can proceed with far fewer individuals because the maintainance cost of
additional platforms is minimal. Thus we can have a situation better
suited for small businesses and public domain developers. Instead of
large numbers of mediocre programmers producing huge amounts of mediocre
code (as many firms seem to do), we have a small number of excellent
programmers producing a smaller, but functionally equivelant, amount of
excellent code.
There's a strong performance argument, because microkernels seem
inherently slower. It is my opinion that advantages outlined above
heavily outweigh this, especially when one considers the high
performance offered by new processors of today. There will come a time,
soon, when the added stability and feature sets of microkernel OSes will
dominate.
What does this have to do with FreeBSD? Not a thing that I can see. My
understanding of FreeBSD is that it was designed to run on the Intel
platform, period. With this design goal in mind, what is the advantage
of sacrificing speed to have an ultraportable OS? Especially when you
consider that Intel processors are relatively slow when compared to the
RISC processors available.
-Matt
Jordan K. Hubbard
>There's a strong performance argument, because microkernels seem
>inherently slower. It is my opinion that advantages outlined above
>heavily outweigh this, especially when one considers the high
>performance offered by new processors of today. There will come a time,
>soon, when the added stability and feature sets of microkernel OSes will
>dominate.
The areas in which we face the most resistance WRT performance (and you
hit it on the head when you picked this as the main reason the UNIX
traditionalists scream about microkernels) is in high-speed networking
where every bit of layering is crucial and for applications like
video, you can't afford any interruptions in the data stream. FreeBSD
in general is still a ways off from this goal considering that we've
got no real-time extensions to provide metered response, but there's
no use in making the problem any more difficult!
Jordan
Jon Jenkins
a completely subjective opinion of what FreeBSD needs
to survive and propser:
(GUI GUI GUI GUI GUI GUI )^100000000000000000000000000000
We could all learn something from MS Windows success.
An easy to use GUI X development tools ala Borlands Delphi
for Windows. This makes GUI development easy and quick.
Probably this would be based on Xview or Motif clone
maybe even Tcl/Tk but the next generation allowing users
to "drag n drop" user interfaces for X. This technology
is technically feasible with current tools and if done
properly would without a doubt become the industry
standard UNIX/X develpment tool.
With this tool the basics i.e make it easy
to install with simple easy to use
graphical user interfaces for everthying from
network setup to system configuration to
file management to program development to ...,
are easy and simple to develop.
Once this happens the "hords" will take it form there
as they have with MS Windows and develop/port
all sorts of proggies to make life easier.
Contrary to both opinions I dont think
FreeBSD needs to be bleeding edge to survive
in fact I think it would be its death nell
if all this "new technology" is introduced
without removing the archaic academic UNIX
philosophy "if it ain't hard to use it ain't
UNIX" which still pervades the UNIX mindset
of both academic and commercial thinking.
Jon
--
----------------------------------------------------------------------
Name: Dr Jon Jenkins
Location: Digital Equipment Corp, NaC,
Burnett Place, Research Park,
Bond University, Gold Coast
QLD, AUSTRALIA 4229
Phone: 61-75-75-0151
Fax: 61-75-75-0100
Internet: jenk...@ozy.dec.com
Close Proximity: "HEY YOU !!!"
The opinions expressed above are entirely personal and do not
reflect the corporate policy of DEC or the opinions of DEC management.
-----------------------------------------------------------------------
Matthew Jason White
Future of FreeBSD... by Ken Nak...@er6.rutgers.e
> Take a look at NetBSD source tree. What you're saying isn't intrinsic
> to microkernel architecture.
No, there have always been those who port each new version of a software
to multiple systems. The fun thing about microkernels is that this
becomes no longer necessary. The cut in development time will
eventually justify the lessened performance in the same way that C
replaced assembly (at the time, C was significantly slower...today I
suspect that optimizing compilers make the opposite true on some
architectures).
>
> >Instead of large numbers of mediocre programmers producing huge
> >amounts of mediocre code (as many firms seem to do), we have a small
> >number of excellent programmers producing a smaller, but
> >functionally equivelant, amount of excellent code.
>
> How do you guarantee the quality of programmers? What if you end
> up with small number of mediocre programmers? It has nothing to do
> with microkernel architecture.
That's a management problem. The fact is, one version of a piece of
software is less time consuming to maintain than twelve. For many
corporations today, it simply is not an option to pay extra for the
really topnotch programmers because they need extra people to do ports.
If you aren't porting significantly, then you can shell out for better
programmers in few numbers.
How do you insure excellent programmers? If they suck, fire them. Or
better yet, do a good job checking references.
-Matt
Jon Jenkins
>In article <3umkok$d...@nntpd.lkg.dec.com>,
>Jon Jenkins <jenk...@ozy.dec.com> wrote:
snip ....
>Funny you should mention that, but Sun is currently developping a product
>called SpecTCL which is TCL/Tk with a drag'n'drop GUI builder. They plan
>to announce it when the Windows, Mac and X versions are finished beta
>testing. As I understand it, the TCL/Tk part of the product is and will
>remain freely usable under the Berekeley licence.
This is a good start. Personally I think the "interpreted" type
interface to GUI API is "last generation". Have a look at Borlands
Delphi to see how I would "like" to see X development done. There
is no technical reason it could not be so. We have all the C++
tools to do this type of "templated" interface. We also need
the "integrated" ancilliary tools such as bitmap, icon, cursor
editors a well as object based design so as to allow easy
user extension to create their own extended objects from
standard base objects. In fact others have already done most
of the work in this respect!
>
>You might also not know that SCO's latest version of UNIX uses something
>similar called Visual TCL to build and extend its system admin toolset.
>This is basically TCL scripts with access to Motif widgets. They have
>rigged it so that you can write Visual TCL scripts and execute them from
>text mode terminals as well as X and still get the same GUI look and feel.
Ditto for this. I suppose this is better then nothing but Tcl/Tk
is still obtuse and archaic enough to frighten most users away. The
speed issue of interpreted scripts also concerns me although with
100MHz+ Pentiums becoming the norm I suppose speed
is really a moot point. As to Motif while it is a commercial
product and not freely available I am not really interested!!
FreeBSD should be exactly that: Free with source code.
>
>They are already doing this kind of thing. Have a look through the TCL/Tk
>archives sometime. There is an AMAZING variety of applications already
>available.
I am hoping to participate with Terry Lambert in something
soon but I think it is more than a two person effort. Interested ????
>
>
>
>--
>Michael Dillon Voice: +1-604-546-8022
>Memra Software Inc. Fax: +1-604-542-4130
>http://www.memra.com E-mail: mic...@memra.com
Warner Losh
>to "drag n drop" user interfaces for X. This technology
>is technically feasible with current tools and if done
>properly would without a doubt become the industry
>standard UNIX/X develpment tool.
Hmmm, I guess I should have tried harder to get the FreeBSD release of
OI and ObjectBuilder out the door :-(. Its been doing that for
years...
Oh well.
Warner
--
Warner Losh "VMS Forever" home: i...@village.org
Cyberspace Development, Inc work: i...@marketplace.com
Makers of TIA, The Internet Adapter. http://marketplace.com/
Terry Lambert
]
] To my mind, the microkernel is the way of the future. With increasingly
] diverse processor architectures available, this is one technology that
] will keep things manageable. With microkernels, a development effort
] can proceed with far fewer individuals because the maintainance cost of
] additional platforms is minimal. Thus we can have a situation better
] large numbers of mediocre programmers producing huge amounts of mediocre
] code (as many firms seem to do), we have a small number of excellent
] programmers producing a smaller, but functionally equivelant, amount of
] excellent code.
A microkernel is not the only possible hardware abstraction
mechanism (the main benefit you cite here), and the Mach
microkernel is not the best possible microkernel for a number
of reasons. Chorus (a proprietary microkernel implementation
being used for advanced projects by Novell) addresses a number
of issues in Mach, most notably causing a great reduction in
the message overhead and the amount of protection domain
crossing that goes on.
Nevertheless, there are many projects that in fact abstract
the hardware sufficiently to obviate the need for that part
of the microkernel's capability. SVR4.2 ES/MP is one example
and NT is another.
] There's a strong performance argument, because microkernels seem
] inherently slower. It is my opinion that advantages outlined above
] heavily outweigh this, especially when one considers the high
] performance offered by new processors of today. There will come a time,
] soon, when the added stability and feature sets of microkernel OSes will
] dominate.
The problem with tis argument is that I can always run faster
by writing closer to the glass, and faster is aways better no
matter how fast you are already running. 8-).
] What does this have to do with FreeBSD? Not a thing that I can see. My
] understanding of FreeBSD is that it was designed to run on the Intel
] platform, period. With this design goal in mind, what is the advantage
] of sacrificing speed to have an ultraportable OS? Especially when you
] consider that Intel processors are relatively slow when compared to the
] RISC processors available.
Your understanding of the design of FreeBSD is flawed. It is
intended to be portable to multiple platforms. That it is not
already distributed on non-Intel platforms is a portation and
political issue, not a design issue.
The sacrafice of speed is only necessary if you buy into the
Microkernel mechanism for hardware abstraction, and then that
is largely irrelevent unless you choose a particular microkernel
technology that exhibits the limitations you have outlined.
That there is not a non-proprietary technology microkernel for
use in abstracting the hardware interface is a seperate problem.
Terry Lambert
te...@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Ken Nakata
>Excerpts from netnews.comp.unix.bsd.freebsd.misc: 20-Jul-95 Re: The
>Future of FreeBSD... Jordan K. Hubbard@violet (5085)
>> In fact, many members of the project would LEAVE were we to suddenly
>> jump on the Mach bandwagon since universal agreement
>> on microkernel technology is hardly here, and there are in fact a number
>> of detractors alive and well in the UNIX camp.
>To my mind, the microkernel is the way of the future. With increasingly
>diverse processor architectures available, this is one technology that
>will keep things manageable. With microkernels, a development effort
>can proceed with far fewer individuals because the maintainance cost of
>additional platforms is minimal.
Take a look at NetBSD source tree. What you're saying isn't intrinsic
to microkernel architecture.
>Instead of large numbers of mediocre programmers producing huge
>amounts of mediocre code (as many firms seem to do), we have a small
>number of excellent programmers producing a smaller, but
>functionally equivelant, amount of excellent code.
How do you guarantee the quality of programmers? What if you end
up with small number of mediocre programmers? It has nothing to do
with microkernel architecture.
/kenn
--
Ken Nakata <kenn@{eden,remus}.rutgers.edu> | "http://remus.rutgers.edu/~kenn/"
Rutgers, The State University of New Jersey | for Logitech TrackMan/MouseMan
New Brunswick, New Jersey | support for NetBSD/mac68k
Matthe...@cs.cmu.edu
Future of FreeBSD... Thor Lancelot Simon@clou (1827)
> Anyone who believes in this kind of ugly software layering is strongly
> encouraged to read Henry Massalin's PhD dissertation,
ftp://ftp.cs.columbia.edu/reports/reports-1992/cucs-039-92.ps.Z.
While I don't purport to have read the entire paper, I have finished
reading through the portion that spoke about kernel structure. I find
it largely irrelevant to this discussion. Maybe there is something
later in the paper that I have not read yet; I'll read the rest tonight
to be sure. From what I have read so far, I have these comments:
The flaws in Mach are not necessarily those of the technologies that
were developed as part of Mach. The very fact that Mach was a research
project here implies the fact that they didn't know what they were
doing. They were experimenting, and one of the things they came up with
was the idea of a microkernel.
The idea of a small piece of hardware dependant code running underneath
the rest of the operating system is not isolated in Mach. If Mach's
idea of layering didn't work out, then that suggests that something else
should be tried, not the whole idea arbitrarily thrown out. Indeed,
this is what groups like OSF, IBM and Microsoft have done with their
offerings and with much more success (Windows NT will even drive serial
ports at 115.2kbps ;-)).
The idea of an abstract hardware interface will not go away. This is
what originally drove the creation the operating system, later it pushed
the development of the idea of the device driver. Each of these
inventions was slower than what existed previously, but they added
enough value in portability, stability, and ease of use that they were
deemed worthwhile. Similarly, the microkernel provides this abstraction
for the system hardware.
Back to Massalin's paper, I find that it has several interesting ideas
that I look forward to reading more about. It is perhaps a too
whimsical to be taken seriously by the community at large. Massalin's
choice of hardware was also rather unfortunate. By limiting himself to
older, CISC, architectures he did not exploit a chance to demonstrate
the value of this technology on modern systems.
I find the use of assembly language for the implementation of the
operating system to be highly questionable. Assembly language is both
non-portable and difficult to debug. So while this operating system
runs well on the systems for which it has been implemented, it is highly
unlikely that it will make its way to other platforms. It is unclear to
me at this point whether the assembly implementation is integral to the
concepts developed or if perhaps the idea of runtime code generation
could be implemented in some other language, such as C or Dylan.
BTW, the URL for the Mach project is:
http://www.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/www/mach.html
-Matt
Thor Lancelot Simon
>Future of FreeBSD... Jordan K. Hubbard@violet (5085)
>
>> In fact, many members of the project would LEAVE were we to suddenly
>> jump on the Mach bandwagon since universal agreement
>> on microkernel technology is hardly here, and there are in fact a number
>> of detractors alive and well in the UNIX camp.
>
>diverse processor architectures available, this is one technology that
>will keep things manageable. With microkernels, a development effort
>can proceed with far fewer individuals because the maintainance cost of
>large numbers of mediocre programmers producing huge amounts of mediocre
>programmers producing a smaller, but functionally equivelant, amount of
>excellent code.
>
>inherently slower. It is my opinion that advantages outlined above
>heavily outweigh this, especially when one considers the high
>performance offered by new processors of today. There will come a time,
>soon, when the added stability and feature sets of microkernel OSes will
>dominate.
Anyone who believes in this kind of ugly software layering is strongly
encouraged to read Henry Massalin's PhD dissertation,
ftp://ftp.cs.columbia.edu/reports/reports-1992/cucs-039-92.ps.Z.
--
Thor Lancelot Simon t...@cloud9.net
Somewhere they're meeting on a pinhead, calling you an angel.
Marcus I. Ryan
>From: Jon Jenkins <jenk...@ozy.dec.com>
>Subject: Re: The Future of FreeBSD...
>Date: 20 Jul 1995 22:19:00 GMT
>I wont reply to the detail of this post but I will give
>a completely subjective opinion of what FreeBSD needs
>to survive and propser:
>(GUI GUI GUI GUI GUI GUI )^100000000000000000000000000000
>We could all learn something from MS Windows success.
What? Abandon ethics? Be a bully? MS-Windows is a success because of Bill
Gates. If it weren't for his marketing and business skills, windows probably
never would have done any better than other GUIs. I remember when Windows 3.0
came out - there were at least 5 or 6 active GUIs on INTEL systems alone, all
being sold in a similar fashion (preinstalled on the system at purchase).
GUI is not why windows won.
>An easy to use GUI X development tools ala Borlands Delphi
>for Windows. This makes GUI development easy and quick.
>Probably this would be based on Xview or Motif clone
>maybe even Tcl/Tk but the next generation allowing users
>to "drag n drop" user interfaces for X. This technology
>is technically feasible with current tools and if done
>properly would without a doubt become the industry
>standard UNIX/X develpment tool.
From http://www.shsu.edu/~stdyxc05/VXP/
VXP -- Visual X windows Programming Interface
VXP is an integrated Motif graphical user interface (GUI) builder.
Application developer can build a working Motif GUI in minutes, simply by
pointing and clicking on predefined icons which represent Motif widgets, then
dragging and dropping them on the design space. VXP provides developer an
environment to design a Motif GUI for your application interactively, and
generates the C code required to producethe GUI. VXP also lets developer edit
non-GUI code of the application, compile the application and test it...
combined with LessTif
(from http://www.cs.uidaho.edu:8000/hungry/microshaft/lesstif.html:
LessTif is the Hungry Programmers' version of OSF/Motif. It will be source
code compatible with Motif, meaning that the same source will compile with
both libraries and work exactly the same.)
I'd say things are coming right along.
>With this tool the basics i.e make it easy
>to install with simple easy to use
>graphical user interfaces for everthying from
>network setup to system configuration to
>file management to program development to ...,
>are easy and simple to develop.
The install is already easy - or at least as easy as the NT and
OS/2 installations I've been through. There are already other X-Windows
applications to do as you suggest. Though the ones I can think of off the top
of my head are commercial, I'd be amazed if there weren't shareware ones out
there somewhere...
>Once this happens the "hords" will take it form there
>as they have with MS Windows and develop/port
>all sorts of proggies to make life easier.
Don't bet on it. Afterall, OS/2 has many of the same kinds of developement
tools and it's still floundering (though it's catching up a little). As much
as I hate to say it, what actually sells and operating system these days is
hype. OS/2 Warp managed to catch up by quite a bit, simply by including the
Internet BonusPak. Do you think that "You on-ramp to the information
superhighway" and "Enhances You Exisiting DOS and Windows(TM)" on the side of
the box did nothing for sales? If FreeBSD had the resources to do the kind of
advertising they have, I bet that FreeBSD would be much more popular. As I
recall, advertising - well, sort of - is what Jordan Hubbard was actually
hired by Walnut Creek to do. His official description was more PR than
advertising, but since we're not trying to sell FreeBSD, one is close enough
to the other :)
>Contrary to both opinions I dont think
>FreeBSD needs to be bleeding edge to survive
>in fact I think it would be its death nell
>if all this "new technology" is introduced
>without removing the archaic academic UNIX
>philosophy "if it ain't hard to use it ain't
>UNIX" which still pervades the UNIX mindset
>of both academic and commercial thinking.
UNIX is not any harder to use than DOS. People talk about having to reconfig
the kernel, and edit some files in /etc, but look at all of the time and
tweaking it takes in DOS just to get some device drivers going, let alone to
get the thing on the network. If you don't network it, there's that much less
configuration. It all depends on what you want to do with it. FreeBSD is
making it easier all of the time. Just don't expect them to sacrifice UNIX
compatibility for "ease of use" (ls will always be ls, etc.) - it would defeat
the purpose.
[Jon's signature snipped]
----------------------------------------------------------------
Marcus I. Ryan |*Diplomacy is the art of saying 'Nice
Asst. SysAdmin, CCE Labs | doggie!' until you can find a rock.
Iowa State University |--------------------------------------
sh...@iastate.edu |*Diplomacy - Letting someone else have
(515) 294-0715 | things your way.
----------------------------------------------------------------
Jordan K. Hubbard
>Hmmm, I guess I should have tried harder to get the FreeBSD release of
>OI and ObjectBuilder out the door :-(. Its been doing that for
>years...
Yeah, you sure should have! :-)
Jordan
P.S. I still have the complimentary copy of the OI manual that Amber
sent me sitting on the floor behind me. Totally useless since any
app I develop with it can't even be run by anyone else save a few
Linux users who are still using an outdated and somewhat buggy version.
Damn shame, that! :-( :-(
Michael Hoess
>> base than FreeBSD, and therefore can provide *high quality*
CD-Manufactures saw a chance to make money with it, and so Linux got it's
free advertising and marketing (My actual PC-magazines shows 6 commercials for
Linux-CD's and a large report on the different Linux-distributions, nothing
large or visible for FreeBSD).
>Perhaps it is time to start integrating
>tools like TCL/Tk and expect and PERL into the system in the same way
>that X and USENET and vi have been added.
And on the other side I think such stone-age tools like vi should be kicked out
(since they make people who worked with comforable DOS-Editors run away) and
replace them with other editors like JOE.
Sorry for my bad english...
Michael Hoess
hoe...@track.informatik.uni-stuttgart.de
Jon Jenkins
thanks for replying to my post.
mar...@ccelab.iastate.edu (Marcus I. Ryan) wrote:
>In article <3umkok$d...@nntpd.lkg.dec.com> Jon Jenkins <jenk...@ozy.dec.com> wri
tes:
>>From: Jon Jenkins <jenk...@ozy.dec.com>
>>Subject: Re: The Future of FreeBSD...
>>Date: 20 Jul 1995 22:19:00 GMT
>
>>I wont reply to the detail of this post but I will give
>>a completely subjective opinion of what FreeBSD needs
>>to survive and propser:
>
>>(GUI GUI GUI GUI GUI GUI )^100000000000000000000000000000
>
>>We could all learn something from MS Windows success.
>
>What? Abandon ethics? Be a bully? MS-Windows is a success because of Bill
>Gates.
Well here we will just have to agree to disagree. See the very
last paragraph for some intresting info.
> If it weren't for his marketing and business skills, windows probably
>never would have done any better than other GUIs. I remember when Windows 3.0
>came out - there were at least 5 or 6 active GUIs on INTEL systems alone, all
>being sold in a similar fashion (preinstalled on the system at purchase).
>GUI is not why windows won.
Actually Windows/386 was the first and the compatilbility problems
killed the other efforts. I'm sure that this compatibilty problem
was not all by "accident".
>
>>An easy to use GUI X development tools ala Borlands Delphi
>>for Windows. This makes GUI development easy and quick.
>>Probably this would be based on Xview or Motif clone
>>maybe even Tcl/Tk but the next generation allowing users
>>to "drag n drop" user interfaces for X. This technology
>>is technically feasible with current tools and if done
>>properly would without a doubt become the industry
>>standard UNIX/X develpment tool.
>
>From http://www.shsu.edu/~stdyxc05/VXP/
>VXP -- Visual X windows Programming Interface
>
>VXP is an integrated Motif graphical user interface (GUI) builder.
>Application developer can build a working Motif GUI in minutes, simply by
>pointing and clicking on predefined icons which represent Motif widgets, then
>dragging and dropping them on the design space. VXP provides developer an
>environment to design a Motif GUI for your application interactively, and
>generates the C code required to producethe GUI. VXP also lets developer edit
>non-GUI code of the application, compile the application and test it...
>
>combined with LessTif
>(from http://www.cs.uidaho.edu:8000/hungry/microshaft/lesstif.html:
>
>LessTif is the Hungry Programmers' version of OSF/Motif. It will be source
>code compatible with Motif, meaning that the same source will compile with
>both libraries and work exactly the same.)
Well this would be a good start as long as it will work on the LessTif
base. Motif being a commercial and relatively expensive is not
a consideration for "FreeBSD" at least in my view.
>
>I'd say things are coming right along.
I'm hoping to get together (in the electronic sense) with Terry
Lambert to have a look at this area and we will certainly look
at this option. Interested in helping out ??
>
>
>>With this tool the basics i.e make it easy
>>to install with simple easy to use
>>graphical user interfaces for everthying from
>>network setup to system configuration to
>>file management to program development to ...,
>>are easy and simple to develop.
>
>The install is already easy - or at least as easy as the NT and
>OS/2 installations I've been through.
That could well be. I have not yet installed the 2.0.5 CD
that came the other day. What you say could certainly not be
said of the 2.0.0 release.
> There are already other X-Windows
>applications to do as you suggest. Though the ones I can think of off the top
>of my head are commercial, I'd be amazed if there weren't shareware ones out
>there somewhere...
The reason perhaps you cant think of them is that they are scarce!
How many Windows apps builders can you think of immediately ?
VB, MSC, BC++ and the first of the complete object orientated
paradigm generation and the best of all: Borlands Delphi
>
>>Once this happens the "hords" will take it form there
>>as they have with MS Windows and develop/port
>>all sorts of proggies to make life easier.
>
>Don't bet on it. Afterall, OS/2 has many of the same kinds of developement
>tools and it's still floundering (though it's catching up a little).
Did you know at last count that there are 10 million OS/2 users. Yes
thats correct. Most of them are in the commercial sector
so we dont hear the hype in the more academic world but
OS/2 has a very solid and fanatical user base. Dont be
surprised if OS/2 becomes a major player over the the next
few years. Did you know that OS/2 is being ported to
other workstation platforms ??
> As much
>as I hate to say it, what actually sells and operating system these days is
>hype.
Yes I agree with you here, Look at the advance orders
for Windows 95. Why would anybody in their right mind
order an operating system months even years ahead
of its first release? answer: hype!!
> OS/2 Warp managed to catch up by quite a bit, simply by including the
>Internet BonusPak. Do you think that "You on-ramp to the information
>superhighway" and "Enhances You Exisiting DOS and Windows(TM)" on the side of
>the box did nothing for sales? If FreeBSD had the resources to do the kind of
>advertising they have, I bet that FreeBSD would be much more popular.
Again I think we will have to disagree.
> As I
>recall, advertising - well, sort of - is what Jordan Hubbard was actually
>hired by Walnut Creek to do. His official description was more PR than
>advertising, but since we're not trying to sell FreeBSD, one is close enough
>to the other :)
Linux was never advertised and look at its poularity.
In Europe its user base is 10x that of FreeBSD.
>
>>Contrary to both opinions I dont think
>>FreeBSD needs to be bleeding edge to survive
>>in fact I think it would be its death nell
>>if all this "new technology" is introduced
>>without removing the archaic academic UNIX
>>philosophy "if it ain't hard to use it ain't
>>UNIX" which still pervades the UNIX mindset
>>of both academic and commercial thinking.
>
>UNIX is not any harder to use than DOS.
Whoa there, surely you jest! I wont go into a
diatribe here. Just compare setting up two simple
applications (forgetting all the nasty kernel configuration)
compare setting up Eudora Mail on Windows with /etc/sendmail.cf
on UNIX!!!! and then compare setting up a dot matix
printer in Windows versus printcap etc on UNIX: Nuff said.
> People talk about having to reconfig
>the kernel, and edit some files in /etc, but look at all of the time and
>tweaking it takes in DOS just to get some device drivers going,
I have never had a problem with this but I have
had plenty of problems setting up FreeBSD and I work
inside the kernel of OSF/1 and ULTRIX everyday!!
> let alone to
>get the thing on the network.
Windsock was trivial, perhaps a few minutes. /etc/hosts
/etc/hosts.conf, bind, NIS, SLIP, PPP, routing, device
slattach, etc etc .... There really is no comparison
> If you don't network it, there's that much less
>configuration. It all depends on what you want to do with it. FreeBSD is
>making it easier all of the time.
Yes I agree it is getting easier.
> Just don't expect them to sacrifice UNIX
>compatibility for "ease of use" (ls will always be ls, etc.) - it would defeat
>the purpose.
Who said anything about compromising compatibility. I said "add" functionality.
As for compatibility this is a joke in the UNIX world and always has been
POSIX or no POSIX.
As for "ls" well here is perfect example: if we had a good file manager
for X then "ls" would be available for your use if you wanted but
bascially obsolete for everyday use. Yes I do have xfm but we miss the point:
what should be done is a good toolset to develop xfm quickly and
efficiently via object based GUI builders. Lets say
I want to change to look of the filemanager window
in xfm without changing the functionality:
I have get in the code and hack several
thousand lines of code combined with an intricate
knowledge of X intrinsics. If it was developed with a
good object based GUI builder I wouold start that up
and "drag n drop" a few components, point the
event handlers at the backend functionality
and recompile and exit.
Which is exactly what I am saying:
If FreeBSD is to put effort into anything over the next few years
then a object based GUI builder app should be high on the list
of priorities.
Have a look at Borlands Delphi to see how a GUIs should be
built. With C++ and perhaps LessTif or the like there is
no technical bar to something similar for UNIX/X. I know
that SUN and perhaps SGI are already working on something
similar based on Tcl/Tk if rumour is correct.
Just as an interesting aside did you know
that the US goverment has accepted NT as an Open
System. If you dont get the significance of this
then it effectively allows NT to replace any
UNIX operating system in the Goverment services.
Two large military organisations (I'm not sure
I can tell you who so they will remain nameless)
have already announced they will swap from UNIX
to NT. You have got to ask yourself why ?
The answer was spelt out in one bid response:
NT is easy to use, maintain and configure
UNIX is not. The savings in system maintainence
and staff training as well as the plethora of
cheap effective applications were the
deciding factors.
This may be real flame bait so please please
please dont reply as this a a really really
really subjective opinion but here goes:
Unless the UNIX community gets together
and provides the common toolsets to develop
fast cheap GUI applications including
system admin and configuration and
mulitmedia in an object based paradigm
then I predict that within 10 years
UNIX will be relagated to
academic circles with NT and OS/2 being
the predominat OS for both Goverment and
commercial systems.
Jon
Ken Nakata
>No, there have always been those who port each new version of a software
>to multiple systems. The fun thing about microkernels is that this
>becomes no longer necessary.
Why and how is it so with microkernel and it is not with other OS's
such as NetBSD?
Parhaps you don't know this; With NetBSD, we already have very
portable environment across many platforms. If I can compile one
program on i386 port, I'll be able to just re-compile the source on
Mac68k port and use it in most cases. Amiga, Atari, Mac68k and Sun3
ports can even share the same binary executables (No, I don't hate
FreeBSD or anything. It's just that I'm a NetBSD user, rather happy
one).
Why is it a microkernel thing? Please explain.
>The cut in development time will eventually justify the lessened
>performance in the same way that C replaced assembly
I don't see the cut *intrinsic* to the microkernel architecture,
"intrinsic" meaning the cut can only be achieved by the architecture.
It can be achieved by other means. BTW, I haven't object to the
lesser performance at all. Like you say, someday that'll be justfied.
>That's a management problem. The fact is, one version of a piece of
>software is less time consuming to maintain than twelve. For many
>corporations today, it simply is not an option to pay extra for the
>really topnotch programmers because they need extra people to do ports.
>If you aren't porting significantly, then you can shell out for better
>programmers in few numbers.
>How do you insure excellent programmers? If they suck, fire them. Or
>better yet, do a good job checking references.
You totally missed the point. He stated that *with microkernel
architecture* you have fewer excellent programmers instead of many
mediocre programmers. Probably his point was instead that
microkernelized OS can be maintained by fewer programmers than
conventional monolithic OS. But it has nothing to do with
programmers' quality and I don't believe it is true, either.
If you don't bother to read posts carefully, why do you bother to
respond?
Michael Dillon
Jon Jenkins <jenk...@ozy.dec.com> wrote:
>Linux was never advertised and look at its poularity.
>In Europe its user base is 10x that of FreeBSD.
Wait a minute. Linux is advertised in Europe as it is advertised
elsewhere. I believe the first book published about Linux was in Germany.
It received a lot of positive magazine coverage in Europe.
Back when comp.os.linux was the only Linux newsgroup, there was an
extended flamefest regarding the meaning of FREE software and the GNU
licence. It dragged on and on as people posted misinformed flames and
others corrected them but the thing that got drilled into everybody's
head was that anyone was FREE to sell Linux and make money off of it.
Not long after that, Linux products started popping up all over ranging
from a guy who would charge you so much to coppy floppies to CD-ROM's to
companies like the ACC book http://www.acc-corp.com who also sell FreeBSD.
Now that Linux has a monthly glossy magazine (with more color pages every
issue) and has booths at all the major trade shows, there is certainly a
LOT of advertising going one.
There's no reason why FreeBSD couldn't do the same. In particular, if
someone were to publish a FreeBSD magazine, the popularity of the system
would grow faster than it already is. And make no mistake, FreeBSD's
popularity is growing. A lot of us who use Linux are evaluating FreeBSD
or have plans to do so. Many people use BOTH systems depending on the job
they need done. Sometimes Linux is better, sometimes FreeBSD is.
FreeBSD is better at NFS.
FreeBSD has faster networking code.
FreeBSD can be used as a WAN router using Enhanced Technologies 56K and T1
sync cards (email den...@et.htp.com)
I believe FreeBSD has NIS and shadow passwords and quotas which are still
awkward patches for Linux.
There is no doubt in my mind that FreeBSD is a success and will continue
to be so. There is no doubt in my mind that the existence of TWO free
UNIX workalikes helps both of them. It legitimizes the whole idea of a
freely available O/S.
This thread started out with GUI as the topic. A lot of people believe
that FreeBSD has a GUI because it has X. This is not true. The term "GUI"
no longer refers to what X does. The term has changed its meaning to
include the typical things that people do with a GUI, the typical
programs they run, the typical ease (or expected ease) of getting things
done. The MacOS is the epitome of a GUI. FreeBSD is nowhere near this.
However, there is no reason why FreeBSD could not become something much
closer to the epitome of a GUI. Caldera (http://www.caldera.com) has the
right idea in building a network desktop based on a UNIX system under the
hood. They happened to choose Linux. In the past NeXT chose Mach as their
UNIX-like underpinning. Work with OS/2 for a while and you'll see that PM
and SOM are layered on top of a multitasking O/S that is powerful in its
own right.
What I'd like to see is a componentware approach to the GUI that builds
upon UNIX's strengths as a "toolbox" O/S with lots of filters and tools
that can be glued together in a myriad of ways the designer never thought
of. I don't believe that anybody has done this well, especially not
Microsoft with their OLE concept, but then I believe it's because few
people outside the UNIX world really understand the simplicity and power
of filters and pipes and scripts. I remember when Windows 3.0 started to
gain market acceptance and people talked about how you could buy a word
processor from one company and a spell checker from another and they
would all work together simply and easily. Instead we have bloated
do-everything applications that take 50 megs of hard drive to install,
are awkward to use, to learn, they crash too often, the design by
committee is inconsistent, the error messages are confusing or stupid....
Can't we do better?
>Windsock was trivial, perhaps a few minutes. /etc/hosts
>/etc/hosts.conf, bind, NIS, SLIP, PPP, routing, device
>slattach, etc etc .... There really is no comparison
I've just been evaluating Winsock's and I must say I've been through hell
trying to get them configured and working properly. This includes
commercial products like PC/TCP and PC/NFS
>efficiently via object based GUI builders. Lets say
>I want to change to look of the filemanager window
>in xfm without changing the functionality:
>I have get in the code and hack several
>thousand lines of code combined with an intricate
>knowledge of X intrinsics. If it was developed with a
>good object based GUI builder I wouold start that up
>and "drag n drop" a few components, point the
>event handlers at the backend functionality
>and recompile and exit.
No recompile. Just like using ResEdit on a Mac, you should be able to
change some stuff and it's done. The sophisticated end user should be
able to do it even if they don't know how to program or understand a
compiler error.
>built. With C++ and perhaps LessTif or the like there is
>no technical bar to something similar for UNIX/X. I know
>that SUN and perhaps SGI are already working on something
>similar based on Tcl/Tk if rumour is correct.
They are working on making TCL/Tk the GUI/scripting system by some small
redesign for portability and by releasing ports for UNIX, MacOS and
Windows. The TCL/Tk source code will be freely available, but their GUI
builder will be a commercial product. It's a start. A componentware
system needs a scripting language, but it is much more than just a GUI
with a scripting language. Check out comp.lang.tcl for more details or else
http://www.sunlabs.com:80/research/tcl/ will take you to dozens of WWW pages
telling you everything you want to know about TCL and Tk
Michael Dillon
Michael Hoess <hoe...@track.informatik.uni-stuttgart.de> wrote:
>>Perhaps it is time to start integrating
>>tools like TCL/Tk and expect and PERL into the system in the same way
>>that X and USENET and vi have been added.
>And on the other side I think such stone-age tools like vi should be kicked out
>(since they make people who worked with comforable DOS-Editors run away) and
>replace them with other editors like JOE.
Doesn't that one use Wordstar like commands? I love vi ever since 1987
when I started using it instead of ed but I have to say I agree with this
comment. The standard CUA style interface with a dash of MacOS thrown in
is far easier for novices to learn. Is it all that hard to clone the DOS
EDIT command's interface? Of course, nobody bothers because we already
have our favourite editors...
Jon Jenkins
mic...@okjunc.junction.net (Michael Dillon) wrote:
>In article <3us0rg$7...@nntpd.lkg.dec.com>,
>Jon Jenkins <jenk...@ozy.dec.com> wrote:
>
>>Linux was never advertised and look at its poularity.
>>In Europe its user base is 10x that of FreeBSD.
>
>Wait a minute. Linux is advertised in Europe as it is advertised
>elsewhere. I believe the first book published about Linux was in Germany.
>It received a lot of positive magazine coverage in Europe.
Sorry I was talking about when Linux first started. I can still
remember downloading the different bits from all over the place.
You are of course correct now that Linux has such a large
base it is advertised quite heavily.
..snip
>
>There's no reason why FreeBSD couldn't do the same. In particular, if
>someone were to publish a FreeBSD magazine, the popularity of the system
>would grow faster than it already is. And make no mistake, FreeBSD's
>popularity is growing. A lot of us who use Linux are evaluating FreeBSD
>or have plans to do so. Many people use BOTH systems depending on the job
>they need done. Sometimes Linux is better, sometimes FreeBSD is.
I suppose it really depends on where FreeBSD community wants
to head. If it is technical excellence rather than ease
of use then real time, multiprocessor extensions, efficient fs etc
are probably the way to go.
If however the aim is to make FreeBSD as attractive
as possible to potential users without compromising it's
compatibility with the historical UNIX base I suggest
the best way to do this is to concentrate efforts on
ease of use factors and a comprehensive GUI app builder
closely followed by apps to do all the nasty stuff would
be paramount.
My personal preference would be ease of use but others
may and will differ.
NT is a direct competitor for UNIX and you have got to
ask why use UNIX instead of NT? My only rational reason
is cost i.e. it (FreeBSD) and most of the tools are free!!
A less rational reason is my enjoyment in being able to
"see under the hood" and being able to customise my
environment i.e. shells, window managers source for the
apps etc. In my experinece organisations started
using UNIX because ther was no alternative. No other
OS provided the extensive range of tools or the
OS support for the types of applications that they
wanted to run. That is no longer the case both
OS/2 and NT provide most if not all the functionality
of UNIX and in many areas superior OS strategies
and the "power" apps that were once the domain of the
RISC workstations are now available on these OSs.
The next few years will be very interesting indeed!!!
..snip
>
>There is no doubt in my mind that FreeBSD is a success and will continue
>to be so. There is no doubt in my mind that the existence of TWO free
>UNIX workalikes helps both of them. It legitimizes the whole idea of a
>freely available O/S.
I agree. I would however like to see it's popularity spread
into the non academic and non "hackers" realm. I believe
the single best way to do this is to have a nice slick
GUI for everything.
>
>This thread started out with GUI as the topic. A lot of people believe
>that FreeBSD has a GUI because it has X. This is not true. The term "GUI"
>no longer refers to what X does. The term has changed its meaning to
>include the typical things that people do with a GUI, the typical
>programs they run, the typical ease (or expected ease) of getting things
>done. The MacOS is the epitome of a GUI. FreeBSD is nowhere near this.
but it could be!!
>
>However, there is no reason why FreeBSD could not become something much
>closer to the epitome of a GUI. Caldera (http://www.caldera.com) has the
>right idea in building a network desktop based on a UNIX system under the
>hood. They happened to choose Linux. In the past NeXT chose Mach as their
>UNIX-like underpinning. Work with OS/2 for a while and you'll see that PM
>and SOM are layered on top of a multitasking O/S that is powerful in its
>own right.
As for Mach so did NT and OSF/1 !! As for Next its a shame they
chose the 68k base as its death was also Next's death. i really
liked Objective C it is so much cleaner than C++.
>
>What I'd like to see is a componentware approach to the GUI that builds
>upon UNIX's strengths as a "toolbox" O/S with lots of filters and tools
>that can be glued together in a myriad of ways the designer never thought
>of. I don't believe that anybody has done this well, especially not
>Microsoft with their OLE concept, but then I believe it's because few
>people outside the UNIX world really understand the simplicity and power
>of filters and pipes and scripts. I remember when Windows 3.0 started to
>gain market acceptance and people talked about how you could buy a word
>processor from one company and a spell checker from another and they
>would all work together simply and easily. Instead we have bloated
>do-everything applications that take 50 megs of hard drive to install,
>are awkward to use, to learn, they crash too often, the design by
>committee is inconsistent, the error messages are confusing or stupid....
The OO concept has some advantages after all!!
>
>Can't we do better?
>
>>Windsock was trivial, perhaps a few minutes. /etc/hosts
>>/etc/hosts.conf, bind, NIS, SLIP, PPP, routing, device
>>slattach, etc etc .... There really is no comparison
>
>I've just been evaluating Winsock's and I must say I've been through hell
>trying to get them configured and working properly. This includes
>commercial products like PC/TCP and PC/NFS
I only speak for myself having set up Trumpet Windosock once each on
ether, SLIP and PPP. I had all three systems running under a few minutes.
Netscape, Eudora and Ewan followed a few minutes later. It may
well be that as a general rule it is much more difficult.
>
>>efficiently via object based GUI builders. Lets say
>>I want to change to look of the filemanager window
>>in xfm without changing the functionality:
>>I have get in the code and hack several
>>thousand lines of code combined with an intricate
>>knowledge of X intrinsics. If it was developed with a
>>good object based GUI builder I wouold start that up
>>and "drag n drop" a few components, point the
>>event handlers at the backend functionality
>>and recompile and exit.
>
>No recompile. Just like using ResEdit on a Mac, you should be able to
>change some stuff and it's done. The sophisticated end user should be
>able to do it even if they don't know how to program or understand a
>compiler error.
I agree.
>
>>built. With C++ and perhaps LessTif or the like there is
>>no technical bar to something similar for UNIX/X. I know
>>that SUN and perhaps SGI are already working on something
>>similar based on Tcl/Tk if rumour is correct.
>
>They are working on making TCL/Tk the GUI/scripting system by some small
>redesign for portability and by releasing ports for UNIX, MacOS and
>Windows. The TCL/Tk source code will be freely available, but their GUI
>builder will be a commercial product. It's a start. A componentware
>system needs a scripting language, but it is much more than just a GUI
>with a scripting language. Check out comp.lang.tcl for more details or else
>http://www.sunlabs.com:80/research/tcl/ will take you to dozens of WWW pages
>telling you everything you want to know about TCL and Tk
Why do we need a scripting lanquage at all? If you haven't yet
seen Borlands Delphi take a look. There really is nothing
that even compares either in the MS Windows
or the UNIX/X world. As for ease of use and
user friendliness (is there such a term?) Tcl/Tk is still way
to far off the mark. Both the base AND the App builder need
to be OO based otherwise you lose half the benefit of the
extensibility, replacability and inheritance of
components otherwise we end up in the same "deadly embrace"
of reinventing the wheel i.e thousands of lines of code
(be it Tcl or C++ or whatever) for every app.
Thanks for your reply,
Charles Buckley
>In article <3up590$n...@rover.village.org>, Warner Losh <i...@village.org> wrote:
>>Hmmm, I guess I should have tried harder to get the FreeBSD release of
>>OI and ObjectBuilder out the door :-(. Its been doing that for
>>years...
>
>Yeah, you sure should have! :-)
>
>sent me sitting on the floor behind me. Totally useless since any
>app I develop with it can't even be run by anyone else save a few
>Linux users who are still using an outdated and somewhat buggy version.
As do I, on a top shelf. I remember that the executables I did cobble up
were of the mambo-variety, although this dated from the pre-shared-libs
era. I tried hard but couldn't generate any interest in deploying this
in a corporate/corporate-client arena.
It seems that window-based apps are to have a Windows-oid flavour for a
number of years to come. Somehow this bothers me.
tedm%...@agora.rdrop.com
| Hi Marcus,
|
|
[discussion deleted]
| This may be real flame bait so please please
| please dont reply as this a a really really
| really subjective opinion but here goes:
|
| Unless the UNIX community gets together
| and provides the common toolsets to develop
| fast cheap GUI applications including
| system admin and configuration and
| mulitmedia in an object based paradigm
| then I predict that within 10 years
| UNIX will be relagated to
| academic circles with NT and OS/2 being
| the predominat OS for both Goverment and
| commercial systems.
|
| Jon
If this happens I couldn't be more pleased. Looking back on the history of
Unix I can only point to a few good things that ever came out of commercial
vendors dicking around with it. The vast majority of good things in Unix
today came out of universitys, mainly grad students, not to mention the
enjoyable names as well. Can you imagine a commercial vendor naming a
program "lint" for example?
In contrast, I can think of much screwed up crap that comes from the
commercial businesses. Like, SCO's hate affair with the SYSVR4 kernel,
for example. Or, even better, what about NIS from Sun?
If you look at all of the good things that are in NT and OS/2 they all
originated with work done on the Unix operating system. Well, with OS/2
some came also from IBM's work on SYS/36 but the point is there.
Commercial vendors simply don't have the ability to allow the wide lattitude
for truely revolutionary ideas to be brought to fufillment. All
commercial businesses that are really successful in the computer business
have strong ties to academic institutions, either official ties or
unofficial. Businesses are really great at taking a good idea that isin't
really fleshed out and refining the heck out of it to make it palatable to the
consumer. But, they stink at coming up with truely original ideas.
The next great advances in operating systems will originate in the academic
community, and be refined by commercial entities. That is how it always
has been and how it always will be. So what if these ideas are brought
from Unix into a commercial OS?
As long as there are geniuses in the academic community who hack out their
ideas in Unix and there are intelligent people in the business comjmunity
smart enought to apply these ideas to commercial products there will be a
home for everyone, believe me.
Marcus I. Ryan
>From: Jon Jenkins <jenk...@ozy.dec.com>
>Subject: Re: The Future of FreeBSD...
>Hi Marcus,
>thanks for replying to my post.
You're welcome :)
>mar...@ccelab.iastate.edu (Marcus I. Ryan) wrote:
>>In article <3umkok$d...@nntpd.lkg.dec.com> Jon Jenkins <jenk...@ozy.dec.com>
>wri
>tes:
>Actually Windows/386 was the first and the compatilbility problems
>killed the other efforts. I'm sure that this compatibilty problem
>was not all by "accident".
I tried Windows/386 and Windows/286 before windows v3.0 - it was horrendous.
3.0 was a dramatic improvement - so much so I tend not to acknowledge the
earlier versions ;)
[stuff about VXP -- Visual X windows Programming Interface and LessTif]
>Well this would be a good start as long as it will work on the LessTif
>base. Motif being a commercial and relatively expensive is not
>a consideration for "FreeBSD" at least in my view.
Well, that's LessTif's intent - 100% compatibility with Motif...
>I'm hoping to get together (in the electronic sense) with Terry
>Lambert to have a look at this area and we will certainly look
>at this option. Interested in helping out ??
I'd love to, but unfortunately I've already promised some of my time to the
documentation project and with my schedule that's already more than I can
handle :) (don't let the .edu fool you, I work for a living too :)
>> There are already other X-Windows
>>applications to do as you suggest. Though the ones I can think of off the top
>>of my head are commercial, I'd be amazed if there weren't shareware ones out
>>there somewhere...
>The reason perhaps you cant think of them is that they are scarce!
>How many Windows apps builders can you think of immediately ?
>VB, MSC, BC++ and the first of the complete object orientated
>paradigm generation and the best of all: Borlands Delphi
Well, that and I've not looked - I was raised in the command-line world, so I
run after my text tools first. :)
>Did you know at last count that there are 10 million OS/2 users. Yes
>thats correct. Most of them are in the commercial sector
>so we dont hear the hype in the more academic world but
>OS/2 has a very solid and fanatical user base. Dont be
Don't forget Government - there are probably about as many government agencies
running OS/2 as commercial companies (though that's just my overall impression
- not based on any facts or figures).
>surprised if OS/2 becomes a major player over the the next
>few years. Did you know that OS/2 is being ported to
>other workstation platforms ??
I know it's being ported to the PowerPC :) Other than that I was not aware.
However, I don't think that will have much of an affect. What makes an
operating system popular is who developes what apps for it, or at least what
will run on it. I'll be interested in seeing what happens with FreeBSD and
its kin when the WINE project fully implements windows in X. I may be
completely nuts, but I seem to recall reading the newsgroup a while ago where
people were already running MicroSoft Word under X.
>> OS/2 Warp managed to catch up by quite a bit, simply by including the
>>Internet BonusPak. Do you think that "You on-ramp to the information
>>superhighway" and "Enhances You Exisiting DOS and Windows(TM)" on the side of
>>the box did nothing for sales? If FreeBSD had the resources to do the kind of
>>advertising they have, I bet that FreeBSD would be much more popular.
>Again I think we will have to disagree.
I don't think we have to disagree completely. I use OS/2 and like it, but can
you honestly and with complete confidence say that despite the fact that they
based entire commercials around that bonus pack it had no significant impact
on sales?
>Linux was never advertised and look at its poularity.
>In Europe its user base is 10x that of FreeBSD.
Advertising is not necessarily commercials. Advertising is also done by word
of mouth, getting magazines to review the products, having booths at shows,
etc. FreeBSD is capable of competing with Linux and its level of advertising
to some degree (6 or so distributions of linux being sold by commercial
vendors, vs. 1 distribution of FreeBSD being sold by Walnut Creek). I don't
think either will have advertisements on TV like IBM, MicroSoft, etc., anytime
soon which is more of what I was referring to.
>>UNIX is not any harder to use than DOS.
>Whoa there, surely you jest! I wont go into a
>diatribe here. Just compare setting up two simple
>applications (forgetting all the nasty kernel configuration)
>compare setting up Eudora Mail on Windows with /etc/sendmail.cf
>on UNIX!!!! and then compare setting up a dot matix
>printer in Windows versus printcap etc on UNIX: Nuff said.
Windows != DOS! Don't make this mistake. I was not comparing X with Windows,
I was comparing command-line, text-based UNIX with command-line, text-based
DOS. On top of that, sendmail.cf is something I've never needed to play with.
It's default settings work well for my system. If you want to compare
readers/viewers, comapre Pegasus Mail for DOS, and mh (because it's what I've
set up).
1) FTP them to your local machine.
2) Extract the archives (PKZip and pkg_add)
3) run PConfig for PMail, run mh-install for MH.
4) If a different editor for PMAIL is prefered, you're SOL. If a different
editor for MH is prefered, edit .mh_profile and add EDITOR: uemacs :)
5) Use them.
mh takes the same number of steps to install, unless you want to use something
other than the systems default editor, an option not available in any DOS mail
programs I know of.
Remember, lets compare apples with apples.
>> People talk about having to reconfig
>>the kernel, and edit some files in /etc, but look at all of the time and
>>tweaking it takes in DOS just to get some device drivers going,
>I have never had a problem with this but I have
>had plenty of problems setting up FreeBSD and I work
>inside the kernel of OSF/1 and ULTRIX everyday!!
2.0.5 is a little easier when it comes to PS/2 mice, but other than that, at
most I've had to open up LINT and GENERIC together and get the proper line
from LINT. If I REALLY want to get fancy (which I usually do for speed's
sake), I read through and figure out which devices I don't need, and then
remove them (though I must admit it annoys me to get compile errors if I
remove the PCI line even on a non-PCI machine *Shrug*). In MicroEmacs, it's a
matter of a few ^K (cut) and ^Y (paste) commands here and there, then
config GENERIC && cd ../../compile/GENERIC && make depend && make && install\
&& reboot
and I'm done.
Comparing setups for my machine at home:
486DX/2 66MHz Intel, EISA
ATI Mach32 Graphics Ultra Pro 2MB
PC Logic Modem on Com3 IRQ 5
SMC Elite16
Soundblaster Pro
Adaptec 1740
Quantum 1G hard drive
Mitsumi CD-ROM
Colorado Jumbo 250
UNIX/X (1 CD, or FTP connection):
Run the standard FreeBSD install program and check the various options.
Installing X, I have to answer a few questions that I pull straight out of my
manuals about my monitor and video card, but for the most part it's just
checking boxes and answering yes/no questions.
Add a few packages with the pkg_manage, do a quick kernel reconfig (for a
faster bootup, and to add the sb device, copied over from LINT). Type in the
command above, and in a little bit (20-30 minutes, unfortunately), I have a
freshly optimized system. I admit that the time needed for the reconfig is
irritating, but as a trade-off for the advantages, it's acceptable.
DOS: (17 floppies for DOS, Windows, and drivers, no apps)
Install DOS. (3 disks)
Install Mitsumi CD-ROM driver (1)
Install Windows (7)
Install ATI Mach32 driver (2)
Install SMC Ethernet drivers (1)
Install Soundblaster drivers (2)
Install Colorado Tape software (1)
tweak memory, clean up autoexec.bat and config.sys so everything is readable,
(so I don't have 3 PATH=%PATH%;... statements, and to add a
SHELL=C:\DOS\COMMAND.COM /E:1024 /P so that all of the new environment
variables won't run me out of environment space). To get enough memory to run
my applications, I have to run PCTools Ramboost, undo some of its changes, and
then run MemMaker. Several applications still won't run, so I'll probably
have to get Multimedia Cloaking utilities, or set up multiple boot
configurations for my various games and large DOS programs. That says nothing
of the addtional setups I'll have to do to actually efficiently run on my
NetWare network (editing net.cfg so that lsl and vlms don't take up most of my
conventional memory remaining).
Of course, all of that assumes that those installs do both DOS and Windows at
the same time. Otherwise, I have to do even more installs and configs to get
the things to work in Windows. None of the installs look or operate the same.
>> let alone to
>>get the thing on the network.
>Windsock was trivial, perhaps a few minutes. /etc/hosts
>/etc/hosts.conf, bind, NIS, SLIP, PPP, routing, device
>slattach, etc etc .... There really is no comparison
Again, Winsock is Windows, but I'll acccept it.
Winsock: Install, add Trumpet's directory to path, odipkt and winpkt commands
to startnet.bat, and reboot. Run windows, and then trumpets setup. Add your
IP#, domain name, netmask, default gateway, name server, Packet Vector, and if
you want, play with a few other settings, though their not necessary. Exit
and restart for changes to take effect.
FreeBSD: During install tell it IP#, domain name, hostname, netmask, default
gateway, and name server. When you reboot to load the system the first time,
it's there and ready.
You keep comparing by saying everything you can tweak about UNIX. Just
because it's there doesn't mean you have to mess with it. Look at all of the
settings you can add to WIN.INI and SYSTEM.INI. They'll make it run faster,
but you don't have to touch them in most cases. The same is true with
Autoexec.bat and config.sys, but those you likely will need to play with. The
main problem is that no devices come pre-installed with DOS, and Windows at
minimum requires you to go in after it's done (with the exception of printers
that they already have drivers for) and feed it a few disks.
On top of that, you don't have the problem of keeping track of all of your
driver disks, keeping each up-to-date seperately, etc. It all comes on one
CD, and when one thing is updated, they're all updated.
Everything that runs under a standard UNIX command prompt should run under an
xterm in X, but not one of my favorite games (Doom, X-wing, Wing
Commander 3, etc.) will run under a dos shell in any of OS/2, NT, or Windows
3.11. OS/2 does offer the best chance though with all of the settings you can
change.
[snip]
>As for "ls" well here is perfect example: if we had a good file manager
>for X then "ls" would be available for your use if you wanted but
>bascially obsolete for everyday use. Yes I do have xfm but we miss the point:
X is not officially part of FreeBSD, so why is it on FreeBSD's shoulders to
develop it? On top of that, any X-windows program should compile on any UNIX
if programmed correctly, which means if the linux camp developes one, as long
as the source code is available, FreeBSD can use it to. That's the beauty of
UNIX, free software, and an OS that comes with compilers built-in :)
[snip - GUI builder app stuff]
>Which is exactly what I am saying:
>If FreeBSD is to put effort into anything over the next few years
>then a object based GUI builder app should be high on the list
>of priorities.
I agree with the need for such a thing, but I disagree that the FreeBSD core
team should be the ones to do this. Say things were a little different in the
DOS world. MicroSoft decides to sell DOS to Netware, so that DOS and Windows
are no longer owned by one company. What you are are saying is that Novell
(owners of DOS) should develop a nice GUI builder app. for Windows.
[snip]
>Just as an interesting aside did you know
>that the US goverment has accepted NT as an Open
>System. If you dont get the significance of this
>then it effectively allows NT to replace any
>UNIX operating system in the Goverment services.
>Two large military organisations (I'm not sure
>I can tell you who so they will remain nameless)
>have already announced they will swap from UNIX
>to NT. You have got to ask yourself why ?
Okay, why? Especially when Novell's UnixWare is available, and completely
manageable using the Motif-based manager tools. It's still UNIX, but is as
easily configured as NT. That's a different conversation though. I also use
NT and love it. The only reason I keep DOS around is because NT won't run my
games, and because Reachout and my scanned don't have NT version yet (they
still rely on DOS device drivers)
[snip]
>Unless the UNIX community gets together
>and provides the common toolsets to develop
>fast cheap GUI applications including
>system admin and configuration and
>mulitmedia in an object based paradigm
>then I predict that within 10 years
>UNIX will be relagated to
>academic circles with NT and OS/2 being
>the predominat OS for both Goverment and
>commercial systems.
I disagree, but I won't argue the point, as it has been argued repeatedly. I
do agree that FreeBSD, and UNIX in general will not replace NT, OS/2, etc.,
for quite some time to come without a lot more applications, just like OS/2
won't outdo windows until there are a lot more native OS/2 applications
(although OS/2 will run Windows apps, you have to buy a copy of windows to do
this meaning that for each person running a windows app under OS/2, one
version of each was sold. OS/2 may make again against it's previous sales,
but it doesn't close the gap any faster).
Regardless, you state directly that this is not a problem of just FreeBSD, but
of UNIX as a whole. Rather than saying FreeBSD will die if this doesn't
happen, and pinning all the responsibility on the team, and freebsd users, pin
it on EVERYONE. Get the Linux, NetBSD, Mach, and 386BSD, and WINE project
programmers involved too. Personally I think all of the UNIX teams need to
work together to get people using UNIX, to develop the tools needed to make it
work, to get applications ported to UNIX, and to make people notice it in
general. Then we can fight and bicker about whose dad's can beat each other
up :)
Amancio Hasty, Jr.
>In article <3uktse$d...@hal.nt.tuwien.ac.at>,
>Martin Birgmeier <mar...@hal.nt.tuwien.ac.at> wrote:
>> that wheel is basically from the stone-age of OSs as well... I
>> understand that there is going a large amount of effort into making
>> FreeBSD an advanced Unix system (unified buffer cache comes to mind),
>> but basically it's still the same old story.
>
>FreeBSD *is* an advanced UNIX system.
>
>> merge with Lites as developed by Johannes Helander *as soon as
>> possible*
>
>with X in 16M. Going to Lites will probably double the kernel size and make
>a serious impact on memory requirements.
>--
I am not sure that Lites would buy us anything ... In fact initially it will
be like running 386bsd alpha which is not a very good prospect after taking
the 4.4 bsd upgrade path hit.
Oh, and I ran Lites/FreeBSD and managed to run doom under FreeBSD/Lites.
No X server though because at the time there was not X server readily
available for Lites and I didn't feel like compiling one for Lites and
the FreeBSD X server didn't run with Lites so it was back to 101 for X
servers. Yes, I heard that the Lites group had X running but my impression
was that it was not well supported and that they didn't use that much.
If anyone wants perl, tcl/tk, guile,etc.. they can compile it or add the
package
to their system is really not a big deal. Think of a package like an
option for your system. To add a package download it from the net or cd
to your FreeBSD cdrom distribution and type "pkg_add <whatever>".
Amancio
Matt Dillon
:Ken Nakata <ke...@er6.rutgers.edu> wrote:
:>Matthew Jason White <mwh...@CMU.EDU> writes:
:>>No, there have always been those who port each new version of a software
:>>to multiple systems. The fun thing about microkernels is that this
:>>becomes no longer necessary.
:>
:>Why and how is it so with microkernel and it is not with other OS's
:>such as NetBSD?
:>
:>Parhaps you don't know this; With NetBSD, we already have very
:>portable environment across many platforms. If I can compile one
:>program on i386 port, I'll be able to just re-compile the source on
From a theoretical perspective, nobody has really written a real
microkernel yet. So far, the microkernels (including Mach) appear to
be at least as complex as their monolithic brothers and require
about as much work to port across platforms. Just adding
a few more levels of subroutine call does not a microkernel make,
IMHO.
On the otherhand, I keep hearing people screaming about how inefficient
microkernels are. There is nothing in the inherent design that requires
a microkernel to be any less efficient then a monolithic design, it is
only the *current implementations* you see in the field which are
inefficient, which I attribute simply to bad design irregardless of
whether it is a microkernel or not.
I think the point is pretty much moot, myself. I see both monolithic
and microkernel designs heading for the same destination.
-Matt
Jon Jenkins
>In <3us0rg$7...@nntpd.lkg.dec.com> Jon Jenkins <jenk...@ozy.dec.com> writes:
>| Hi Marcus,
>|
>|
>
>[discussion deleted]
>
>| This may be real flame bait so please please
>| please dont reply as this a a really really
>| really subjective opinion but here goes:
>|
>| and provides the common toolsets to develop
>| fast cheap GUI applications including
>| system admin and configuration and
>| mulitmedia in an object based paradigm
>| then I predict that within 10 years
>| UNIX will be relagated to
>| academic circles with NT and OS/2 being
>| the predominat OS for both Goverment and
>| commercial systems.
>|
>
>If this happens I couldn't be more pleased. Looking back on the history of
>Unix I can only point to a few good things that ever came out of commercial
>vendors dicking around with it. The vast majority of good things in Unix
>today came out of universitys, mainly grad students, not to mention the
>enjoyable names as well. Can you imagine a commercial vendor naming a
>program "lint" for example?
Im sure Ken Thompson and the other UNIX designers at
AT&T Bell Labs (a very commercial organisation) would
have been very heartened to read your comments!! System V
(nee Novell nee ???) continues to be a fully
commercial product whereas the BSD variant is
not and we wont mention XENIX (mainly cause I dont
know anything about it :-).
But I bascially agree with you and the current
discussion was aimed at the non commercial sector.
>
>If you look at all of the good things that are in NT and OS/2 they all
>originated with work done on the Unix operating system. Well, with OS/2
>some came also from IBM's work on SYS/36 but the point is there.
This is patently untrue. NT is based on the mach kernel
which is a significant departure from the traditional
monolith kernel. The only other UNIXish group to do this
prior to OSF/1 was Next. Just beacuse the interface
is similar does not imply the guts are eg Win32s and NT.
OS/2 also started life as pre-NT when IBM and MS were a
little closer friends than now!!
The one area where there is much common ground is networking
but remember the IP paradigm was started in the late 60's
as a DARPA funded packet siwtching project
long before UNIX was conceived!
>
>Commercial vendors simply don't have the ability to allow the wide lattitude
>for truely revolutionary ideas to be brought to fufillment. All
>commercial businesses that are really successful in the computer business
>have strong ties to academic institutions, either official ties or
>unofficial. Businesses are really great at taking a good idea that isin't
>really fleshed out and refining the heck out of it to make it palatable to the
>consumer. But, they stink at coming up with truely original ideas.
Im sure the VMS people at DEC would also be heartened
to hear this comment. The most successful computer buisness
of them all: MS has no ties to any academic institution
apart from selling sw to students.
>
>The next great advances in operating systems will originate in the academic
>community, and be refined by commercial entities. That is how it always
>has been and how it always will be. So what if these ideas are brought
>from Unix into a commercial OS?
This may well be true but the reverse is also true. There
are a lot of awfully smart prople in the commecial
sector too and the larger companies like DEC, IBM,
HP, Fujitsu and the recently defunct Cray etc
spend a whole lot more money on research than
the universities get in grants. The increasing scale
and complexity of OS requires mucho dollars and will
probably also require a pre existing revolution
in hw concepts as well.
>
>As long as there are geniuses in the academic community who hack out their
>ideas in Unix and there are intelligent people in the business comjmunity
>smart enought to apply these ideas to commercial products there will be a
>home for everyone, believe me.
I agree wholeheartedly and also state that the reverse
applies: any good idea conceived in the commercial sector
will find its way into and be improved upon in the academic
community.
Anyway we are a little off topic here. This startred
as a discussion about the future of FreeBSD, perhaps
enough has been said.
Thanks for your comments
Peter da Silva
Matthew Jason White <mwh...@CMU.EDU> wrote:
> Excerpts from netnews.comp.unix.bsd.freebsd.misc: 21-Jul-95 Re: The
> Future of FreeBSD... by Ken Nak...@er6.rutgers.e
> > to microkernel architecture.
> No, there have always been those who port each new version of a software
> to multiple systems. The fun thing about microkernels is that this
> becomes no longer necessary.
Nonsense.
This is like the object oriented programming people claiming that with OO
languages you don't have to spend effort abstracting interfaces.
Interface abstraction can, but does not always, benefit from object oriented
languages.
Portability can, but does not always, benefit from microkernel design.
You can also get portability from a layered interface abstraction within
a single protection domain.
Like BSD uses.
--
Peter da Silva (NIC: PJD2) `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Har du kramat din varg idag?"
Peter da Silva
> They were experimenting, and one of the things they came up with
> was the idea of a microkernel.
They didn't "come up with" the idea. The microkernel has been widely used
in real time operating systems for many years. Most real-time people
consider that the Mach microkernel contains too many services to really
count as one.
Mach is more of a hybrid like RSX-11.
Yes, an abstract interface is useful. BSD has lots of them laid out already.
Peter da Silva
> killed the other efforts. I'm sure that this compatibilty problem
> was not all by "accident".
I *used* the first version of Windows, the one that "beat" the rest.
And I quit using it shortly thereafter. The rest were MUCH more compatible
with what counted... DOS...
> Whoa there, surely you jest! I wont go into a
> diatribe here. Just compare setting up two simple
> applications (forgetting all the nasty kernel configuration)
> compare setting up Eudora Mail on Windows with /etc/sendmail.cf
> on UNIX!!!!
Compare setting up Eudora Mail on windows with setting up "elm". Eudora
isn't a server.
(not to mention that sendmail is by an order of magnitude the worst case
you can come up with, and there are other servers available)
> and then compare setting up a dot matix
> printer in Windows versus printcap etc on UNIX: Nuff said.
Yeh. How *do* you set up a printer in Windows so it prints a banner page?
I'm still trying to figure this out. If I install the ".SEP" files they
provided the printer spits out an error message and dumps the job.
> Windsock was trivial, perhaps a few minutes.
Yeh, clients are inherently easier to configure.
I'm still working on getting network backup of my NT server up.
> /etc/hosts
> /etc/hosts.conf, bind, NIS, SLIP, PPP, routing, device
> slattach, etc etc .... There really is no comparison
Right. UNIX exposes the configuration details. Windows hides them, so if
you're doing anything but setting up a vanilla client you're scrod.
> Just as an interesting aside did you know
> that the US goverment has accepted NT as an Open
> System.
What this means is that the POSIX subsystem conforms to FIPS 151. This
doesn't mean it's an "open system" in any real sense. The POSIX subsystem is
deliberately crippled, so as to be no more than a checkbox on the purchase
requisition form.
> If you dont get the significance of this
> then it effectively allows NT to replace any
> UNIX operating system in the Goverment services.
So long as it can actually do the job.
> Two large military organisations (I'm not sure
> I can tell you who so they will remain nameless)
> have already announced they will swap from UNIX
> to NT. You have got to ask yourself why ?
Because they're followers?
Can you say $100 hammers?
> The answer was spelt out in one bid response:
> NT is easy to use, maintain and configure
> UNIX is not.
I'm supporting UNIX and NT here. NT is easy to set up in a vanilla
configuration. It is *impossible* to debug problems. You just have to
try things... I'm not talking about "I don't know how this works" I mean
"there is no indication what the problem is".
For example, I tried to access a Novell server. It gave me an error
that basically said "this subsystem is not initialized". OK, I'll go
set it up. Click, click, "this subsystem is not initialized". Um, why
not? Sorry, that option's ghosted because the subsystem isn't initialized
and when I try and initialize it what does it say? "Initialization failed".
Why? Doesn't say.
OK, go look in the event log. Surely it'll say something there. Nope. Lots
of print jobs, no errors. Nothing in the registry.
Rebooting "fixed" it, but there were *NO* diagnostics. Anywhere.
I don't care how good your GUI is, you need to log failures somewhere.
Meanwhile in FreeBSD 99.5% of the problems can be diagnosed by looking in
/var/log.
Yes, a better interface for the dumb stuff will help, but NT is no bed of
roses. Well, if you count the thorns...
Peter da Silva
Jon Jenkins <jenk...@ozy.dec.com> wrote:
> NT is a direct competitor for UNIX and you have got to
> ask why use UNIX instead of NT?
UNIX is far less likely to fuck up and leave you hanging without a clue
as to why it's broken. Being able to see under the hood isn't just a
matter of enjoyment, it's an essential part of system management.
J Wunsch
>>Perhaps it is time to start integrating
>>tools like TCL/Tk and expect and PERL into the system in the same way
>>that X and USENET and vi have been added.
Btw., Perl became part of the system several months ago. There's even
a growing amount of system commands using it (e.g. adduser, catman).
Many people consider Tcl a less thoroughful designed hack, however.
>And on the other side I think such stone-age tools like vi should be kicked out
>(since they make people who worked with comforable DOS-Editors run away) and
>replace them with other editors like JOE.
No. Even though i'm a vi-hater, there are far too many people who are
used to have it, and you cannot neglect that it is _the_ standard Unix
editor now (and has totally replaced ed in this field, even though
some SysV man pages for ed still claim:
ed(1) ed(1)
NAME
ed, red - text editor
SYNOPSIS
ed [-s] [-p string ] [-x] [-C] [file]
red [-s] [-p string ] [-x] [-C] [file]
DESCRIPTION
ed is the standard text editor. If the file argument is given, ed
...
I agree that there may be editors better suited for beginners, while
they cannot cope with the variety of things you can do with vi. Other
people (like me) are able to do all this (and way more) with Emacs,
but it's just the same: a powerful tool, but nothing for the first-
time or casual user, rather something as complex like an Integrated
Development Environment.
There must be (and there is) room for several such things, and it's
mostly a matter of personal taste which to use.
--
cheers, J"org private: joerg_...@uriah.heep.sax.de
http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)
Nate Williams
Jon Jenkins <jenk...@ozy.dec.com> wrote:
>>If you look at all of the good things that are in NT and OS/2 they all
>>originated with work done on the Unix operating system. Well, with OS/2
>>some came also from IBM's work on SYS/36 but the point is there.
>
>This is patently untrue. NT is based on the mach kernel
Just for clarification, NT is *NOT* based on the mach kernel, although a
few of the big Mach folks do work for M$, and probably have brought in
many of the features of Mach into NT.
AFAIK, NT is still a monolith kernel, although it has loadable drivers
which give it a 'micro-kernelish' flavor. But, Sun boxes have been
doing this for awhile and all of the free *nix clones also have this
ability as well.
>>Commercial vendors simply don't have the ability to allow the wide lattitude
>>for truely revolutionary ideas to be brought to fufillment. All
>>commercial businesses that are really successful in the computer business
>>have strong ties to academic institutions, either official ties or
>>unofficial. Businesses are really great at taking a good idea that isin't
>>really fleshed out and refining the heck out of it to make it palatable to the
>>consumer. But, they stink at coming up with truely original ideas.
>
>Im sure the VMS people at DEC would also be heartened
>to hear this comment.
Alot of really neat stuff was done in VMS, and a lot of credit must be
given to Apollo for DNS. But, I think that most *truly* new ideas have
come from educational institutions because they don't have anything to
lose if the project fails.
> The most successful computer buisness of them all: MS has no ties to
> any academic institution apart from selling sw to students.
And it has yet to provide anything revolutionary in terms of software.
Nate
--
na...@sneezy.sri.com | Research Engineer, SRI Intl. - Montana Operations
na...@trout.sri.MT.net | Loving life in God's country, the great state of
work #: (406) 449-7662 | Montana. Wanna go fishing? Send me email, and we'll
home #: (406) 443-7063 | setup something.
Henry Tieman
I just had to add my comments to this thread.
I think that the major difference between the MS operating systems
and FreeBSD is a design goal issue. Most UNIX systems are designed
from the start to be a server communicating with other servers.
When you put a MS operating system on a machine, it is a client
computer, depending on other hosts and servers. Since servers are
harder to configure it makes since that FreeBSD is harder to configure.
In article <3us0rg$7...@nntpd.lkg.dec.com> Jon Jenkins <jenk...@ozy.dec.com> writes:
...
> As much
>as I hate to say it, what actually sells and operating system these days is
>hype.
Yes I agree with you here, Look at the advance orders
for Windows 95. Why would anybody in their right mind
order an operating system months even years ahead
of its first release? answer: hype!!
Apparently non every one is falling for the hype. There was a box
associated with a story on MS-Windows 95, in PC-Week. It told of
a software developer who was desprate to get around the 640k problems
with DOS/MS-Windows. After using a beta of MS-Win 95, they are now
shipping their program with a copy LINUX. I think they should have
used FreeBSD, but I'm a little biased.
...
Whoa there, surely you jest! I wont go into a
diatribe here. Just compare setting up two simple
applications (forgetting all the nasty kernel configuration)
compare setting up Eudora Mail on Windows with /etc/sendmail.cf
on UNIX!!!! and then compare setting up a dot matix
printer in Windows versus printcap etc on UNIX: Nuff said.
This is the difference between configuring a server and configuring
a client. I'm not familure with Eudora, but most other MS style
mail programs use POP to get their mail from a server, they are
incapable of acting as a server. On FreeBSD mail is a full SMTP
implementation, which requires major effort to setup.
> People talk about having to reconfig
>the kernel, and edit some files in /etc, but look at all of the time and
>tweaking it takes in DOS just to get some device drivers going,
I have never had a problem with this but I have
had plenty of problems setting up FreeBSD and I work
inside the kernel of OSF/1 and ULTRIX everyday!!
You obviously have not setup a PC with:
net card
2 hard drives
sound blaster
accelerated video
to run multipul apps from microsloth, under MS-Windows. This
usually takes about a full day, although there have been cases
where it's taken most of a week.
> let alone to
>get the thing on the network.
Windsock was trivial, perhaps a few minutes. /etc/hosts
/etc/hosts.conf, bind, NIS, SLIP, PPP, routing, device
slattach, etc etc .... There really is no comparison
With a real network card, the network setup for FreeBSD was
taken care of by the install. Worked flawlessly, first time.
I answered the standard questions once and it just worked.
It even uses our NIS server to contact the real world.
I do agree though that setting up PPP/SLIP under FreeBSD is
much more work than under most of the MS-Windows stacks.
But most MS-Windows inplementations do not allow the user
the full range of options that PPP allows. You pay a price
for flexability.
henry
These are my opinions and don't reflect my employer, my boss
or the guy who signs the checks.
Robert Brockway
: In article <3us0rg$7...@nntpd.lkg.dec.com>,
: Jon Jenkins <jenk...@ozy.dec.com> wrote:
: >Linux was never advertised and look at its poularity.
: >In Europe its user base is 10x that of FreeBSD.
: Wait a minute. Linux is advertised in Europe as it is advertised
: elsewhere. I believe the first book published about Linux was in Germany.
: It received a lot of positive magazine coverage in Europe.
This is akin to which came first, the chicken or the egg.
Books are printed about Linux because it is popular, not the other
way around. same with the magazines. Linux has been around since
1992, but it is only since 1994 that its name has appeared in
magazines. It was already very popular by this point.
-Robert
--Robert Brockway, email: ec53...@student.uq.edu.au
WWW: http://student.uq.edu.au/~ec531667
No silly quote today.
Carl Harris
: Whoa there, surely you jest! I wont go into a
: diatribe here. Just compare setting up two simple
: applications (forgetting all the nasty kernel configuration)
: compare setting up Eudora Mail on Windows with /etc/sendmail.cf
: on UNIX!!!!
You're comparing apples and oranges here. Eudora is a user application.
Sendmail is a mail transport agent, not a user application. Sendmail does
*many* things that Eudora was never intended to do; that no mail user
application is intended to do. There are a number of Eudora-like
applications (including Eudora itself) for Unix, if you want to make such
a comparison.
I'll agree that Unix user applications tend to be a little tricky to
install, but if we're going to compare difficulty levels, let's stick to
packages that are comparable.
--
Carl Harris
EXECUTIVE Scapegoat (and Systems Engineer)
Department of Computer Science, Virginia Tech
ceha...@cs.vt.edu
Doug Rabson
>
> [...]
>
> I think the point is pretty much moot, myself. I see both monolithic
> and microkernel designs heading for the same destination.
This reminds me of when my martial arts teacher says that it doesn't
matter what art you practise; if you work at it long enough, you will
end up in the same place.
Perhaps one day, Mach, *BSD, Linux will all gracefully merge into the
'Zen Operating System'. Now, the only question is, what is the OS
equivalent to the Zen warrior instruction, "Don't think, act!"
--
Doug Rabson, Microsoft RenderMorphics Ltd. Mail: d...@render.com
Phone: +44 171 251 4411
These are not the opinions of Microsoft. FAX: +44 171 251 0939
Nate Williams
> From a theoretical perspective, nobody has really written a real
> microkernel yet.
Everything I have read and seen regarding QNX implies that they wrote a
'real' microkernel. Unfortunately it costs money and you can't get
source code to it. ;(
Jordan K. Hubbard
Jon Jenkins <jenk...@ozy.dec.com> wrote:
>If however the aim is to make FreeBSD as attractive
>as possible to potential users without compromising it's
>compatibility with the historical UNIX base I suggest
>the best way to do this is to concentrate efforts on
>ease of use factors and a comprehensive GUI app builder
>closely followed by apps to do all the nasty stuff would
>be paramount.
I would say that this pretty much sums up our "mandate" in 500
words or less.
Not that we're adverse to technical advancement or innovation - the
whole UNIX framework has some pretty ancient misfeatures that are
going to take some rethinking to fix or re-work in ways that won't
break the world, and we'll certainly be going over those issues
at some point. Our first mission is, however, to increase its
general applicability to a number of networking and enterprise server
tasks by making it easier to install and to administer. I strongly
feel that this historical shortcoming must be overcome before we can
really move on to the other issues blocking FreeBSD's (and, indeed,
UNIX in general's) advancement in the operating systems arena.
Jordan
Jon Jenkins
>In article <3v01bh$q...@nntpd.lkg.dec.com>,
>Jon Jenkins <jenk...@ozy.dec.com> wrote:
>>This is patently untrue. NT is based on the mach kernel
>
>Just for clarification, NT is *NOT* based on the mach kernel, although
a
>few of the big Mach folks do work for M$, and probably have brought in
>many of the features of Mach into NT.
"I have seen the light" or in this case the source....
NT **IS** based on Mach (noticed I said **based on** not **uses**)
You say "Mach folk" as if it is commercial orgainsation. Do you
know where Mach kernel came from ?? Mach came from a research group
at CMU and started in 1985 or there abouts. Both OS/2 and NT
are **based on** on the original Mach kernel. The port of OS/2
to RISC is not just **based on** Mach it uses substantial portions
of it!
>
>AFAIK, NT is still a monolith kernel, although it has loadable drivers
>which give it a 'micro-kernelish' flavor. But, Sun boxes have been
>doing this for awhile and all of the free *nix clones also have this
>ability as well.
As has OSF/1 from its inception, also **based** on the Mach kernel
and yes I see the source on a regular daily basis. Next was also
**based on** the Mach kernel although in this case I have never
seen the source. As was Luna and a few other OSs.
Anyway enough of this pointless bickering. The discussion was about
which direction FreeBSD should point it's limited resources now
that it is a relatively mature product. I do not see Mach as
being relevant to FreeBSD unless FreeBSD wants to move to
a real time kernel base in which case Real-Time Mach would
probably be a good choice.
Jon Jenkins
>In article <3us0rg$7...@nntpd.lkg.dec.com> Jon Jenkins <jenk...@ozy.dec.com> writes:
..snip
>
>I tried Windows/386 and Windows/286 before windows v3.0 - it was horrendous.
>3.0 was a dramatic improvement - so much so I tend not to acknowledge the
>earlier versions ;)
Yes Im sure Microsoft agrees with you: Huh Windows/386, what was that !!
>>Well this would be a good start as long as it will work on the LessTif
>>base. Motif being a commercial and relatively expensive is not
>>a consideration for "FreeBSD" at least in my view.
>
>Well, that's LessTif's intent - 100% compatibility with Motif...
It looks promising. I downloaded it and after a few problems
compiling it started with the examples from a text. Looks
very promising.
>
>>I'm hoping to get together (in the electronic sense) with Terry
>>Lambert to have a look at this area and we will certainly look
>>at this option. Interested in helping out ??
>
>I'd love to, but unfortunately I've already promised some of my time to the
>documentation project and with my schedule that's already more than I can
>handle :) (don't let the .edu fool you, I work for a living too :)
I know the feeling. I cannot add anything to the kernel because
of my role at DEC and having potentially "inside" or "confidential"
knowledge of the workings of OSF/1 and ULTRIX prevents me
from contributing to anything related to the kernel. But since
I have never used X/Motif or anything like this at work
I can probably contribute without any "legal" problems.
..snip OS/2 stuff
.. stuff related to setup on DOS/Windows vs UNIX
OK, I will agree with you here and I did give one of the
worst possible examples in sendmail. I suppose I am biased
as I run plain vanilla box. Intel Pentium, Diamond Stealth VRAM,
NCR SCSI, SCSI disk, SCSI CD-ROM, SCSI tape and thats it so
setup under either system is preety trivial.
>
>>I have never had a problem with this but I have
>>had plenty of problems setting up FreeBSD and I work
>>inside the kernel of OSF/1 and ULTRIX everyday!!
This still holds for me. I have on several occsaions
had to reload all my DOS/Windows and apps. For me
and my system (barring all the @#$%$#@ disks I have
to feed the damm thing) it is still easier to setup DOS/Windows
than FreeBSD and I work with UNIX everyday. I only use
Windows for word processing and sending faxes although
I have mail, ewan and Netscape setup and use SLIP
to work for both. I f I had a decent GUI word processor
and fax I would dump Windows altogether!!
>[snip]
>>As for "ls" well here is perfect example: if we had a good file manager
>>for X then "ls" would be available for your use if you wanted but
>>bascially obsolete for everyday use. Yes I do have xfm but we miss the point:
>
>X is not officially part of FreeBSD, so why is it on FreeBSD's shoulders to
>develop it? On top of that, any X-windows program should compile on any UNIX
>if programmed correctly, which means if the linux camp developes one, as long
>as the source code is available, FreeBSD can use it to. That's the beauty of
>UNIX, free software, and an OS that comes with compilers built-in :)
Yep I agree. I don't think it is on FreeBSDs shoulders to
develop one. This was really a question of where should the
limited resources of FreeBSD be pointed at next now that,
as of 2.0, FreeBSD is a good solid UNIX compatible OS
quite useable in almost any situation where you might
buy a commercial UNIX and better in some respects.
>[snip]
>>Just as an interesting aside did you know
>>that the US goverment has accepted NT as an Open
>>System. If you dont get the significance of this
>>then it effectively allows NT to replace any
>>UNIX operating system in the Goverment services.
>>Two large military organisations (I'm not sure
>>I can tell you who so they will remain nameless)
>>have already announced they will swap from UNIX
>>to NT. You have got to ask yourself why ?
>
>Okay, why? Especially when Novell's UnixWare is available, and completely
>manageable using the Motif-based manager tools. It's still UNIX, but is as
>easily configured as NT. That's a different conversation though. I also use
>NT and love it. The only reason I keep DOS around is because NT won't run my
>games, and because Reachout and my scanned don't have NT version yet (they
>still rely on DOS device drivers)
I think this decision was based on the belief that
1: most people without extensive commputer experience
would find NT more familiar ands easier to use than any UNIX
2: Cheap apps. How much does MS Office cost: $500. How much to outfit
a UNIX box with the same facilities: you would not get much
change out of $20,000.
3: There is nothing in the UNIX world that even comes
close to the likes of MC++, BC++ and Delphi is somethinig else.
This makes development easy, cheap and fast.
>Regardless, you state directly that this is not a problem of just FreeBSD, but
>of UNIX as a whole. Rather than saying FreeBSD will die if this doesn't
>happen, and pinning all the responsibility on the team, and freebsd users, pin
>it on EVERYONE. Get the Linux, NetBSD, Mach, and 386BSD, and WINE project
>programmers involved too. Personally I think all of the UNIX teams need to
>work together to get people using UNIX, to develop the tools needed to make it
>work, to get applications ported to UNIX, and to make people notice it in
>general. Then we can fight and bicker about whose dad's can beat each other
>up :)
Yes absolutely positively without any shadow of a doubt. I think
FreeBSD is mature enough to either participate or to take
the lead. As this wouold be an X based project it would be
portable to other X based platforms. It really depends
on whom ever is driving the FreeBSD bus (jkh??) decides
to spend the somewhat limited development resources.
Thanks again for your considered response.
Regards
Jon Jenkins
>Jon Jenkins <jenk...@ozy.dec.com> wrote:
>> Actually Windows/386 was the first and the compatilbility problems
>> killed the other efforts. I'm sure that this compatibilty problem
>> was not all by "accident".
>
>
>And I quit using it shortly thereafter. The rest were MUCH more compatible
>with what counted... DOS...
So did I but a lot didn't.
>
>> Whoa there, surely you jest! I wont go into a
>> diatribe here. Just compare setting up two simple
>> applications (forgetting all the nasty kernel configuration)
>
>> compare setting up Eudora Mail on Windows with /etc/sendmail.cf
>> on UNIX!!!!
>
>Compare setting up Eudora Mail on windows with setting up "elm". Eudora
>isn't a server.
Yes thats true. But the fact still remains it is possible to set
up Eudora in a few minutes without reading a single man/page. I had
to read voluminous diatribes on sendmail before I even attempted
it. However this was a trite response: as you state I gave one of
the worst possible examples in sendmail!!
The example of printing was not trite in the least. I still
cannot print any graphics with my dot matix printer on UNIX.
That and a decent word processor and GUI fax are the only reaons
I still use Windows at all.
>Yeh. How *do* you set up a printer in Windows so it prints a banner page?
>I'm still trying to figure this out. If I install the ".SEP" files they
>provided the printer spits out an error message and dumps the job.
I dont consdier banner pages in the same league as not being able to
print at all.
>
>> Windsock was trivial, perhaps a few minutes.
>
>Yeh, clients are inherently easier to configure.
>
>I'm still working on getting network backup of my NT server up.
We had no problesm with this ( I didnt do it myself the sysadmin
did) so I dont know how much effort was required, either in
time or acuired knowledge, but it took only a few minutes
to set the backup to the UNIX server.
>
>> /etc/hosts
>> /etc/hosts.conf, bind, NIS, SLIP, PPP, routing, device
>> slattach, etc etc .... There really is no comparison
>
>Right. UNIX exposes the configuration details. Windows hides them, so if
>you're doing anything but setting up a vanilla client you're scrod.
They should be hidden fromthe average user. The whole
philosphy of modern computing and OO is to hide
the details IF you dont want to see them. The config
files, *.ini, are there if you want to get in and
hack them with notepad or whatever.
>
>What this means is that the POSIX subsystem conforms to FIPS 151. This
>doesn't mean it's an "open system" in any real sense. The POSIX subsystem is
>deliberately crippled, so as to be no more than a checkbox on the purchase
>requisition form.
Yeah but ohh what a checkbox!!. Regardless of the "purity" of the
classification it still holds that NT can now replace
any UNIX system in Goverment service and the rush has
already started.
>
>So long as it can actually do the job.
>
>> Two large military organisations (I'm not sure
>> I can tell you who so they will remain nameless)
>> have already announced they will swap from UNIX
>> to NT. You have got to ask yourself why ?
>
>Because they're followers?
of who, they were the first! the followers are yet to come.
I suspect that there were other reasons as well:
1: cheap apps
2: familiarity with Windows, and compatibility
>
>I'm supporting UNIX and NT here. NT is easy to set up in a vanilla
>configuration. It is *impossible* to debug problems. You just have to
>try things... I'm not talking about "I don't know how this works" I mean
>"there is no indication what the problem is".
I have not had much to do with NT but I have heard this
before. The error logging is supposed to be preety good
if you turn on all the options. But I'll take
your word that it is not as good as reported.
>
>Meanwhile in FreeBSD 99.5% of the problems can be diagnosed by looking in
>/var/log.
Yes I do agree that UNIX histoically has had lots of
error logging output. The output however has not
always been of much use:
/var/syslog.dated/XX:XX:XX
my_app: init failed: timeout on device: /dev/my_device with error code: 56
Huh what the hell does that mean ???
A popup dialog with a help button and decent human
readable help text and suggestions is obviously preferred.
>
>Yes, a better interface for the dumb stuff will help, but NT is no bed of
>roses. Well, if you count the thorns...
I wasnt supporting the NT system, just saying that it
is perceived, correctly or incorrectly, that it is easier
to install, configure and maintain than UNIX. There is
no reason why UNIX community can't borrow the "good" bits
from Windows, NT or any OS.
Thanks for your reply
Larry Riedel
Jon Jenkins (jenk...@ozy.dec.com) wrote:
> 3: There is nothing in the UNIX world that even comes
> close to the likes of MC++, BC++ and Delphi is somethinig else.
> This makes development easy, cheap and fast.
I'm not sure what "comes close to the likes of" means, but for
me, developing non-GUI C++ code with emacs and gcc on Unix is
easier, faster, and cheaper than with MSVC++ on NT, although
obviously pre-compiled headers and incremental linking would
be welcome enhancements to gcc, but I think that Unix is still
overall a much better development environment than NT ( even
WITH the MKS toolkit :). Writing GUI code may be easier (for
the money) on NT, but as a software engineer I do not find GUI
building to be a very interesting challenge anyway - maybe one
step above database programming. :)
Larry
Peter da Silva
> From a theoretical perspective, nobody has really written a real
> microkernel yet.
QNX?
OK, it's an icky commercial product instead of a lovely academic research
platform, but it's the closest to the ideal microkernel I've ever heard of.
Peter MacLeod
[etc]
: If this happens I couldn't be more pleased. Looking back on the history of
: Unix I can only point to a few good things that ever came out of commercial
: vendors dicking around with it. The vast majority of good things in Unix
: today came out of universitys, mainly grad students, not to mention the
: enjoyable names as well. Can you imagine a commercial vendor naming a
: program "lint" for example?
This is a naive view of history.
"lint" came out of Bell Labs, and was sold as part of AT&T's Unix pretty
early on.
Many of the most important ideas in computing of the last 25 years have
come out of research arms of commercial entities, e.g. Bell Labs for UNIX, C,
etc., Xerox PARC for the GUI, the Mouse, the laser printer, etc.
It is interesting to notice that in the case of Unix, the UC Berkeley work,
certainly the most important effort in the development of UNIX after the
original work by Thomson & Ritchie et. al. at Bell Labs, was mostly IMHO to
"finish" the system, make it into a usable large-scale operating system,
with coherent networking, VM, high-performance file systems, etc. Such work
is, well, a lot of work, and a lot of it was well done, but, for example,
designing a new filesystem doesn't necessarily consititute a "great advance
in operating systems."
: The next great advances in operating systems will originate in the academic
: community, and be refined by commercial entities. That is how it always
: has been and how it always will be. So what if these ideas are brought
: from Unix into a commercial OS?
Some people do the ground-breaking things, some people do the incremental
work that make things useful to others. Both kinds of people exist in
both the academic and commercial sectors, and both kinds of of people are
necessary.
--P
Alan F Lundin
Nate Williams <na...@sneezy.sri.com> wrote:
>In article <3v01bh$q...@nntpd.lkg.dec.com>,
>Jon Jenkins <jenk...@ozy.dec.com> wrote:
>>>If you look at all of the good things that are in NT and OS/2 they all
>>>originated with work done on the Unix operating system. Well, with OS/2
>>>some came also from IBM's work on SYS/36 but the point is there.
>>
>>This is patently untrue. NT is based on the mach kernel
>
>few of the big Mach folks do work for M$, and probably have brought in
>many of the features of Mach into NT.
The word I hear is that Rashid (of Mach fame) is in
a position something like a "Fellow". In other words,
he has no product development responsibilities, and can
work on whatever he pleases. I gather his work has no
ties or association with Cutler's NT (formerly VMS) group
except that they all now work for Micro$oft. Also, I hear
that the "Cairo" OS that MS is working on is a repackage
of the OO version of Unix called "Clouds".
--alan
--
Alan Lundin <afl...@sandia.gov>
Dan Hildebrand
>
> From a theoretical perspective, nobody has really written a real
> microkernel yet.
I think many would argue that QNX qualifies as a true microkernel. Even
the people who first coined the term "microkernel" agree that QNX is a
microkernel OS (Ira Goldstein and Paul Dale). :-)
> So far, the microkernels (including Mach) appear to
> be at least as complex as their monolithic brothers and require
> about as much work to port across platforms.
An examination of QNX will show an architecture MUCH simpler than that of
many operating system. One reason for this is that the processes around
the microkernel that provide OS services exhibit a POSIX/UNIX personality
directly, rather than attempting to be "personality neutral". As a result,
a service-using process does IPC directly with a service-providing process,
not through some additional levels of abstraction. The resulting
architecture is very "flat", and not layered heavily at all.
> Just adding
> a few more levels of subroutine call does not a microkernel make,
> IMHO.
Agreed.
> On the otherhand, I keep hearing people screaming about how inefficient
> microkernels are. There is nothing in the inherent design that requires
> a microkernel to be any less efficient then a monolithic design, it is
> only the *current implementations* you see in the field which are
> inefficient, which I attribute simply to bad design irregardless of
> whether it is a microkernel or not.
The problem with attempting to make a comparison between a monolothic
kernel and a microkernel OS, is that you can't compare the architectures
alone, you invariably end up comparing the quality of implementation as
well. For a comparison to be meaningful, you need to locate "best of
breed" examples of each approach and then make a comparison.
> I think the point is pretty much moot, myself. I see both monolithic
> and microkernel designs heading for the same destination.
I'm not so sure. Microkernels do distributed applications much nicer than
monolithic kernels, given the orthogonal means by which both local and
remote services accessed.
--
Dan Hildebrand (da...@qnx.com) QNX Software Systems, Ltd.
http://www.qnx.com/~danh 175 Terence Matthews
phone: (613) 591-0931 (voice) Kanata, Ontario, Canada
(613) 591-3579 (fax) K2M 1W8
Jon Jenkins
in the next few years and what, if any, should the limited
resources of FreeBSD be directed at. I suggested
that a good GUI app builder should be paramount
**IF** the consensus is that ease of use features
are the next on the agenda.
Please keep to topic or start a new one!!
Jon Jenkins
>
>Jon Jenkins (jenk...@ozy.dec.com) wrote:
>> 3: There is nothing in the UNIX world that even comes
>> close to the likes of MC++, BC++ and Delphi is somethinig else.
>> This makes development easy, cheap and fast.
>
>me, developing non-GUI C++ code with emacs and gcc on Unix is
>easier, faster, and cheaper than with MSVC++ on NT, although
>obviously pre-compiled headers and incremental linking would
>be welcome enhancements to gcc, but I think that Unix is still
>overall a much better development environment than NT ( even
>WITH the MKS toolkit :).
All I can say to that is that it is a very personal choice,
one which is definitely in the minority. Sureley you can't
compare the integrated project management, edit, compile,
debug, profile, context sensitive help environment, icon,
bitmap, menu and other resource builders, etc etc
of Borlands C++ to UNIX tools. Come on be serious,
there simply is no comparison in terms of
efficiency. Good grief dealing with emacs alone is like
wrestling with a dinosaur with a Lisp pteradactyl thrown
in for good measure of frustration and unnecessary crap.
I have said this before: if you want to see how GUIs
should be developed have a look at Delphi, it will
blow you away!!
>" Writing GUI code may be easier (for
>the money) on NT, but as a software engineer I do not find GUI
>building to be a very interesting challenge anyway - maybe one
>step above database programming. :)
You completely miss the point here. The aim is be able to
provide the tools to build GUI front ends quickly
and easily. The backend code can be as interesting
or as boring as you like from theoretical particle physics
to system administration. You cannot deny that GUI interfaces
are generally easier and more friendly to use
let alone conext sentive help, multimedia etc. Like
it or not this is the way computing is going or has
already gone!!
Look at the popularity of WWW explosion over the past
12 months. The Internet has been available for 10+ years
but limited mainly to academic circles. Put a GUI
in front of it, call it WWW and whammo all of a sudden
millions of previously unimpressed people want it.
IMHO FreeBSD should also have the GUI mentality as an
option. In order to do that GUI interface builders
are almost mandatory.
This brings up an interesting point for discussion:
Is it possible to use Web tools as a GUI builder i.e.
to have a cut down browser to interface between
the user and back end code. The server (which is really
on the local machine) is used to access an HTML
encoded front ends ?? In this way the publicly
available Web tools could be used to build
the front end to apps in a standardised way
?? How would the user selections and entries
and back end output get between the HTML engine and
the back end code ? interprocess comms,
network, shared mem, pipes ??? Pardon my ignorance
if this is a dumb suggestion but I know little
of the Web technology.
J Wunsch
>I know the feeling. I cannot add anything to the kernel because
>of my role at DEC and having potentially "inside" or "confidential"
>knowledge of the workings of OSF/1 and ULTRIX prevents me
>from contributing to anything related to the kernel.
Interesting. Matt Thomas doesn't seem to have this kind of troubles,
he's been contributing the 100 MBit ethernet and FDDI drivers, and
he's also a DEC employee.
>I think this decision was based on the belief that
...
>3: There is nothing in the UNIX world that even comes
> close to the likes of MC++, BC++ and Delphi is somethinig else.
> This makes development easy, cheap and fast.
OTOH, the problems related with an unprotected operating system do
make development on those systems a nightmare, expensive and slow. As
a formerly rather happy Borland user, i wouldn't really like to change
back from Emacs/gcc/gdb (sort-of Integrated Development Environment
for me) now. Just the fact that a single error writing some garbage
around a NULL pointer will cause my system to hang without any chance
for a post-mortem analyzation would make me sick of using them these
days, now that i know of SIGSEGV's and core dumps.
Stephen Hovey
>
>In <3v7lfo$s...@nntpd.lkg.dec.com>, Jon Jenkins <jenk...@ozy.dec.com> writes:
>>Enuff already!! this started as the future of FreeBSD
>>in the next few years and what, if any, should the limited
>>resources of FreeBSD be directed at. I suggested
>>that a good GUI app builder should be paramount
>>**IF** the consensus is that ease of use features
>>are the next on the agenda.
>
>reading this newsgroup for a while and playing around with Linux I would think
>that the things that need to be addressed are:
>
>o Easier installation and improved installation documentation
>o Better migration, or at least good documentation, to guide users going from
> one version to another.
Here here to this one! Nobody ever responded to me on how to upgrade to a newer
version without starting from scratch!
>o Gui management tools
>
Brian Tao
>
>Here here to this one! Nobody ever responded to me on how to upgrade
>to a newer version without starting from scratch!
Jordan mentioned something about an upgrade mechanism for 2.1
during the 950726-SNAP discussion in one of the FreeBSD mailing lists.
--
Brian ("Though this be madness, yet there is method in't") Tao
ta...@gate.sinica.edu.tw <-- work ........ play --> ta...@io.org
Timothy W. Barney
>pe...@nmti.com (Peter da Silva) writes:
>>QNX?
>>OK, it's an icky commercial product instead of a lovely academic research
>>platform, but it's the closest to the ideal microkernel I've ever heard of.
I have recently started using QNX at work. It truly is a micro Kernel,
with over 100,000 installed systems. The places using QNX that I know of
run it on x86 systems. I went to a MACH internals tutorial at USENIX in '91
or so and what they described fits QNX. Then I spent a year developing
in the MACH kernel from OSF - and it perfectly appears as a monolith,
right down to several hundred thousands of lines of code! (it did
scale across multiple parallel processors, but was a bear to work with
by all accounts).
Under QNX, you configre a kernel with what ever servers you want -
the scheduler and pager are required, but file services, serial lines,
what ever, can be configured into the kernel or started as daemons from
the bootup script. Or replaced by your own server.
Anyways, it's a real micro kernel. One caveat, it's very insecure as an OS.
one perspective, humbly submitted,
timothy
--
Timothy Barney, Software Engineer, tba...@medar.com, Opinions are my own
Medar Inc., Welding Controls and Visual Inspection Technologies
Farmington Hills, MI (outside Detroit) (810) 477-3900
Liberty is protected by 4 boxes: Soap,Ballot,Jury,Cartridge. Use in that order.
Peter Wemm
>In article <3v0rk7$a...@blob.best.net>, Matt Dillon <dil...@best.com> wrote:
>> From a theoretical perspective, nobody has really written a real
>> microkernel yet.
>QNX?
>OK, it's an icky commercial product instead of a lovely academic research
>platform, but it's the closest to the ideal microkernel I've ever heard of.
Yes, but it has DOOM! :-)
-Peter
(PS: from what I've seen, QNX looks really nice... It doesn't appear
that they've let total unix compatability get in the way of a
lightweight, efficient OS)
Jon Jenkins
>In <3us0rg$7...@nntpd.lkg.dec.com> Jon Jenkins <jenk...@ozy.dec.com> writes:
..snip plea not to reply !!
>
>Gee, it would be absolutely awful if UNIX were relegated to the backwaters
>of scientific and technical users, wouldn't it?
But in this sceanrio it wouldn't even be used by them. With NT
ported to Alpha and OS/2 about to appear on RS and probably
on PwerPC the traditional hw advantage of the workstation
will evaporate. Now that NT has been declared an "Open System"
watch it disappear from Goverment and scientific uses.
What I am saying is that the major overt (i.e. obvious) differences
between NT/OS2 and UNIX are:
1: GUI
these are both fully GUI based systems UNIX is not. GUI
whether you like it or not is perceived to be easier
to use by the majority of computer users.
2: Cheap Apps
There are a plethora of cheap apps for NT/OS2 whereas
UNIX apps are traditionally 5-10x the cost. They are
easy to develop. You cannot compare developing a GUI
app under something like Delphi to X. The time
and level of knowledge required are of the same
order as the cost: 5-10x.
>Why would the UNIX community in general need the ability to develop
>"fast cheap GUI applications including system admin and configuration
>and multimedia in object based paradigm"? Most people who use software
>do not develop it, they buy it.
And thats the problem. For $500 I can buy a full featured
Office suite from MS. It inlcudes desktop publishing,
spreadsheet, word processing, fax, project management etc etc etc etc etc....
The same quality apps for UNIX would not leave change out
$20,000. You have got to ask WHY ??
> They don't really care how difficult it
>is (or is not) to develop, other than how it relates to quality and cost.
>And heaven knows ease of development has a loose relation to quality
>and cost, look at the (now 7th!!!) beta of Winblows '95.
Ease of development (i.e. time=monsy) bears no relation to cost.
You jest sureley ?
>
>There are several companies producing impressive distributed systems
>management tools for UNIX. Between them, these companies have everything
>from user account maintenance to load balancing to data mirroring. The
>fact that these fine products exist, and that others will soon be avail-
>able, and that they compete with each other, means the customer is probably
>already getting a "better deal."
He might well be but only in relation to UNIX, certainly not
in relation to similar NT/OS2 products.
>
>The SGI workstations are still *the* workstation for developing multimedia,
>even if the platform being developed for is Winblows or Mac. Don't take my
>word for it, read the articles in _Computer Graphics World_.
Yep for top quality video and mutlimedia SGI is still the one. Desktop
publishing is another story (pardon the pun) SGI has already lost
the battle. This will also change very quickly now. The Pentiums
and P6 PCs are already faster than the MIPS platforms and the
sw is catching up real quick!!.
>
>Pundits have been predicting the demise of UNIX at the hands of VMS,
>MS-Windows, Mach, Choros, or whatever you please for years, and it hasn't
>happened yet. UNIX will meet its demise when somebody comes along with
>something better, which *nobody* has yet. I have hopes that we will see
>such a system soon; there is some promising research going on in Plan 9
>and SpringOS.
The reason it has never happened is for 3 reasons:
1: hw hw hw. The PC hw base has not up until recently been a match
for traditional UNIX hw platforms. That advantage is now reversed with
100+MHz P5 and P6s being more potent than most UNIX based hw.
2: Windows was never a match for UNIX. NT and OS/2 are as good as
UNIX in most areas and better in some. Although they lack some
of the traditional functionality of UNIX they usually provide
acceptable alternatives.
3: NT and OS/2 have both been ported to traditional hw platforms
and compatibility of apps across all the hw platforms is a
particularly attractive feature.
All I am saying is UNIX could do better in this respect
and if it doesn't it may well decrease further in popularity
and even UNIX needs a base level of usage to keep
the ball rolling.
Thanks for your reply
Jon
--
----------------------------------------------------------------------
Name: Dr Jon Jenkins Location: Digital Equipment Corporation NaC
Voice/Fax: 61-7-55-75-0151/100 Burnett Place, Research Park,
Inet: jenk...@ozy.dec.com Bond University, Gold Coast
Close Proximity: "HEY YOU !!!" QLD, AUSTRALIA 4229
"Daddy, what's outside the Universe?" (My 5 year old.....)
-----------------------------------------------------------------------
fre...@i-2000.com
>Enuff already!! this started as the future of FreeBSD
>in the next few years and what, if any, should the limited
>resources of FreeBSD be directed at. I suggested
>that a good GUI app builder should be paramount
>**IF** the consensus is that ease of use features
>are the next on the agenda.
I don't even have FreeBsd yet (going to order next week though), but after
reading this newsgroup for a while and playing around with Linux I would think
that the things that need to be addressed are:
o Easier installation and improved installation documentation
o Better migration, or at least good documentation, to guide users going from
one version to another.
o Gui management tools
Barnacle Wes
| please dont reply as this a a really really
| really subjective opinion but here goes:
|
| Unless the UNIX community gets together
| and provides the common toolsets to develop
| fast cheap GUI applications including
| system admin and configuration and
| then I predict that within 10 years
| UNIX will be relagated to
| academic circles with NT and OS/2 being
| the predominat OS for both Goverment and
| commercial systems.
Gee, it would be absolutely awful if UNIX were relegated to the backwaters
of scientific and technical users, wouldn't it?
Why would the UNIX community in general need the ability to develop
"fast cheap GUI applications including system admin and configuration
and multimedia in object based paradigm"? Most people who use software
do not develop it, they buy it. They don't really care how difficult it
is (or is not) to develop, other than how it relates to quality and cost.
And heaven knows ease of development has a loose relation to quality
and cost, look at the (now 7th!!!) beta of Winblows '95.
There are several companies producing impressive distributed systems
management tools for UNIX. Between them, these companies have everything
from user account maintenance to load balancing to data mirroring. The
fact that these fine products exist, and that others will soon be avail-
able, and that they compete with each other, means the customer is probably
already getting a "better deal."
The SGI workstations are still *the* workstation for developing multimedia,
even if the platform being developed for is Winblows or Mac. Don't take my
word for it, read the articles in _Computer Graphics World_.
Pundits have been predicting the demise of UNIX at the hands of VMS,
MS-Windows, Mach, Choros, or whatever you please for years, and it hasn't
happened yet. UNIX will meet its demise when somebody comes along with
something better, which *nobody* has yet. I have hopes that we will see
such a system soon; there is some promising research going on in Plan 9
and SpringOS.
--
Wes Peters | Yes I am a pirate, two hundred years too late
Softweyr | The cannons don't thunder, there's nothing to plunder
Consulting | I'm an over forty victim of fate...
w...@intele.net | Jimmy Buffet
Hobby Wizard
fast
>with X in 16M. Going to Lites will probably double the kernel size and
make
>a serious impact on memory requirements.
>--
>Peter da Silva (NIC: PJD2) `-_-'
I concur ... I prefer FreeBSD to Linux.
Joe
Michael Dillon
J Wunsch <joerg_...@uriah.heep.sax.de> wrote:
>Peter da Silva <pe...@nmti.com> wrote:
>
>[Tcl]
>
>>... It's the best tool available for integrating all those config
>>file management issues under one hood.
>
>While i agree with your other opinions, this one is arguable, and
>heavily depends on somebody's point of view. I could state ``Perl is
>the best tool available for ...'' with just the same right (and both
>are true). :-)
They are not the same thing. PERL is a great programming language for
doing all sorts of sysadmin stuff, for building special tools quickly,
for replacing shell scripts....
But TCL is something else. Firstly it is embeddable as the scripting
language for other applications similar to IBM REXX and Amiga REXX. Peter
was referring to config file management issues. For that you need a
couple of things. You need to build tools that allow a person to set up
config files in a GUI environment with built in help explanations of what
is required but minus the myriad of syntactical issues. Secondly, you
need a way to drive other applications via things like drag & drop. TCL
combined with Tk is admirably suited for these two things. When you start
getting down to actual applications, you are better off extending the TCL
language by writing C code to do the actual work and merely allowing TCL
to call those procedures and act as the glue.
Using this approach you can build a complete integrated graphical desktop
for configuring and managing a UNIX system with TCL/Tk as the scripting
language. This doesn't display PERL, however, and if you read through the
PERL 5 docs you will find that the TCL scripting language can be embedded
in PERL as well. Why would you do such a thing? Simple. If you want to
build your app in PERL rather than in C but still want to provide the
user/admin with a standard macro scripting language, you can do this by
embedding TCL within PERL.
SCO has built a graphical sysadmin system for their lates UNIX releases
using something they call Visual TCL which is TCL with access to the
entire Motif user interface and the ability to runb on text terminals too.
If you are interested have a look at
http://websco.sco.COM:80/Products/vtcl/vtcl.html
which will lead you not only to SCO's Visual TCL but also to many other
TCL and Tk resources on the Web.
--
Michael Dillon Voice: +1-604-546-8022
Memra Software Inc. Fax: +1-604-542-4130
http://www.memra.com E-mail: mic...@memra.com
Michael Dillon
Jon Jenkins <jenk...@ozy.dec.com> wrote:
>j...@bonnie.heep.sax.de (J Wunsch) wrote:
>>Jon Jenkins <jenk...@ozy.dec.com> wrote:
>>
>>
>>Interesting. Matt Thomas doesn't seem to have this kind of troubles,
>>he's been contributing the 100 MBit ethernet and FDDI drivers, and
>>he's also a DEC employee.
>
>the ISDN code. I asked if I could contribute to an ISDN
>driver for FreeBSD and was told no!.
But DEC sells 100baseTx cards and FDDI cards so naturally they told Matt
to go right ahead and gave him all the technical documents and a list of
email addresses of other employees to provide him tech support. DEC is a
big company and does lots of things but they are not going to say no to
increased sales of network cards.
Jordan K. Hubbard
Michael Dillon <mic...@okjunc.junction.net> wrote:
>SCO has built a graphical sysadmin system for their lates UNIX releases
>using something they call Visual TCL which is TCL with access to the
>entire Motif user interface and the ability to runb on text terminals too.
>If you are interested have a look at
>http://websco.sco.COM:80/Products/vtcl/vtcl.html
And, if the various people inside SCO and I can ever get it past SCO legal,
will be appearing for FreeBSD fairly soon.
Wish us luck!
Jordan
Michael Dillon
Why not just use TCL/Tk which is already available under the same
licencing terms as FreeBSD. I would think that you will run into problems
with Motif since Visual Tcl merely provides a thin wrapper around Motif
so that TCL programs can use it. You are, in effect, giving away free
Motif when you give away Visual TCL.
What is it about Visual TCL that makes you prefer it to TCL/Tk?
David O'Brien
: In article <3utfha$3...@nntpd.lkg.dec.com>,
: Jon Jenkins <jenk...@ozy.dec.com> wrote:
: > NT is a direct competitor for UNIX and you have got to
: > ask why use UNIX instead of NT?
: UNIX is far less likely to fuck up and leave you hanging without a clue
: as to why it's broken. Being able to see under the hood isn't just a
: matter of enjoyment, it's an essential part of system management.
Amen brother!!! When I took this sysadmin job a year ago, I was told I
would admin Solaris and NT servers and workstations. After having
admin'ed Netware, I figured NT would take about as much time and
trouble. WRONG!!! I am now quitting this job just to get the hell away
from NT. I spend 70% of my time with NT and 30% on Solaris. NT
workstation is fine. It is great compared to MS-Windows. In fact, I
will never use MS-Windows again.
BUT, just try to administer an NT server and domain (the equivalent to a
Unix NIS domain). In-freaking impossible! No diagnostics. No admin
tools. The user interface to sysadmin tools is as dumbed down as
everything else in ms-windows. Like Peter said, when you got a problem,
you are just hanging. Using NT is letting Microsoft decided how to
setup and run your LAN. At least with Unix, I have tons of
configurations I can set to customize the servers for the way *I* want
my network. Microsoft as some pretty f*cked up notions about domains.
After a while, you really wonder if anyone at Microsoft has every used
networked machines for over a week.
A small example:
The administrator under NT server doesn't have any permissions in user's
home directories. MS thinks, "now why should an administrator ever be
allowed permission in a user's home dir?"
Now what do you do when your 6-gig server that had 2-gig free last week
now has 200meg free? You want to do a little ``du'' action and find the
disk hog. Wrong, remember?, you don't have read permissions. Time to
fix this. So you pull up file manager, go into permissions. I'd like
to do a little ``chmod +r'' for the administrator in the user's
directories. Buzz, wrong answer. The tool only acts like ``chmod =''
(ie. setting the absolute permission, not just adding or subtracting a
subset). Just great, can't change permissions on the user's dir or
files without screwing up any other permissions a user may have given
someone else. Phone call to MS on thier primium support line (you
should see the companies yearly bill for this one...). The NT tech
support guys are ok in general workstation and install problems, but
administrating a server??? Surely you jest! BTW, I did finally find a
hidden command-line program that comes with NT to do what I wanted. But
you think dd or find has a weird syntax???
-- David (obr...@sea.legent.com -or- dob...@seas.gwu.edu)
David O'Brien
: > >I'm still trying to figure this out. If I install the ".SEP" files they
: > >provided the printer spits out an error message and dumps the job.
: > I dont consdier banner pages in the same league as not being able to
: > print at all.
: You don't have 100 people's printouts coming out on the same printer.
Agreed! And how do you keep MS in their infinate wisdom from NOT
pre-pending ^D to every PS print job in MS-Windows. That CtrlD option
doesn't do jack!
: > >I'm still working on getting network backup of my NT server up.
: > We had no problesm with this ( I didnt do it myself the sysadmin
: > did) so I dont know how much effort was required, either in
: > time or acuired knowledge, but it took only a few minutes
: > to set the backup to the UNIX server.
: Well, get your sysadmin to drop me a line. The NT backup software ONLY
: supports directly connected tape devices, totally incompatible with our
: centralized backup scheme.
Actually it *can* be done. You need the full-fledged version of
ntbackup. ntbackup is a braindead version of Arcadia's Backup Exec.
Only problem is it cost $1000 for the package that works with my NT
server and tape drives. But still having problems getting it run from
"cron" reliably. Man what I wouldn't give for cron and shell scripts to
run NT backups from. My Unix backup scheme took me 1 hour to fully
setup. My NT backups (for the whole domain)... Well that is still
on-going.
: > The config
: > files, *.ini, are there if you want to get in and
: > hack them with notepad or whatever.
: Not in NT. A lot are hidden in the resource database, and others aren't
: visible at all.
And the one's that are there, are named at least as weird as anything
I've ever seen in Unix.
: > I have not had much to do with NT but I have heard this
: > before. The error logging is supposed to be preety good
: > if you turn on all the options. But I'll take
: > your word that it is not as good as reported.
: I've got all the options I can find turned on and I still get "Can't
: initialize subsystem", without even the name of the subsystem it couldn't
: initialize. "Perror" is a better interface than that!
You forgot to mention just how "lovley" the Event Viewer is. It gives
much more cryptic things than "my_app: init failed: timeout on device:
/dev/my_device with error code: 56". And it displays each entry in a
stupid little popup box that is about 30 chars wide and 6 rows. I've
got a 1024x768 display. I think I can see a little more of the message
at one time MS idiots. How about a "full screen" button for that box???
Want to print out a few security events to show the boss and CYA when
you come down on that problem user? Nope, can't print out an event, no
pull down choice for it. Just do a screen capture and print it you say?
Nope, remember your 30x6 view of the world?
: > Huh what the hell does that mean ???
: It means either the device isn't connected, or it's not properly configured.
: It tells you what the device is, and where it's connected. And it implies
: that there's a hardware document over on the shelf that'll explain error
: code 56.
: That's loads better than "something's wrong but I'm not saying what".
: > A popup dialog with a help button and decent human
: > readable help text and suggestions is obviously preferred.
: Not if the popup dialog with a help button and decent human readable text
: and suggestions lead you down a dead end.
Exactly. For those that aren't, us sysadmin's are paid to fix problems.
That way, you don't have 100 people that need to be an expert on these
things. Messages like this one point us in the right direction. NT's
messages point you to hell.
: Oh, I found one of my problems. I used blind testing.
: A UNIX box would have told me the problem immediately.
Yea, just try setting up services (aka daemons) on NT. There is no
documention from MS on how they invoke them or the environments they
enherit. Seems like much of what we do around my workplace with NT is
all trial and see the responce. Unix has much better docs than this.
And if you make the right choice :-) of FreeBSD, you can even varify
with the source.
-- David O'Brien (obr...@sea.legent.com)
Death to NT!!!!
Jon Jenkins
..blast of NT.
I cannot argue either way I do not know enough about NT
in everyday use or sysadmin details. From
a kernel point of view NT is certainly better
documented than any UNIX I have everr worked on.
However I think you have missed the point: it is not
me who said this, the US government has declared that
NT is an Open System therfore putting NT in
direct competition with UNIX. As to whether
sysadmin's jobs will be more difficult I
have no opinion. The fact is that two very
large goverment/military groups have already
stated that they will change from UNIX to NT.
Like it or not the "perception" is that
the average computer user will find NT easier
to use than UNIX. Perhaps also the increased
sysadmin time was offset against the
time required by the more numerous "average user"
to come to grips with UNIX versus the more
familiar NT. A second reason would have
to be the relatively inexpensive apps
and development tools for NT versus the
ridiculous cost of similar UNIX tools
even if available.
Again this was not a deabate as to which OS
is better but rather what should be done
to FreeBSD to make it better. It seems
that GUIs are popular (understatement intended!)
Question is should FreeBSD adopt a GUI
development strategy and if so based on what
technology ?
Jon Jenkins
..snip more scathing NT remarks.
Just beacuse NT has some/many/numerous/infinite
number of bad points is NOT relevant. One of
it's good point is it has a good GUI and
developoment tools (best is yet to come
when Delphi ports to NT). This one good point
i.e. GUI, seems to be VERY VERY important to
the average user. Just because FreeBSD may
adopt a GUI for sysadmin etc does not mean it
will adopt all/any of NT's (or Windows or Mac's)
bad points. A good GUI on top of a good
OS (aka FreeBSD) would make it more popular
with users. If this is desired then a quick
easy GUI development toolset would ease the
porting of the many existing obtuse scripts/files
and design of new ones by allowing Mr/Mrs/Ms Average
user to develop GUIs without having to spend the
next few years learning Xt/Xlib etc. The idea
is that many hands will make light work and
the many hands will be there IF there is
an easy to use GUI based GUI builder.
To show you what happens when someone does
this. Borlands Delphi is an Object based
event driven drag'n'drop GUI builder for
Windows/Win95. When Delphi was released it
went to the #6 position in sw sales and
is still there. The newsgroup
comp.lang.pascal went from a relatively
quiet group to the busiest newsgroup on
the net.
Who ever heard of a compiler being in the Top 10?
The reason is simple: any idiot could design really
spiffy interfaces for Windows while only
knowing a fraction of Windows internals.
"Want a slider?, no problem: click, click, done"
"Want an SQL engine?: click, drag, drop, next ?"
"Want a file/print dialog'? click, click done"
"Want to build your own component? click, click...,
type few lines, pull up integrated
bitmap/icon/cursor/XXX editor,
rebuild library, done"
etc
Jon
--
----------------------------------------------------------------------
Ted Wisniewski
>j...@bonnie.heep.sax.de (J Wunsch) wrote:
>>Jon Jenkins <jenk...@ozy.dec.com> wrote:
>>Interesting. Matt Thomas doesn't seem to have this kind of troubles,
>>he's been contributing the 100 MBit ethernet and FDDI drivers, and
>>he's also a DEC employee.
>
>You will have to ask Matt about this. I wrote most of
>the ISDN code. I asked if I could contribute to an ISDN
>is quite understandable on Digitals part. Why should
>they let me use expertise I have gained while in their
>employ (and still so) on a potential competitors product.
I think the difference here is:
I think a driver for a piece of DEC hardware would get a blessing because
it will boost sales of such hardware.
Where ISDN is not a piece of DEC hardware and thus DEC has nothing to gain
and just would lose.
It is just good business practice to encourage sales of your product by
providing drivers. (If we could only get printer manufacturers to do
the same we would be all set).
| Ted Wisniewski INET: t...@oz.plymouth.edu |
| Computer Services t...@wiz.plymouth.edu |
| Plymouth State College te...@psc.plymouth.edu |
| Plymouth NH, 03264 HTTP: http://oz.plymouth.edu/~ted/ |
William R. Somsky
Jon Jenkins <jenk...@ozy.dec.com> wrote:
> Like it or not the "perception" is that
> the average computer user will find NT easier
> to use than UNIX. [...]
>
> Again this was not a deabate as to which OS
> is better but rather what should be done
> to FreeBSD to make it better. It seems
> that GUIs are popular (understatement intended!)
If GUI's, etc, _really_ do make things better, then OK,
but please, _please_, **PLEASE**, don't add them just
because they're "popular" or are "perceived" to be better.
IF IT'S NOT **ACTUALLY** BETTER, DON'T DO IT!!!
[ I was going to ramble on some more, but I'll
just leave it at this and save some net bandwidth. ]
________________________________________________________________________
William R. Somsky som...@phys.washington.edu
Department of Physics, Box 351560 B432 Physics-Astro Bldg
Univ. of Washington, Seattle WA 98195-1560 206/616-2954
Jordan K. Hubbard
Michael Dillon <mic...@okjunc.junction.net> wrote:
>Why not just use TCL/Tk which is already available under the same
>licencing terms as FreeBSD. I would think that you will run into problems
>with Motif since Visual Tcl merely provides a thin wrapper around Motif
>so that TCL programs can use it. You are, in effect, giving away free
>Motif when you give away Visual TCL.
Well, you are and you're not. You're exposing an API for using Motif
widgets indirectly, but you're not exposing the Motif API itself which
is where the OSF's money is (selling to people who need the Motif API
documented in the manuals). And the OSF has always permitted static
linking anyway, so?
As to why I might perfer SCO Visual TCL over TCL/Tk, well, who ever said
that I preferred it? It just adds another interesting dimension to the
possibilities, that's all. It's all very hypothetical right now anyway
until we actualy see the bits!
Jordan
Brian Tao
>
>If GUI's, etc, _really_ do make things better, then OK,
>but please, _please_, **PLEASE**, don't add them just
>because they're "popular" or are "perceived" to be better.
>
> IF IT'S NOT **ACTUALLY** BETTER, DON'T DO IT!!!
Well, what say you to a GUI-based kernel configuration utility?
You will have the choice of an X-based Tk interface, a libdialog-
based one (like the current installer) or a Web/CGI-based one. Better
than editing config files by hand, no? I mention this because there
is work under way for such a beast. Subscribe to the freebsd-hackers
mailing list if you want in on this project.
Dan Hildebrand
>>
>>pe...@nmti.com (Peter da Silva) writes:
>>>QNX?
>>>OK, it's an icky commercial product instead of a lovely academic research
>>>platform, but it's the closest to the ideal microkernel I've ever heard of.
>
>with over 100,000 installed systems.
The installed bass is significantly larger than this. :-)
>Under QNX, you configre a kernel with what ever servers you want -
>the scheduler and pager are required, but file services, serial lines,
>what ever, can be configured into the kernel or started as daemons from
>the bootup script. Or replaced by your own server.
Actually, the process of building a kernel is nothing more than "lumping" a
number of processes together so that once the OS is loaded into memory all
those processes can begin execution without having to be loaded from mass
storage first. If you know your system will have access to a network or
local hard disk, you only need to lump enough processes into the boot image
so that after boot loading enough OS is present to load the extra processes
from disk or network to complete your OS. Whether a process is started
from the boot image, or loaded and executed, it runs identically (in a
separate, MMU-protected address space). A bootable OS tends to consist of
a Process Manager (which implicitly includes the microkernel), a shared
library and then either Net and a Network driver or Fsys and a disk driver.
Everything else can be started by the bootup shell script.
If the OS you are configuring is intended to execute or boot from ROM, then
it needn't have any network or filesystem servers.
>Anyways, it's a real micro kernel. One caveat, it's very insecure as an OS.
I would argue that it is comparable to most UNIX systems in that it
implements the UNIX/POSIX standard group and member numbers and access
control, shadow password file, etc. Where QNX differs is that it treats
the network as a single logical machine with any process transparently able
to use any resource on any node as if it was local. As a result,
super-user for the "machine" implies super-user for the network. Various
"firewalls" can be erected to partition the network if necessary.
Terry Lambert
] Why would the UNIX community in general need the ability to develop
] "fast cheap GUI applications including system admin and configuration
] and multimedia in object based paradigm"? Most people who use software
] do not develop it, they buy it. They don't really care how difficult it
] is (or is not) to develop, other than how it relates to quality and cost.
] And heaven knows ease of development has a loose relation to quality
] and cost, look at the (now 7th!!!) beta of Winblows '95.
I agree. But the difficulty of development reflects on the cost
and the availability of the products. The Mac is harder to code
for than the PC, so the Mac sucks hind-teat as far as application
availability. Most business software for the Mac is ported to
the Mac from the PC or another platform.
UNIX has been typically thought of as multiuser, and the costs of
packages have reflected a per-seat cost multiplier as a result,
until license managers have become more available.
Now the license manager licensing cost is factored into product
price at an average per seat expected amortization.
Because of the increased difficulty of programming in a UNIX
environment -- or rather, the different expertise required -- the
UNIX market is not commodity with regard to software, and thus
the prices are set at what the market will bear instead of on
parity with the competition.
How many terminal emulation packages do you know about on UNIX?
I don't mean X stuff, which anyone can program, I mean the real
thing. Basically, one.
] There are several companies producing impressive distributed
] systems management tools for UNIX. Between them, these
] companies have everything from user account maintenance to
] load balancing to data mirroring. The fact that these fine
] products exist, and that others will soon be available, and
] that they compete with each other, means the customer is probably
] already getting a "better deal."
Yes, commoditization is a big factor in price. But so is the
level of effort necessary to achieve cross-platform homogeneuity.
Escpecially with systems management tools.
] The SGI workstations are still *the* workstation for developing multimedia,
] even if the platform being developed for is Winblows or Mac. Don't take my
] word for it, read the articles in _Computer Graphics World_.
I agree, mostly. DOOM was written on a NeXTStep box, after all.
Terry Lambert
te...@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
J Wunsch
>What is it about Visual TCL that makes you prefer it to TCL/Tk?
The ability to run also on a standard terminal? (Sorry if i'm
ignorant and this would also work with TCL/Tk, but from what i know by
now, i don't think so.)
J Wunsch
>... I wrote most of
>the ISDN code. I asked if I could contribute to an ISDN
>driver for FreeBSD and was told no!. The decision
>is quite understandable on Digitals part. Why should
>they let me use expertise I have gained while in their
>employ (and still so) on a potential competitors product.
(No offense to you, Jon, just my opinion:)
I think this policy would be impossible in Germany. I have to ask my
employer if i'd like to make some extra money in my spare time, but as
long as i'm going to contribute to non-commercial projects and don't
use any of the company's resources, they cannot prevent me from doing
this.
I'm selling my working-power, not my body/brain to my employer.
Bertram Barth
J Wunsch <joerg_...@uriah.heep.sax.de> wrote:
>Jon Jenkins <jenk...@ozy.dec.com> wrote:
>
>>... I wrote most of
>>the ISDN code. I asked if I could contribute to an ISDN
>>driver for FreeBSD and was told no!. The decision
>>is quite understandable on Digitals part. Why should
>>they let me use expertise I have gained while in their
>>employ (and still so) on a potential competitors product.
>
>(No offense to you, Jon, just my opinion:)
>
>I think this policy would be impossible in Germany. I have to ask my
>employer if i'd like to make some extra money in my spare time, but as
>long as i'm going to contribute to non-commercial projects and don't
>use any of the company's resources, they cannot prevent me from doing
>this.
>
>I'm selling my working-power, not my body/brain to my employer.
Just another opinion:
AFAIK it's not that easy. Here in Germany also it might depend on the
area the company is working in (and on the companies policy).
If a company is selling a product and you are working on this product
and thus get knowledge about some internal details which they think
are important/company-confident/whatever, then they maybe wont allow
you to contribute to a similiar project even if it's non-commercial.
(Eg. I can't imagine that one person is allowed to work on similiar
projects for two direct competitors at one time.)
I've seen contracts where it's explicitly written down that people are
not allowed to use the knowledge gained (and internals seen) while
working in a company to contribute to any other project.
And sometimes companies have funny ideas about what is company-confident
and about what you've learned from them :)
Things are totally different if your companies area of interest and
the goal of the non-commercial project are different.
Ciao,
bertram
--
at home: ber...@gummo.bbb.sub.org (++7251) 81325
at work: ber...@ifib.uni-karlsruhe.de (++721) 608-2168
Terry Lambert
] You will have to ask Matt about this. I wrote most of
] the ISDN code. I asked if I could contribute to an ISDN
] driver for FreeBSD and was told no!. The decision
] is quite understandable on Digitals part. Why should
] they let me use expertise I have gained while in their
] employ (and still so) on a potential competitors product.
This was Novell's point of view as well.
Pity I learned little at Novell not directly related to file
systems (and most of that I knew before; Weber has had a UNIX
source license for a long time) and NetWare. Neither of which
I was hell-bent on coding in FreeBSD at the time.
And they wouldn't let me fix the problems in UnixWare outside
of the little box they had me filed away in. The biggest case
of AI* I have ever seen.
I think they feared the raising of the bar.
Terry Lambert
te...@cs.weber.edu
---
*"Artificial Importance" -- Ed Lane
Terry Lambert
] In article <3vab2q$i...@buffnet2.buffnet.net>, Stephen Hovey <sho...@buffnet.net> wrote:
] >
] >Here here to this one! Nobody ever responded to me on how to upgrade
] >to a newer version without starting from scratch!
]
] Jordan mentioned something about an upgrade mechanism for 2.1
] during the 950726-SNAP discussion in one of the FreeBSD mailing lists.
I'd like to be able to in-place upgrade from Linux, please.
8-).
Terry Lambert
te...@cs.weber.edu
Terry Lambert
] Well, what say you to a GUI-based kernel configuration utility?
Yes... drag and drop loading of kernel modules by placing them
in a "System" folder.
Peter da Silva
Terry Lambert <te...@cs.weber.edu> wrote:
> Because of the increased difficulty of programming in a UNIX
> environment -- or rather, the different expertise required -- the
> UNIX market is not commodity with regard to software, and thus
> the prices are set at what the market will bear instead of on
> parity with the competition.
You watch how you phrase that.
The UNIX environment is orders of magnitude easier to *program* in than DOS
or NT or the Mac or any of those little bitty-box PC systems.
> How many terminal emulation packages do you know about on UNIX?
I wrote one. It's cool: it reads vt100 codes on stdin and writes your terminal
codes to stdout. You can stick it on the output of any application that expects
a vt100 and it runs it on your terminal.
The toughest part was figuring out what a real vt100 did on undocumented cases.
--
Peter da Silva (NIC: PJD2) `-_-'
Bailey Network Management 'U`
Peter da Silva
> widgets indirectly, but you're not exposing the Motif API itself which
> is where the OSF's money is (selling to people who need the Motif API
> documented in the manuals). And the OSF has always permitted static
> linking anyway, so?
So it'll be a tool distributed without source?
That's a pretty big negative, when Tcl/Tk is just a drop-in, and there's a
character-mode interface that's Tk-compatible.
Peter da Silva
J Wunsch <joerg_...@uriah.heep.sax.de> wrote:
> >What is it about Visual TCL that makes you prefer it to TCL/Tk?
> The ability to run also on a standard terminal?
ftp://ccfadm.eeg.ccf.org/pub/ctk/ctk4.0b1.tar.gz
Jordan K. Hubbard
>In article <3vkp33$j...@bonnie.tcd-dresden.de>,
>J Wunsch <joerg_...@uriah.heep.sax.de> wrote:
>> >What is it about Visual TCL that makes you prefer it to TCL/Tk?
>
>> The ability to run also on a standard terminal?
>
>ftp://ccfadm.eeg.ccf.org/pub/ctk/ctk4.0b1.tar.gz
Uh. I've looked at this, and all I can say is that while it looks
like a cute idea, I wouldn't have to be one to actually use it.. :)
No offense to the author in intended, but it's not really something
that I think provides sufficient capabilities in BOTH areas of direct
usability and quality of abstraction. Try taking a serious look at it
from the point of view of someone actually stuck with crafting
a production quality interface with it. There are big holes.
I think that emulating something as broad-based as Tk was the fundamental
mistake the author couldn't get around. You need to go one level higher
up for your forms and layouts to both look good and be easy to use.
Jordan
Toni Mueller
> Well, what say you to a GUI-based kernel configuration utility?
> based one (like the current installer) or a Web/CGI-based one. Better
> than editing config files by hand, no? I mention this because there
> is work under way for such a beast. Subscribe to the freebsd-hackers
> mailing list if you want in on this project.
I don't mind having these, but the system must remain completely configurable
with no more than /bin/vi, IMHO (and cc and such, for that matter).
I think it's a _really bad idea_ to throw these out and require running a GUI
to configure the system.
Regards,
--------
Toni M"uller M"uller & Brandt GbR sup...@m-u-b.de +49 2261 79351
Internet, Unix, networking, administration, consulting, programming
Microsoft Network is prohibited from redistributing this work in any form,
in whole or in part. Copyright, Toni M"uller, 1995. License to distribute
this post is available to Microsoft for $1000. Posting without permission
constitutes an agreement to these terms. Please send notices of violation
to sup...@m-u-b.de and Postm...@microsoft.com
Mikhail Teterin
|Brian Tao (ta...@gate.sinica.edu.tw) wrote on 1 Aug 1995 06:20:43 GMT:
|> Well, what say you to a GUI-based kernel configuration utility?
|> You will have the choice of an X-based Tk interface, a libdialog-
|> based one (like the current installer) or a Web/CGI-based one. Better
|> than editing config files by hand, no? I mention this because there
|> is work under way for such a beast. Subscribe to the freebsd-hackers
|> mailing list if you want in on this project.
|I don't mind having these, but the system must remain completely configurable
|with no more than /bin/vi, IMHO (and cc and such, for that matter).
|I think it's a _really bad idea_ to throw these out and require running a GUI
|to configure the system.
My full support! Having to deal with Windows NT at work, I know, what
happens when, say, Registry gets screwed -- the whole damn thing may
not come up! Even if this happened to be an Intell machine, and you,
accidentaly have a DOS installed -- you can not go and fix NT from it --
Registry database is in a binary form (unlike .ini files of plain old
Windows). You may very well end up reinstalling the whole OS.
So, yes, smth like control panel may be nice (not of the highest
priority, IMHO), but vi should remain sufficient for the job.
-mi
--
И пусть никто не уйдёт обиженным...
-- Why is that 2 o'clock all the time?!
-- It is a manometer!!!
Warner Losh
wrote:
>So, yes, smth like control panel may be nice (not of the highest
>priority, IMHO), but vi should remain sufficient for the job.
I believe that most of the people working on this issue agree with
this often made point.
Warner
--
Warner Losh "VMS Forever" home: i...@village.org
Cyberspace Development, Inc work: i...@marketplace.com
Makers of TIA, The Internet Adapter. http://marketplace.com/
Jordan K. Hubbard
>I don't mind having these, but the system must remain completely configurable
>with no more than /bin/vi, IMHO (and cc and such, for that matter).
>
>I think it's a _really bad idea_ to throw these out and require running a GUI
>to configure the system.
I'm sorry if it was ever implied that we would. Don't forget, we also
intend to have this beast install/configure easily from a _serial console_,
so we're not going to go so hog-wild with GUI front-ends that this becomes
impossible. We'd only be shooting our own goals in the feet.
Jordan
Jon Jenkins
...snip
>|I don't mind having these, but the system must remain completely configurable
>|with no more than /bin/vi, IMHO (and cc and such, for that matter).
>
>|I think it's a _really bad idea_ to throw these out and require running a GUI
>|to configure the system.
>
>My full support! Having to deal with Windows NT at work, I know, what
>happens when, say, Registry gets screwed -- the whole damn thing may
>not come up! Even if this happened to be an Intell machine, and you,
>accidentaly have a DOS installed -- you can not go and fix NT from it --
>Registry database is in a binary form (unlike .ini files of plain old
>Windows). You may very well end up reinstalling the whole OS.
>
>So, yes, smth like control panel may be nice (not of the highest
>priority, IMHO), but vi should remain sufficient for the job.
Absolutely agree. However to make BOTH manual and GUI setup
easier perhaps a globally based single keyword file otherwise
parsing becomes a nightmare. If desired the GUI tool (or vi)
can be used to modifiy the keyword file. Then if desired the
various "standard" files could be generated automatically.
For example in networking setup the files such as:
hosts
hosts.conf
resolv.conf
networks
etc etc
would still form the basis for the networking
setup and could still be edited by hand. Additionally
a global networking file (say networks.conf) with
sections for each of the base files could
be used by a utility (say netsetup) to generate
the individual files. Then a GUI utility (xnetsetup)
could be sued to generate/modify the networks.conf
file and subsequently call netsetup to generate the
base files.
Michael Dillon
>>happens when, say, Registry gets screwed -- the whole damn thing may
>>not come up! Even if this happened to be an Intell machine, and you,
>>accidentaly have a DOS installed -- you can not go and fix NT from it --
>>Registry database is in a binary form (unlike .ini files of plain old
>>Windows). You may very well end up reinstalling the whole OS.
>Absolutely agree. However to make BOTH manual and GUI setup
>easier perhaps a globally based single keyword file otherwise
>parsing becomes a nightmare. If desired the GUI tool (or vi)
>can be used to modifiy the keyword file. Then if desired the
>various "standard" files could be generated automatically.
Let's look at it this way. The NT and VMS idea of a single central
registry for all system and application configuration parameters is an
EXCELLENT idea. You always know where to find things and ideally you can
integrate a hypertext help system with the single configuration editor tool.
But, as we all know, it complicates backwards compatibility and makes it
hard to build special purpose tools that manipulate the configuration.
In complex networks or anywhere you have a skilled admin working on a
systems, it is usually easier to deal with plain text config files.
The way that everybody can win here is to keep all the plain text config
files and implement the registry system as well. The fundamental concept
of a registry is that there is one program that can manage all
configuration settings. So lets keep that part of the registry system but
build it on top of the existing base of multiple text config files.
The central registry file would be a directory containing multiple plain
text config files, each one of which would define the layout and location
of an existing UNIX config file. This would be something akin to a
Macintosh resource file with definitions of fields, dialog boxes and all
the user interface for managing and editing that particular config file
from a GUI environment as well as the procedure for making the config
take effect since note everything accepts kill -HUP.
Anybody that wishes to ignore the registry system can do so and
everything will operate fine. When that admin moves on a nd a new admin
comes on the job, the registry system will still be ready to use because
it is based on existing files.
I'm not saying this will be easy because there are several interesting
challenges I can see in building such a system such as preserving
comments in config files and especially, what if someone uses vi to
comment out a section of the config? A registry user should be able to
see the comment and should be able to tell the registry to add that
commented section back in at which point the registry program would need
to distinguish commented out entries from real comments....
But if this is done it will go a LONG way to making UNIX palatable to the
masses of barely computer literate admins who are now running much of the
worlds computer and network infrastructure.
--
Michael Dillon Voice: +1-604-546-8022
Memra Software Inc. Fax: +1-604-542-4130
http://www.memra.com E-mail: mic...@memra.com
Dave Duling
If you learned to program on DOS-OS/2-NT, then making system calls in BSD or
SYS V is very awkward and so you think UNIX is hard to program for. You like
the integrated environment. {:-(}
If you learned to program on UNIX, then worrying about stacks, segments, and
heaps is very awkward and you think DOS-OS/2-NT is hard to program for. You
like the command line. {:-)}
(2) Also ....
In article <3vi3cp$j...@nntpd.lkg.dec.com>,
Jon Jenkins <jenk...@ozy.dec.com> wrote:
>dob...@seas.gwu.edu (David O'Brien) wrote:
>>Peter da Silva (pe...@nmti.com) wrote:
>
>...snip more scathing NT remarks.
>..........
>bad points. A good GUI on top of a good
>OS (aka FreeBSD) would make it more popular
>with users. If this is desired then a quick
>easy GUI development toolset would ease the
>porting of the many existing obtuse scripts/files
>and design of new ones by allowing Mr/Mrs/Ms Average
>user to develop GUIs without having to spend the
>next few years learning Xt/Xlib etc. The idea
>is that many hands will make light work and
>the many hands will be there IF there is
>an easy to use GUI based GUI builder.
>
Interesting thread. It seems that BEFORE a group can decide upon a GUI
toolset, it must first decide upon a GUI ! FreeBSD (and Linux for
that matter) run generic X-windows fine, but without Motif there is no
standard for what sliders, buttons, windows... etc... look like or how
they behave. Do you want mouse focus windows or mouse click focus windows ?
Do you want general objects for the GUI pieces or custom objects or
both ? How will these GUI objects be distributed over the network ? Do
you want client-server tools built into the OS+GUI or make them entirely
from libs ? You wouldn't use a Win32 compiler to make an OS/2 program, and
you wouldn't use an OpenLook toolkit to make a Motif program. Well, you
might but ...
One interesting starting point might be to look at the Caldera release.
Could that be ported to FreeBSD ? It would certainly be nice to have
some GUI portability between the two.
>To show you what happens when someone does
>this. Borlands Delphi is an Object based
Im writing C, C++, & FORTRAN on Unix and NT, and frankly, I dont really care
about Delphi at this point ! My life is complicated enough ...
- Dave Dul...@niehs.nih.gov
** Clearly not speaking for the taxpayers ... **
Dave Duling
Im writing C & C++ on Unix and NT, and frankly, I dont really care about
Delphi at this point !
- Dave Dul...@niehs.nih.gov
Jordan K. Hubbard
Dave Duling <dul...@niehs.nih.gov> wrote:
>Interesting thread. It seems that BEFORE a group can decide upon a GUI
>toolset, it must first decide upon a GUI ! FreeBSD (and Linux for
>that matter) run generic X-windows fine, but without Motif there is no
>standard for what sliders, buttons, windows... etc... look like or how
>they behave. Do you want mouse focus windows or mouse click focus windows ?
Well, I think that Tk isn't a bad choice if you're looking for some sort of
"standard" for such things, and I think that having an interpreted language
for GUI development certainly helps when you're at the "fiddling and tweaking"
stage of evolving the interface since doing development on top of the raw Motif
API sucks deceased marmots through thousands of meters of oil-encrusted
Alaska pipeline. If you have something like UIM/X running on top then
at least you're only sucking very small dead gerbils through garden hose
by comparison, but you still need to convince the UIM/X folks to port their
toolkit to FreeBSD and I don't think that's likely to happen anytime real
soon.
So once you start taking all that into account, Tk starts looking better
and better. It's just too bad there's still no reasonable "GUI builder" for
it. I tried working with some of the current offerings and they just made
me too frustrated with their general lack of understanding about what makes
a good GUI builder (use reasonable defaults and don't make the user fill in
a 700 entry property sheet for each object unless they really really want to).
Perhaps, with time, that will change. I know that since John O. went to
Sun they've been funding such an effort and hopefully we'll see it soon.
That'd be cool, though I can't help but wonder how some of their customers
must feel: "Buy Sun and get out GUI of the week! First we told you
that Open/Look was it, but we lied. Then we told you to use Motif instead,
but only as part of CDE which will be out in a usable form Real Soon Now.
As soon as you get used to that, however, we'll ask you to drop it all
and go to our new hyper-Tk interface builder that also interfaces to HotJava!
What do you *mean* you don't trust us now?! Have we ever lied to you??
Well, that is anytime within the last five minutes?"
>both ? How will these GUI objects be distributed over the network ? Do
I don't think that this is a GUI problem. If your underlying application
requires distribution then you distribute the DATA and leave the GUI
visualization local. Only a very insane person would try to send the
GUI calls across the network. Well, not if you don't count X, anyway.
>you want client-server tools built into the OS+GUI or make them entirely
>from libs ? You wouldn't use a Win32 compiler to make an OS/2 program, and
Yeesh! I don't think we need to put client-server tools into the OS.
Plenty of room for them up above, with whatever CORBA compliant library
you've standardised on. There's always ORBIX.
>One interesting starting point might be to look at the Caldera release.
>Could that be ported to FreeBSD ? It would certainly be nice to have
>some GUI portability between the two.
I don't think Caldera tries to be a GUI standard so much as a simple
*desktop* standard and I certainly agree that we could use one of those.
I'm still waiting for someone to send me a URL pointing at the code,
of course.. :)
Jordan
Ruslan Belkin
> In article <3vi3cp$j...@nntpd.lkg.dec.com>,
> Jon Jenkins <jenk...@ozy.dec.com> wrote:
> >dob...@seas.gwu.edu (David O'Brien) wrote:
> >>Peter da Silva (pe...@nmti.com) wrote:
> >
> >...snip more scathing NT remarks.
> >..........
> >bad points. A good GUI on top of a good
> >OS (aka FreeBSD) would make it more popular
> >with users. If this is desired then a quick
> >easy GUI development toolset would ease the
> >porting of the many existing obtuse scripts/files
> >and design of new ones by allowing Mr/Mrs/Ms Average
> >user to develop GUIs without having to spend the
> >next few years learning Xt/Xlib etc. The idea
> >is that many hands will make light work and
> >the many hands will be there IF there is
> >an easy to use GUI based GUI builder.
> >
> Interesting thread. It seems that BEFORE a group can decide upon a GUI
> toolset, it must first decide upon a GUI ! FreeBSD (and Linux for
I think, that providing some pre-configured, plug-and-play XFree distribution
(instead of fresh one) even with fvwm, xfm and with BSD-daemon logo will
simple and good start for bringing FreeBSD to Windoze-nized user.
> - Dave Dul...@niehs.nih.gov
> ** Clearly not speaking for the taxpayers ... **
--
Ruslan Belkin
at CS/MONOLIT Network Centre (r...@UA.net)
Thomas Graichen
: I think, that providing some pre-configured, plug-and-play XFree distribution
: (instead of fresh one) even with fvwm, xfm and with BSD-daemon logo will
: simple and good start for bringing FreeBSD to Windoze-nized user.
... but i think the "clean" XFree86 binary tree should also be available -
because not all FreeBSD users are "Windoze-nized" and have their own .fvwmrc
and thus don't need the overhead you may get from all that - but this as an
_option_ is a good idea i think
one point for my switch from linux to FreeBSD was it's relatively clear
filesystemheirarchy - a _real_ /usr/local not that /usr/bin & /usr/local mix
from for instance slackware which made it very hard to maintain the same local
binaries for different platforms (here /usr/local ther /usr etc.) - thus i
think the basic tree should stay relatively small and "clean" in this way -
such a setup as package i _may_ install is ok
by the way - i think it would be a good idea to rethink the placement of all
the X-ports-binaries - i think all stuff not directly related to the basic
distribution (for instance fvwm etc.) belongs more into /usr/local than into
/usr/X11R6 - because this way it is much easier to upgrade XFree86 - maybe
someone else have another opinion
t
_______________________________________________________||_____________________
__||
Perfection is reached, not when there is no __|| thomas graichen
longer anything to add, but when there __|| freie universitaet berlin
is no longer anything to take away __|| fachbereich physik
__||
- Antoine de Saint-Exupery - __||
___________________________||____email: grai...@omega.physik.fu-berlin.de____
J Wunsch
>If you learned to program on DOS-OS/2-NT, then making system calls in BSD or
>SYS V is very awkward and so you think UNIX is hard to program for. You like
>the integrated environment. {:-(}
Hmm, do you think setting up something like
int
sysfoo(const char *foo)
{
struct reg r;
r.r_ax = 0x33;
r.r_cx = strlen(foo);
r.r_dx = foo;
int21(&r);
return r.r_ax;
}
is less awkward than
int
sysfoo(const char *foo)
{
return write(2, (void *)foo, strlen(foo)) >= 0;
}
??? :-)
Andreas Klemm
: ta...@gate.sinica.edu.tw (Brian Tao) wrote:
: ] Well, what say you to a GUI-based kernel configuration utility?
: Yes... drag and drop loading of kernel modules by placing them
: in a "System" folder.
Yes ... and an additional test menue ;-)
--
and...@wup.de /\/\___ Wiechers & Partner Datentechnik GmbH
Andreas Klemm ___/\/\/ - Support Unix -
Andreas Klemm
: In article <40gf8q$d...@hamlet.m-u-b.de>, Toni Mueller <sup...@m-u-b.de> wrote:
: >I don't mind having these, but the system must remain completely configurable
: >with no more than /bin/vi, IMHO (and cc and such, for that matter).
: >
: >I think it's a _really bad idea_ to throw these out and require running a GUI
: >to configure the system.
: I'm sorry if it was ever implied that we would. Don't forget, we also
: intend to have this beast install/configure easily from a _serial console_,
: so we're not going to go so hog-wild with GUI front-ends that this becomes
: impossible. We'd only be shooting our own goals in the feet.
Supposing, that only an experienced person will do a serial console
installation I think it would be smarter to concentrate efforts to
people, who are installing from a PC Console.
Jon Jenkins
some very intelligent comments.
I suppose the question that arises next is:
do we (I, me you, others...) decide to "roll our own"
GUI builder (probably done in Tk) which will generate
Tk scripts or do we wait to see what will happen with
the Sun/Java stuff ?
Jon Jenkins
>j...@violet.berkeley.edu (Jordan K. Hubbard) wrote:
>
>some very intelligent comments.
>
>I suppose the question that arises next is:
>
>do we (I, me you, others...) decide to "roll our own"
>GUI builder (probably done in Tk) which will generate
>Tk scripts or do we wait to see what will happen with
>the Sun/Java stuff ?
PS
Ive still got a sweet spot for an HTML engine
based GUI. It is a standard and there are some
spiffy tools for developing "interfaces" in HTML
around.
J Wunsch
>by the way - i think it would be a good idea to rethink the placement of all
>the X-ports-binaries - i think all stuff not directly related to the basic
>distribution (for instance fvwm etc.) belongs more into /usr/local than into
>/usr/X11R6 - because this way it is much easier to upgrade XFree86 - maybe
>someone else have another opinion
The main problem here is that the official Imakefile templates do not
provide for a differentiation between `system' and `user' application
directories. That would require all ports to modify their Imakefiles,
not a very enlightening idea...