Linux-Advocacy Digest #605, Volume #25 Sun, 12 Mar 00 20:13:06 EST
Contents:
Re: Giving up on NT (Bob shows his lack of knowledge yet again) ("Chad Myers")
Re: In the middle of it all... ("Mark Weaver")
Re: Kernels (Was: Re: BSD & Linux) (Emmanuel Dreyfus)
Re: Giving up on NT (Jack Troughton)
Re: What might really help Linux (a developer's perspective) (Robert Morelli)
Re: What might really help Linux (a developer's perspective) (Robert Morelli)
Re: A Linux server atop Mach? ("Charles W. Swiger")
----------------------------------------------------------------------------
From: "Chad Myers" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.ms-windows.nt.advocacy,comp.os.os2.advocacy,comp.sys.mac.advocacy
Subject: Re: Giving up on NT (Bob shows his lack of knowledge yet again)
Date: Sun, 12 Mar 2000 21:57:25 GMT
"Jason Bowen" <[EMAIL PROTECTED]> wrote in message
news:8agv29$dgm$[EMAIL PROTECTED]...
> In article <38cba2e0$2$obot$[EMAIL PROTECTED]>,
> Bob Germer <[EMAIL PROTECTED]> wrote:
> >On 03/11/2000 at 11:41 PM,
> > Dave <[EMAIL PROTECTED]> said:
> >
> >
> >> That's why the Linux/Win98SE dual boot box has only 64 meg - it's an
> >> Intel 430TX chipset MB. It will take more ram but only caches 64 meg.
> Unless you are a complete fucking idiot that likes to show that he doesn't
> know dick.
Hey, ease up on Bob a little, please. The only reason we even acknowledge
his posts is because it makes him feel special because his therapist told
us to help him out a little.
Remember, nod and smile, nod and smile. A pat on the head once in awhile
couldn't hurt either.
Just like you can't get mad at your dog making a mess on the floor, you
also shouldn't get mad at Bob for being clueless.
Just a helpful reminder!
-Chad
------------------------------
From: "Mark Weaver" <[EMAIL PROTECTED]>
Subject: Re: In the middle of it all...
Date: Sun, 12 Mar 2000 22:51:04 GMT
We recently wrote a TCP-based client-server app with Win32 clients and
NT/Linux/Solaris versions of the server. The NT version of the server runs
as a service or a GUI, the *nix version as a daemon or CLI app. It's 99%
the *same* damn code with some macros and classes to resolve differences in
threads, semaphores, directory searching and a couple of other areas I can't
recall at the moment. The socket code is virtually identical. Initial
development was on NT and the *nix port took a couple of weeks (to develop
the x-platform macros & classes). I have a hard time seeing that should
make much difference which OS you pick as your first target--if you do
things right, you ought to be able to support NT and Linux with essentially
the same source.
Mark
------------------------------
From: [EMAIL PROTECTED] (Emmanuel Dreyfus)
Crossposted-To:
comp.unix.bsd.386bsd.misc,comp.unix.bsd.freebsd.misc,comp.unix.bsd.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.openbsd.misc
Subject: Re: Kernels (Was: Re: BSD & Linux)
Date: Mon, 13 Mar 2000 00:11:19 +0100
Donn Miller <[EMAIL PROTECTED]> wrote:
> An aside - what kind of kernel config utility do you think Microsoft
> used to configure the Windows 2000 kernel, huh?
I beleive winNT and win2k use a microkernel. Therefore, the
configuration of the kernel should be quite simple, and it can be used
nearly forever. To add a driver, they just have to add a service, which
is outside the kernel.
This is a great design, but speaking of Windows, it must be poorly
programmed since it is not famous for stability.
> I'll bet Winvocates
> didn't even know Windows had a kernel. Winvocates would die if they
> went into a room of Windows developers and saw them configuring the
> W2K kernel. "What????!!?? Windows has a kernel???!!?? They have to
> configure and compile a kernel?????!!!!?? *Thunk!*"
Well... It seems some UNIX persons really like to recompile kernels. I
don't. I got a very old machine and it takes me a whole night. Most of
the time, it's for a security fix. Sometime, I would really appreciate
binary patches for a UNIX kernel.
--
Emmanuel Dreyfus
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Jack Troughton)
Crossposted-To:
comp.os.os2.advocacy,comp.sys.mac.advocacy,comp.os.ms-windows.nt.advocacy
Subject: Re: Giving up on NT
Date: Sun, 12 Mar 2000 23:24:09 GMT
On Sat, 11 Mar 2000 20:09:53, [EMAIL PROTECTED] (Bob Hauck)
wrote:
>On 10 Mar 2000 22:04:07 -0600, Dave <[EMAIL PROTECTED]> wrote:
>
>>BTW, check comp.os.os2.setup.misc for the rundown of my trials and
>>tribulations installing OS/2 4 on an IBM Thinkpad 600E laptop. At
>>least the people there are friendly and willing to help.
>
>Uh, sir, you *are* posting to a bunch of advocacy groups here. If you
>want informed, friendly, people who are willing to help you are in the
>wrong place I'm afraid.
>
>There are comp.os.linux.{misc, setup} groups.
Hi Bob!
Wow, I haven't heard from you in a long time. What are you running
these days?
--
==========================================================
* Jack Troughton jake at jakesplace.dhs.org *
* http://jakesplace.dhs.org ftp://jakesplace.dhs.org *
* Montr�al PQ Canada news://jakesplace.dhs.org *
==========================================================
------------------------------
Date: Sun, 12 Mar 2000 17:20:08 -0500
From: Robert Morelli <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: What might really help Linux (a developer's perspective)
mlw wrote:
>
> Robert Morelli wrote:
> >
> > mlw wrote:
> > >
> > > Robert Morelli wrote:
> > > >
> > > > Davorin Mestric wrote:
> > > > >
> > > > > this will never happen, because the linux community already perceives
> > > > > that linux is the best development platform. this is off course far
> > > > > from the truth, but truth is not important. what is important is what
> > > > > people think, not what actually is. so, there would be no push to
> > > > > improve something which is already 'best'.
> > > > >
> > > >
> > > > Sadly, I must agree with this assessment, at least as regards old
> > > > timers.
> > > > I see two big contributing factors.
> > <snip>
> > > > 2. A distorted sense of what powerful software is. At the time UNIX
> > > > came into
> > > > being, in the 1970's, people had just understood compiler principles
> > > > and finite
> > > > state machines, etc., and that seemed hot. In retrospect, to most
> > > > people on
> > > > non-UNIX platforms, that stuff now seems simple minded compared to
> > > > things like
> > > > GUI design, which requires art, creativity, and also more advanced
> > > > software
> > > > concepts. But as ridiculous as it may seem, I think that to the
> > > > average UNIX
> > > > afficionado parsing still seems hot, and piping together programs with
> > > > many
> > > > command line switches seems fancy and powerful, and the expertise of
> > > > the kernel
> > > > hacker is exalted far above the level of the goofball who invents
> > > > something like
> > > > a toolbar, a hypertext help system, or an IDE. Unfortunately, a
> > > > contributing
> > > > factor was the fact that the modern GUI was first popularized on the
> > > > Mac, a
> > > > platform with brain dead multitasking and networking support. This
> > > > invited
> > > > people without insight to also dismiss the GUI as brain dead by
> > > > association.
> > >
> > > You know, this is a huge philosophical argument, that is largely wasted
> > > on end users, but important for software development. Under Windows the
> > > command:
> > >
> > > "something | sort > file.txt" is a very expensive procedure. Under UNIX,
> > > "something | sort > file.txt" is very efficient. UNIX was designed with
> > > the notion that multiple programs can and should as one. Windows (and
> > > DOS) were designed thinking that a program stands alone, while this was
> > > because DOS was a monotasking environment, the metaphor stuck.
> > >
> > > Under UNIX there is no real reason to put everything into one program,
> > > in fact, it is a bad idea. Does that mean that one does not have nice
> > > GUI applications? No. It means that, with the exception of WYSIWYG
> > > editing, applications that consist largely of dialog boxes and text
> > > entry fields, it makes sense to have a text program do the actual
> > > processing of the data, while some GUI toolkit acquires the data and
> > > issues the command to process. This is actually no different than using
> > > VB for dialogs with a .DLL under Windows, except that you can test the
> > > components on the command line. (Which, the end use may never do, but as
> > > a developer, I can test the hell out of it!)
> > >
> > > This sort of metaphor is hard to do well in Windows because the child
> > > process management tools are not in place. Just because one can't do it
> > > under Windows does not mean it is bad, and I reiterate, the reason one
> > > can't do it under Windows is because Windows is based on a programming
> > > model that is very very primitive. NT is a bit better, but if one writes
> > > an application for "Windows" it is very hard to justify targeting only
> > > NT.
> > >
> > > Under Windows the closest analogy is VisualC++. You have a nice WYSIWYG
> > > text editor, but have a text based program actually do the compiling.
> > > cl, nmake, etc. are command line utilities. This is, in fact, a very
> > > UNIX model of doing things. It should be noted, doing this sort of thing
> > > in Windows is difficult to do, under UNIX, one simply issues "popen" and
> > > reads a file.
> >
> > You aren't really addressing the point I was trying to make. I don't dispute
> > the value of good command line support and piping etc. If it's a choice between
> > a pleasant looking GUI, and getting a job done, I prefer to get the job done.
>
> Absolutely, get the job done, but using command line apps behind a GUI
> front end is a very efficient and stable way to do something under UNIX.
>
> > In fact, I consider it mind boggling that no Microsoft OS was ever released
> > with integrated scripting support beyond the DOS batch language. (I think NT 4.0
> > has some kind of a scripting language, but still not seriously supported. Of
>course,
> > there have always been ports of perl, etc., but the system never included
> > the support to make them practical as scripting languages for applications ...)
> > By the same token, I don't praise Apple for weak networking support and
> > cooperative multitasking. Mac and Windows are brain dead systems in numerous ways,
> > and I don't use them for much.
>
> Windows does not lack scripting languages, it lacks the infrastructure
> to make scripting a viable alternative to coding whole applications.
>
> >
> > My point is that a good OS should embrace not only the older basic technologies
>like
> > command line support, but also the more advanced technological innovations like
>the
> > modern GUI paradigm and the component object model.
>
> The UNIX way of reusing small programs that do one thing in a testable
> and deterministic way is far more advanced than Windows "shove
> everything into one app because we can run't more than one" attitude.
>
> The command line is just one interface to a very powerful development
> paradigm. GUI development environments like Tcl/Tk can use the command
> line programs just as easily as VB would use a .DLL. Except with a
> command line utility providing the horse power behind the GUI
> environment, you can regression test bugs, automate testing, etc. A lot
> easier.
>
> > If you ask a typical UNIX bigot
>
> I take offense to "UNIX bigot"
If you read everything I write, I think you'll realize that I don't condemn UNIX or
its
advocates wholesale. I am generally favorable to UNIX and its users, gurus, etc.,
but I give no one an uncritical nod. I condemn a particular attitude which the word
"bigot"
captures appropriately. If you use UNIX but aren't a bigot, the term doesn't apply
to you so
you have no reason to take offense, unless you ally yourself with every UNIX user.
> > why
> > you can't load a file into Emacs by dragging a file object onto the Emacs window,
>he'll
> > smugly answer that UNIX people wouldn't use such a capability even if it were
>there. These
> > people are actually proud of their insularity and lack of sophistication.
>
> Judging everyone that uses UNIX by one person being flip is stupid.
I'm not sure why you assume that I base this statement on a single experience. I work
at a university, where UNIX is quite common. In any case, the important question
here
is, if this is not a typical attitude then why in fact doesn't Emacs have the
capability
I mention and why aren't UNIX users angrily demanding it? For that matter, why did it
take 19 major iterations (that's right, 19, no typo) before it got scroll bars?
> >
> > Mind you, I'm no Windows advocate. But I'll at least give Microsoft credit for
>one thing.
> > In their own bumbling, incompetent way, they have been gradually -- very, very
>gradually --
> > adopted paradigms from other systems (of course, always implementing them in a
>half assed
> > way). Their philosophy is one of extreme conservatism in that they never
>introduce anything
> > original and have no vision of going beyond existing paradigms. But neither do
>they limit
> > themselves by bigotry. I have some sympathy for Apple, because even though the
>Mac is weak in
> > many respects, the company did have vision. They introduced the Newton about a
>year before MS
> > cancelled its first incarnation of the WinCE API (called WinPad). And in the late
>80's they
> > conceived of Pink (aka Taligent) that would go beyond anything then (or now) in
>existence.
> > Unfortunately, Pink was an expensive failure. As a fall back, they have now
>adopted a UNIX
> > foundation for future versions of their OS. That's not too exciting a vision,
>but it does
> > solve the immediate problem of getting decent multitasking.
> >
> > As for UNIX, I have to say that there has been a general complacency to remain
>with very,
> > very good implentations of a 1970's computing paradigm. UNIX still thrives
>because for
> > many purposes a very good implementation of simple, old fashioned ideas is
>superior to a weak
> > implementation of something more sophisticated. I do find it a bit of a depressing
> > philosophy though and in some cases deeply frustrating.
>
> Anyone that thinks "old fashioned" has any place in UNIX has not been
> paying attention. The issue is reason. Make a good case for different
> metaphors and paradigms and they will be implemented and introduce into
> standards before Microsoft's first rip-off.
>
> Many of the things that pass as programming paradigms in Windows are
> simply bad ideas. To adopt them simply because they are new would be
> foolish. Does this mean that things are rejected out of hand? Of course
> not, but if it is a bad idea, it shouldn't happen.
Well, there you go. That's the kind of dismissive, insular attitude I'm talking
about.
Back in the 80's DOS users used to talk about mice and screen graphics as useless,
frivolous,
... It was a combination of ignorance and envy. You don't mention anything specific
as a "bad
idea," so let's stick with the drag and drop example. What is so bad about drag and
drop?
> > But, fortunately I don't think that's really the end of the story. There is a
>new energy
> > among the younger developers of Linux and the traditional UNIX sense of community
>still
> > prevails. I believe that open, vigorous communities are ultimately more creative
>and
> > productive than closed systems. For this reason I expect Linux to break free of
>the depressing
> > legacy of complacency and I see it as the most promising system for the future.
>
> I think you don't see what is happening. UNIX and thus Linux are not
> "old and stodgy" by any measure. It ain't Windows, no way, but some fun
> and exciting stuff is happening. Good GUI apps are coming, and many of
> the GUI apps in Linux are better than the run of the mill Windows apps.
> I will grant you the $100 Billion dollar software company apps are not
> on Linux, yet, but Linux has better implementations for the $100 Million
> dollar software company apps.
You say that I don't see what is happening, but then go on to reinforce what I just
said. Good GUI apps are on the way (but mostly not yet here) because there is a
shift to a more modern attitude. The original question was whether there will be
development tools for Linux of the same quality (or better (!)) as the leading Windows
development tools. I don't know, but it does look promising. Borland for instance
has always been known for first class tools and they have JBuilder on Linux and are
porting
C++ Builder. It remains to be seen whether these tools really stand up to their
Windows
counterparts, and whether the Linux market supports their continued development. This
last point is not just a question of market size; it leads us back to the attitude
issue.
I expect the traditional UNIX folks won't flock to C++ Builder. They'll go on happily
using gcc and Emacs. But if Linux does grow, there will be lots of Windows refugees
who will require something providing the modern conveniences of their old home.
------------------------------
Date: Sun, 12 Mar 2000 17:32:57 -0500
From: Robert Morelli <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: What might really help Linux (a developer's perspective)
Craig Kelley wrote:
>
> Robert Morelli <[EMAIL PROTECTED]> writes:
>
> > My point is that a good OS should embrace not only the older basic
> > technologies like command line support, but also the more advanced
> > technological innovations like the modern GUI paradigm and the
> > component object model. If you ask a typical UNIX bigot why you
> > can't load a file into Emacs by dragging a file object onto the
> > Emacs window, he'll smugly answer that UNIX people wouldn't use such
> > a capability even if it were there. These people are actually proud
> > of their insularity and lack of sophistication.
>
> Just so you know, I can drag files onto emacs using GNOME. ;)
>
> We're getting there. In order to do without all the baggage that
> Windows carries, we have to re-implement a LOT of components.
Eureka! I don't have time to download every daily build, so I suppose I haven't
installed a recent enough version. When did this capability appear?
> > Mind you, I'm no Windows advocate. But I'll at least give Microsoft
> > credit for one thing. In their own bumbling, incompetent way, they
> > have been gradually -- very, very gradually -- adopted paradigms
> > from other systems (of course, always implementing them in a half
> > assed way). Their philosophy is one of extreme conservatism in that
> > they never introduce anything original and have no vision of going
> > beyond existing paradigms. But neither do they limit themselves by
> > bigotry. I have some sympathy for Apple, because even though the
> > Mac is weak in many respects, the company did have vision. They
> > introduced the Newton about a year before MS cancelled its first
> > incarnation of the WinCE API (called WinPad). And in the late 80's
> > they conceived of Pink (aka Taligent) that would go beyond anything
> > then (or now) in existence. Unfortunately, Pink was an expensive
> > failure. As a fall back, they have now adopted a UNIX foundation
> > for future versions of their OS. That's not too exciting a vision,
> > but it does solve the immediate problem of getting decent
> > multitasking.
>
> Under MacOSX, UNIX is a very small part of the story. The exciting
> (visionary, if you will) components are above the UNIX kernel and
> userland tools. See these articles for more information:
>
> http://arstechnica.com/reviews/1q00/macos-x-dp3/macos-x-dp3-1.html
>
> > As for UNIX, I have to say that there has been a general complacency
> > to remain with very, very good implentations of a 1970's computing
> > paradigm. UNIX still thrives because for many purposes a very good
> > implementation of simple, old fashioned ideas is superior to a weak
> > implementation of something more sophisticated. I do find it a bit
> > of a depressing philosophy though and in some cases deeply
> > frustrating.
>
> I disagree. UNIX is a great foundation. It is flexible enough to
> give the power and reliability without sacrificing innovation. I
> don't see it as old technology, because the UNIX of 2000 has little
> resemblence to the UNIX of 10, 20 and 30 years ago.
>
> > But, fortunately I don't think that's really the end of the story.
> > There is a new energy among the younger developers of Linux and the
> > traditional UNIX sense of community still prevails. I believe that
> > open, vigorous communities are ultimately more creative and
> > productive than closed systems. For this reason I expect Linux to
> > break free of the depressing legacy of complacency and I see it as
> > the most promising system for the future.
>
> Yep.
>
> I just wish that Microsoft would opensource Windows 2000. It would be
> a dream to tinker with some of the warts on this otherwise nice
> operating system.
I disagree. I don't want Windows open sourced because open sourcing it would
guarantee that it would survive (in one form or another) and I don't want that.
(I also strongly oppose the idea of open sourcing as an antitrust remedy.) The
DOS-think legacy issues around Windows are much worse than anything in UNIX
and I expect the (gigantic) sourcecode base reflects that. What I favor is
simply importing the best ideas into Linux in fresh, lean, modern
implementations, and letting Windows itself die. The only misgiving I have is
that one way or another Windows will probably cease to be so dominant within 5
years. At that point, who's going to light a fire under Linux developers asses?
------------------------------
From: "Charles W. Swiger" <[EMAIL PROTECTED]>
Subject: Re: A Linux server atop Mach?
Crossposted-To: comp.sys.next.advocacy
Date: Mon, 13 Mar 2000 00:30:03 GMT
Aaron J Reichow <[EMAIL PROTECTED]> wrote:
> There are a number of people who argue that the Linux kernel, and not
> Mach, should be the heart of OS X, often because of reasons of
> portability.
That's an interesting proposition. Let me approach it by thinking about this
at the various layers.
GUI apps
========
MacOS provides support for running Mac software as well as things like
VirtualPC and the Connectix PlayStation emulator; Linux lets you run X11-based
GUI apps (both native and binaries from related platforms like FreeBSD) as
well as limited PC emulation.
To an end-user, portability means "can I exchange documents with my clients or
with my officemates" and "can I run the programs I want to use". Obviously
the existing Mach-kernel based MOSXS or MacOS X developer previews which let
people run MS-Office, IE, the Adobe suite and so forth (*); as well as Mac
games (**) has got better portability than a Linux kernel which did not host
Mac platform apps.
Of course, Apple could do the work to make Linux provide the Carbon API's and
Toolbox support but this would be a company-critical multiyear development
project which would probably add two years to when Apple can ship a new OS.
(*): If you happen to be a frothing-at-the-mouth Linux zealot, yes, Adobe
offers Acrobat for Linux and FrameMaker is in beta, but most of the Adobe
suite is not available for Linux. Sorry, StarOffice just doesn't cut the
mustard if you actually exchange documents with other people. Some people
need IE to do their jobs, certainly anyone creating web content. Finally,
let's note that you can run X on top of Mach (and the MacOS), which means that
if anyone can think of a GUI Linux app which does not already exist in better
form for the Mac, how hard would it be to port it (if a port hasn't already
been done, too)!
(**): And the above goes twice for games. I mean, you have to look pretty far
to find a traditional Unix game like NetHack, Rogue, or Angband...or GUI ones
like xmille and xconq...which do not have a Mac version.
Server apps
===========
For the most part, this is a wash-- both platforms can run Apache, an FTP
server, mail, POP/IMAP, ssh, NFS/SMB/AppleShare filesharing, print sharing,
and so forth.
Linux does have a noticable advantage in databases with Oracle and Sybase
ports; it will be interesting to see whether either company adds MOSXS or X to
the platforms their databases run on.
( I suppose Mach + MacOS X has better Apple-specific support for things like
AppleTalk, but what Linux has [ie, CAP, netatalk+sun, and so forth] works
fine. )
Unix/CLI
========
Again, this layer is mostly a wash. Pretty much the entire GNU suite is at
the "./configure ; make install" level of compatibility. Ditto for all of the
common tools like BIND, sendmail, Apache, Perl, and so forth. From
Darwin-development and from individual ChangeLogs, we've seen that Apple is
actively supporting GNU autoconf and providing configuration feedback to make
sure packages and build easily. Much credit for this (and many thanks)
to Wilfredo Sanchez.
It's worth noting that there are some exceptions, and you may have to do some
porting work sometimes. One area where Linux is doing much better is in the
packet filtering, NAT, PPP, and related technologies-- the Linux Router
Project is a good example.
Kernel
======
Linux has got more extensive driver availability (particularly given the
status of Darwin for Intel) and more loadable kernel modules around for it.
It will be interesting to see how compatible Apple's new driver layer it and
how easy it is to port open source drivers.
> Is it not quite possibly to implement a Linux atop Mach in a way like a
> BSD server was implemented? Or in a way that a Linux server is running
> on top of Mach in MkLinux? Is this Linux server that comes with the
> MkLinux distro open source?
The Mach personality support is intended to allow Mach to run programs which
have very different kernel interfaces and process semantics. The BSD 4.4Lite
API over Mach is so close to the API hosted off Linux that I doubt many
people can actually name a single system call or standard library function
which differs between the two.
[ About the only significant chunk is SysV shared memory, and there is already
a freely available portability layer, as well as commercial product, which
translates shm stuff into Mach messages. ]
-Chuck
Chuck 'Sisyphus' Swiger | [EMAIL PROTECTED] | Bad cop! No Donut.
------------------------+-------------------+--------------------
I know that you are an optimist if you think I am a pessimist....
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.advocacy) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Advocacy Digest
******************************
