Linux-Advocacy Digest #999, Volume #26 Fri, 9 Jun 00 20:13:04 EDT
Contents:
Re: Would a M$ Voluntary Split Save It? (Marty)
Re: Canada invites Microsoft north (abraxas)
Re: Would a M$ Voluntary Split Save It? ("Daniel Johnson")
----------------------------------------------------------------------------
From: Marty <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.os2.advocacy,comp.os.ms-windows.nt.advocacy,comp.sys.mac.advocacy
Subject: Re: Would a M$ Voluntary Split Save It?
Date: Fri, 09 Jun 2000 23:38:48 GMT
JEDIDIAH wrote:
>
> On Fri, 09 Jun 2000 04:26:46 GMT, Marty <[EMAIL PROTECTED]> wrote:
> >JEDIDIAH wrote:
> >>
> >> On Fri, 09 Jun 2000 01:53:00 GMT, Marty <[EMAIL PROTECTED]> wrote:
> >> >JEDIDIAH wrote:
> >> >>
> >> >> On Thu, 08 Jun 2000 23:36:56 GMT, Marty <[EMAIL PROTECTED]> wrote:
> >> >> >JEDIDIAH wrote:
> >> >> >>
> >> >> >> On Thu, 08 Jun 2000 13:32:28 GMT, Marty <[EMAIL PROTECTED]> wrote:
> >> >> >> >Leslie Mikesell wrote:
> >> >> >> >>
> >> >> >> >> In article <[EMAIL PROTECTED]>, Marty <[EMAIL PROTECTED]>
>wrote:
> >> [deletia]
> [deletia]
> >> >for me? We're discussing the tradeoffs between app interoperability and
> >> >system interoperability, remember?
> >>
> >> "interoperability" as you define it is somewhat meaningless.
> >> Passing off some imbedded binary data to another application
> >> and making it look like it's all integrated is slight of hand
> >> not "interoperability".
> >
> >You just don't get it, do you? There are no streams of data flying around
> >under the hood to make this happen. Not a single part of the app is even
>
> Well there has to be.
You're not familiar with the WPS programming paradigm.
> How else is the Monpolysoft component going
> do your "interoperability".
Who's talking about "Monopolysoft"?
> Data has to come from somewhere and data has to go to somewhere.
The data routing is no different than that of any other PM application. The
pertinent VoiceType code is embedded in the shell, modifying how normal PM
messages are sent to normal PM apps.
The data path is simply:
PMSHELL -> Application
Not:
PMSHELL -> "VoiceType daemon" -> Application's special library with hooks ->
Application
and PMSHELL -> Application
If you fail to see the power and elegance of this solution, then there's
nothing more I can do.
> It doesn't matter if it's DDE, the
> GEM message queue, an IP socket or a file.
But it *does* matter if it's a WPS class.
> >aware that anything is happening. I guess you're just not going to understand
> >it clearly until you've used the workplace shell of OS/2. There's no slight
> >of hand involved. It's an extremely elegant and OO solution, which guarantees
> >future interoperability. You just can't find solutions like that on Unix
> >based platforms.
>
> You really have to be a bit more detailed then this bit of rhetoric
> and marketing. It really doesn't tell anyone why we should believe you
> or think that OS/2 is anything special.
I've already explained the elegance of it. VoiceType, like any WPS
application, is guaranteed to work with any OS/2 application without the
application even being aware of its existence. It extends the capabilities of
the shell itself, inheriting the functionality that was already there and
adding to it. Nobody has to write their applications to support VoiceType.
Nobody has to link it with a special library (or one of the subsets of
libraries it supports). Nobody has to test their code with VoiceType to make
sure they didn't break it. Nobody has to worry about whether or not all the
appropriate servers and clients are installed to use it (or not). It's either
there and working, or it isn't there and nobody is the wiser. That is an
extremely elegant solution; no marketing or rhetoric involved. This is the
type of solution showing the major benefits of interoperability between
applications. I've traded off the ability to export the display of my desktop
to another machine for the ability to use powerful and useful applications
like VoiceType. As a home user, that's just great in my book! Why do I care
if I can bring up my desktop on somebody else's machine as a home user?
> >> This is doubly so given the WinDOS cultural bias against
> >> the individual choice when it comes to such tools.
> >
> >You seem to think I'm in favor of Windows and monopolies. I'm absolutely
> >not. I'll say it again: given the choice between interoperability between
> >systems and interoperability between applications on a given system, it is far
> >more beneficial for a home user to have the latter. Would I like to have both
>
> ...except the sort of "interoperabilty" you seem to be advocating
> is the interoperability that only comes from running the predominant
> vendor's product in a crafty way.
Not at all. Applications are perfectly capable of working well with one
another regardless of who provides them.
> The line you draw between one
> physical machine and another is quite an artificial one. There's
> contraining processes to one machine. Quite often the same
> communications methods can be used both locally and remotely.
So how come there is no analogous solution to VoiceType available for X?
> >kinds of interoperability? Sure! Does such a solution exist today? Not that
> >I know of. OS/2 is about as close as I've found to a useful balance between
> >the two.
> >
> >> [deletia]
> >> >> >> There are already versions to handle the 3 most widely used
> >> >> >> toolkits. So, in the worst case you would need a deamon for
> >> >> >> each toolkit you're running.
> >> >> >
> >> >> >Yuck. How does the user know which toolkit is deployed for which app? And
> >> >>
> >> >> Just check what it's linked against. This is also handy for
> >> >> automagically distinguishing between console and X apps.
> >> >
> >> >That's just what a home user wants to be bothered doing.
> >>
> >> ...and just what makes you think the end user would have to be
> >> bothered with the mechanics of this? The tools are there, the
> >> automation facilities are there, the programers are there.
> >>
> >> However, these facilities are stil available to "those that
> >> don't want them" should they prove useful to them or someone
> >> else who may be providing "free tech support" for them.
> >
> >So I suppose this software will just install itself on all the boxes that need
> >it, and fire off the daemons where needed, and modify the startup scripts
> >where needed? I highly doubt it. That also assumes the user performing the
>
> That's nothing more than the same problem that comes about with
> the arrival of any new application or interface. The only way
> you're going to avoid that sort of situation is to have a stagnant
> system. It can be stagnant for a few months, or for years.
When I wish to add a new WPS class to my system, there's no need to wait for
applications to start supporting it at all. I install the software and it's
there for every application to take advantage of. Why should I wait
needlessly for everyone to get their acts together and then have to worry
about whether or not they interpreted the specifications correctly? As a home
user, that doesn't appeal to me as an elegant solution.
> >installation has sufficient priviledge to accomplish said tasks. And this
> >solution still fails to work with all applications. It will not work with
> >statically linked apps which were linked with older versions of the widget
>
> True. OTOH, you could put the facility that you are talking about
> in the library itself or at least modify the toolkit in question
> to be aware of it. Commonly defined protocols are useful in this
> regard.
>
> Thus, Netscape can interact with GNOME Desktop as another gnome
> application would. Fully open standards make this possible.
But then you lose support for older applications which don't make use of these
newer libraries and hooks. Your proposed solutions really can't hold a candle
to the Workplace Shell in terms of application interoperability.
> >library without the needed hooks, and it will not work with apps the use
> >unsupported widget libraries. That's very poor interoperability.
> >
> >> >> >when a new whiz-bang widget library comes along, you no longer have voice
> >> >> >control support with the apps that use it.
> >> >>
> >> >> What makes you think that would be the most relevant compatibility
> >> >> issue? Although, as long as there are common protocols that can be
> >> >> conformed to it should never be a problem.
> >> >
> >> >It breaks and needs to be fixed with each update. That's not interoperability
> >>
> >> That sounds more like a damnation of MS Office style applications
> >> and OLE rather than anything Linux/Unix related.
> >
> >That's a gaping hole in your proposed solution.
>
> That's a version control problem in general. It's not merely
> limited to Linux. It's a side effect of not being so arrogant
> that you think you don't need to push your infastructure
> further anymore.
The functionality of the PMSHELL in OS/2 can continually be expanded by way of
WPS classes without this "version control" problem. Full compatibility with
applications is *always* maintained and functionality is enhanced in the
process.
> >> >in my book. VoiceType works with any OS/2 PM application. Period.
> >> >
> >> >On a side issue, where are these magical daemons going to be run? If they're
> >> >run on your box, they can affect your X session. But in order to affect the X
> >>
> >> That's rather the point now isn't it? (much like something such
> >> as Plugin or efx).
> >
> >Your aim was to point out how this could be used to show system
> >interoperability, was it not? I stated that a solution such as VoiceType
> >could only be implemented effectively on one box, showing the value of
> >application interoperability, and you challenged that statement.
>
> Network desktops can already be effectively implemented across
> machines. I do that on a daily basis with X as do others here.
You have yet to come up with feasible a way in which an application such as
VoiceType could function remotely, maintaining full compatibility with all
apps, past, present, and future.
> >> >sessions of remote machines, it'd have to be running there as well (because
> >> >the application itself is executing remotely and it's pulling from the widget
> >> >libraries on the remote box). Not only that, but the two daemons would have
> >> >to know about each other and be able to communicate so that your remote
> >> >sessions can be controlled by you and you only. And both your box and these
> >> >remote servers would have to have one of these magical daemons for every
> >>
> >> True. However X clients have been doing this sort of thing for
> >> nearly 20 years and Unix is quite capable of handling many small
> >> process communicating with each other. The challeges aren't quite
> >> as impressive as they might sound from a less client-server oriented
> >> perspective.
> >>
> >> >widget library used by the apps you're running (each of which communicate with
> >> >one another). As is often the case, you may not even have administrative
> >> >privileges on one of the boxes in question, and hence could not install or
> >> >start such a daemon yourself as a lowly user.
> >> >
> >> >Application interoperability is much more important than system
> >> >interoperability for such an application, as is the case for nearly any task
> >> >that a home user will want to do. That's my point.
> >>
> >> That's what OEMs, VARs and Distributions are for.
> >
> >But you were attempting to tell me about the wonder of system interoperability
> >for home users. How can you claim any reasonable amount of interoperability
> >if you have to rely on a specific installation of an OS? Are you going to
>
> OEMs make sure all the right pieces are there for a particular
> machine or end user. That doesn't mean that Solaris machines
> can't seamlessly interact with NT machines or Irixes or anything
> else with the necessary tools installed.
You're glossing over my point. It is much more important to me as a home user
to have application interoperability, such as that demonstrated by VoiceType,
than it is to have my computer interoperate with other systems. It makes me
more productive and gives me more powerful tools if I have applications which
can work well together. It buys me nothing if I can run my processes on
somebody else's box and have my file formats and communications protocols
recognized by them. System interoperability only becomes important when
transferrance of information is required. Application interoperability, by
contrast, enables one to be more productive in what they are doing.
------------------------------
From: [EMAIL PROTECTED] (abraxas)
Crossposted-To:
comp.sys.mac.advocacy,comp.os.os2.advocacy,comp.os.ms-windows.nt.advocacy
Subject: Re: Canada invites Microsoft north
Date: 9 Jun 2000 23:41:18 GMT
In comp.os.linux.advocacy Bob Germer <[EMAIL PROTECTED]> wrote:
> On 06/09/2000 at 08:59 PM,
> [EMAIL PROTECTED] (abraxas) said:
>> I dont run windows by the way, or OS2. In case you thought you were
>> getting my goat or something. :)
> Then there are only 2 possibilities. You are running a MAC which is
> nothing more than a glorified Playstation or you are running some form of
> unix which makes your machine virtually useless for 99.98% of business
> customers.
I could be running BeOS, or RISCOS, or Workbench, etc. on a variety of
systems, etc.
Tell me once again how useful OS/2 is for business customers.
=====yttrx
------------------------------
From: "Daniel Johnson" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.os2.advocacy,comp.os.ms-windows.nt.advocacy,comp.sys.mac.advocacy
Subject: Re: Would a M$ Voluntary Split Save It?
Date: Fri, 09 Jun 2000 23:48:33 GMT
"Leslie Mikesell" <[EMAIL PROTECTED]> wrote in message
news:8hpvl1$1oo3$[EMAIL PROTECTED]...
> In article <kvL%4.644$[EMAIL PROTECTED]>,
> Daniel Johnson <[EMAIL PROTECTED]> wrote:
>
> >The Halloween document specifies *improved* products.
>
> The goal was to:
> "De-commoditize protocols & applications"
The goal was to defend MS's dominant position against
a competitor; product improvement was a means to that
end. These haven't every been comodities outside of
the stagnant Unix world, and MS has no reason to expect
them to become so.
> not improve them. Improving them would be to make them even
> more open and thus more widely useful.
No, improving them would not make them more open. At least,
not the way MS does it. :D
> >And "dumping" *is* an improvement for the customers; it's
> >rather inconvinient for competitors, but they can cope.
>
> The improvement is temporary as the innovations of the
> defunct competitors disappear.
Now now, MS is hardly shy about borrowing its competitors
ideas. And of course, the competitors who do not give up
will presumably be compelled to innovate to cope with
MS's rock bottom pricing
This *is* how MS proposes to deal with the similarly low pricing
of Linux. Why can't others do it? Is everyone but MS stupid?
> >I have, for instance, no doubt that Microsoft will rise to the
> >challen of Linux, even though Linux is clearly being dumped
> >into Windows NT's market.
>
> Dumping, by definition, is to sell below cost of production.
> Something built by volunteers doesn't have an associated cost.
Sure it does. Those volunteers are spending their time and money
on it; that they don't draw salaries isn't terribly relevant, unless you
feel that Open Source is magic and special and just *deserves* to
be privileged.
Which I don't. I find it awfully uncreative.
> >MS can't hope to undercut Linux
> >on pricing and still make money, but that doesn't mean they
> >have to give up.
>
> They don't have to concentrate on 'de-commoditizing' either.
> But I don't expect them to stop.
Indeed. Now, if the open source movement *had* managed to
commoditize software, I would fully support efforts to get
technological progress restarted.
Personally, I don't think this has happened. But I just want you
to know I think "de-commoditizing" is a good thing.
> >> Because WINE isn't complete yet to allow an easy transition
> >> away while keeping some legacy apps working.
> >
> >Hmmm.
> >
> >If Linux had had perfect Windows emulator, would *you* use
> >it? It would mean using Windows apps, after all.
>
> There are some nice innovative Windows apps, like Visio, for
> example. And my kids sometimes need to do PowerPoint presentations
> for school. But, of course the real need is to match up
> exactly with those 'de-commoditized' file formats and protocols.
I don't see how WINE is much a solution for that, though.
[snip]
> >Their competitors need protection; they can't seem to keep up.
> >The rest of us don't.
>
> People who would like to have a choice need protection.
You've your choice- you can run wahtever softwarae you like. If
that software isn't good enough for your needs, that is your problem.
People who want to *make* other people use software they don't
want to use- just to cover up their interoperability problems-
need some help.
But I wouldn't call it protection.
> >> For the subset of software that runs under Windows.
> >
> >Well, yes. You can't expect such standardization to be
> >cross platform, after all. Had Windows standardized
> >on PostScript, that would have done zip for anyone else.
>
> Then there would be one popular abstraction, one popular scalable
> font type, etc. with multiple implementations.
You are assuming, of course, that a Windows standardized on PostScript
would succeed- and I doubt it.
Further, you are assuming that if Windows standardizes on PostScript
everyone else will do likewise. This is *very* unlikely; consider the
effort Apple had *already* expended on QuickDraw.
> If someone built
> a 'Winprinter' with a postscript engine it wouldn't be 'de-commoditized'
> to a point where it was impossible to use without buying a specific
> OS.
A "winprinter with a postscript enginer" is a contradiction in terms. Now
a winprinter driven by GhostScript is a fine idea, and perfectly feasible-
but really not substantially different from a winprinter driven by a GDI
driver. Both are dependant on software that drives the printer in
essentially
the same way, and both really just print bitmaps- and let another software
component generate that bitmap.
It's a wash.
But a winprinter driver writen for a hypothetical windows w/ GhostScript-
style printer support would probably not be easily portable to Linux.
Neither, at the end of the day, really does *any* rendering; they just
driver a printer and spit out a bitmap.
> >> Some individual users with one computer and one printer have
> >> done that. Offices tend to have a mix and the diversity
> >> is growing.
> >
> >More precisely, they have a mix of printers (and other accessories)
> >but they tend to be mostly Windows, because by doing so their
> >mix of hardware works.
>
> A more accurate way to express that is that it is difficult
> to use windows with anything else.
No, Windows is very flexible. You *could* use it with all PostScript
printers if you wished to. But it can *also* support less impressive
printers, like PCL printers, without compromise. It can even support
crappy line printers and garbage like that, though that is not so
common these days.
And when the Next Generation Amazing Printer Format comes
along, Windows will be able to support that too.
> And the Halloween document
> makes it clear (as if we didn't already know) that it is
> intentional.
The Halloween document doesn't address this specifically, but
it certainly fits the pattern there outlined- give Windows more
features and better capabilities while retaining as much
cross platform compatibility as possible. Put Linux in the
position of playing perpetual catch up, but make it easy to
transition to Windows.
The plan presumes (explicitly!) that the open source movement
cannot innnovate, cannot turn the tables and make MS play
catch-up as commercial vendors can and sometimes do.
If in time the assumption proves wrong, their
"embrance and extend" idea could backfire badly; if they
embrace and the open source community extends, then
they get to play catch up, and all that lovely compatibility
will only make it easy for their customers to switch to Linux
or something.
But so far, they seems to be right.
[snip]
> >> All of the other old systems, including word95. The money
> >> for the upgrade version is the same color as a brand new
> >> copy.
> >
> >So why doesn't this apply to Windows 2000? Why doesn't
> >MS want to kill "all the other old systems, including Windows 97?"
>
> They probably haven't finished counting the money from the last
> round yet.
:D
[snip]
> >> I'm not presuming anything about the system. I'm observing
> >> it. It does seem healthier on a bigger disk.
> >
> >Well, okay, why don't you fix it? Is somebody else tasked
> >with that at your organization?
>
> This is a personal machine that dual-boots. Now it spends most
> of its time running Linux.
Well, okay. I'm surprised you are not more concerned, if it is
your personal machine.
[snip]
> I have found useful bits of information in the MS knowledge base
> but it is extremely painful. For example the first time I
> tried to set up WLBS where a pair of NT boxes shared an IP
> address for load balancing, it didn't work. The best I could
> find in the knowledge base went approximately: "if it doesn't
> work try a different NIC". Turned out to be correct, but there
> was no list of which ones work or don't work, or why. I got the
> feeling I was sprinkling chicken blood around at midnight to ward off
> the daemons.
I wasn't talking about the knowledge base; I find that rather
hit or miss- a great pile of 'knowlege', but not so much 'base'-
good mainly for bug reports, in my experience.
I meant MSDN; the knowledge base is but a small fragment
of that.
[snip]
> >Perhaps I misremembered it. It's been awhile since I had
> >to install honest-to-gawd Windows 95.
>
> This is a fresh-from-Dell preinstalled Win98SE, I assume still
> with the Microsoft-dictated desktop that the hardware vendors
> are (were?) prohibited from altering.
They are allowed to put extra icons on; the computer I type
this on had a great *mass* of icons. MSN wasn't one of
them, though. It was Win98 first edition. Perhaps they've
returned to it.
> >You'll noticed that MS did eventually drop that icon.
>
> It's back, if it ever did go away. Unlike the others, it
> doesn't have any properties. I think I can delete it but
> it won't go to the recycle bin so it's a one-way trip.
You say that like it's a *bad* thing. :D
[snip]
> >A menu but not the start menu? Windows does not have
> >that feature.
>
> Too bad. It does let you drop a folder there but it
> wants to make everthing in it visible. If you nest it
> inside another folder it comes close to what I wanted,
> just not as neat as KDE. In KDE the contents appear
> as a menu-like popup when you click the toolbar icon.
> In Win98 with a nested folder, clicking the icon opens
> the inner folder out on the desktop.
That's a nice feature.
[snip]
> >I don't see why fiddling the details of the toolbar is
> >preferable to fiddling those of the start menu, and I don't
> >understand how putting something on the toolbar
> >means its is also available on the desktop.
>
> There is just way to much junk on the desktop and in the
> program menu to find anything (especially if you test
> a lot of programs, let the kids load games, etc.)
Well, I don't know, I try to keep my desktop a little neater
than that. The program menu is a bit over the top, but it's
nice to have somewhere to go to get to *every* program
you have.
> I want
> a dozen or so things that I can find quickly. Putting the
> icons in a folder on the desktop gives a reasonable isolation
> and lets you duplicate the set of choices onto another machine
> by copying the folder around. But, it is not really handy
> to use there because the desktop is usually obscured and you
> have to double-click to open that folder before even seeing what
> you want. With KDE the only extra fiddling is to drag a copy
> of the folder to the toolbar and it becomes a handy popup where
> one click/drag starts any of the items.
I see. Why do you want to keep it on your desktop, then? Sounds
like its better off in the toolbar..
> >No, Windows just doesn't have the feature you are
> >looking for.
>
> How do you get a handy set of 'your' items isolated from the rest?
Windows has per-user desktops; your start menu can have
items just for you. Likewise the toolbars Windows does
have (which don't pop up).
> And after you do it, can you copy to another machine?
Certainly. They are just folders. Copy all day long. The
easy way to get at them is with the context menu;
you can "Open" the start menu or a toolbar and
see the content in a window.
[snip]
> >> The issue is whether a single company should be allowed to
> >> force this. Politically, phone companies can't.
> >
> >No company can force this; that is just your fantasy.
>
> No, my fantasies are much more fun than dealing with monopolies.
Well, then there's hope for you. :D
> >You might know if you read the manual, but it came from
> >Microsoft, so it is Chock Full o' Lies (tm), no doubt.
>
> I like that!
Yes, but you can't use it, it's trademarked. :D
[snip]
> >Not really; they just aren't using it as an internet protocol,
> >which is probably wise since it isn't a very good one.
> >
> >There are lots of people out there who use it as a
> >*word processor*, for which task it actually is pretty
> >decent.
>
> But people work together, and you can hardly buy a computer
> that does not have the current version of Word on it -
Sure you can. Word is an expensive program, low end computers
are frequently sold without it.
> it is even in the Works package now.
I beg your pardon?
I do not think Word is any part of Works. You've got it
confused with Office.
> So - sooner or later you
> end up needing a program that will match.
That will read the same files your co-workers do, certainly.
It does not have to be *MS Office*.
------------------------------
** 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
******************************
