Re: The PC industry is heading for collapse

[J G Miller]

On Monday, January 23rd, 2012, at 10:52:01h -0800, Charlie Gibbs wrote:

> A Linux version 0.9.2 is available - but apt-get won't find it.

What did you expect -- the version that comes with whatever version
of Ubuntu you have is the one that is "available/supported" for that
version. And that means all the library version dependencies for
that version as well.

> I spent several hours in dependency hell, downloading and
> building one package after another as I worked my way backwards up the
> critical path.

So, if you want the latest version, that is what you have to do --
also install the latest versions of the libraries on which the
application depends -- and to avoid problems, everything should
be installed under /usr/local.

> Dependency hell is making Linux useless as an application platform.

To plagiarize another poster's expression -- the TROLL BELL just sounded.

> It's time application developers stopped going after all the flashy
> features offered by a myriad of libraries, and started turning out
> applications that were more self-sufficient.

You just do not understand the concept of code reuse via shared libraries.

The fact is Ubuntu came with a version of the application you did
not want to use.

[Charlie Gibbs]

In article <jfkee3$spb$2...@dont-email.me>, mil...@yoyo.ORG (J G Miller)
writes:

> On Monday, January 23rd, 2012, at 10:52:01h -0800, Charlie Gibbs wrote:
>
>> Dependency hell is making Linux useless as an application platform.
>
> To plagiarize another poster's expression -- the TROLL BELL just
> sounded.

No, not trolling, just howls of frustration.

>> It's time application developers stopped going after all the flashy
>> features offered by a myriad of libraries, and started turning out
>> applications that were more self-sufficient.
>
> You just do not understand the concept of code reuse via shared
> libraries.

I believe I do understand the concept. However, I also understand
that it's not a magical solution - it has its pitfalls.

> The fact is Ubuntu came with a version of the application you did
> not want to use.

In other words, you're stuck in a sandbox that's just as circumscribed
as Windows. To break out of the sandbox - on Windows or Linux - you
need powerful tools and hackish skills. That's fine, if you're a
hacker. But it's not going to lure J. Random Luser away from his
Windows box.

And that's what drives me crazy. I want to bring users over to Linux.
But something always goes wrong, and they turn and walk away - and
Microsoft wins again.

--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!

[Dan Espen]

NO!

You aren't stuck in a sandbox, not even close.

It doesn't take hackish skills to enable the beta repository,
use it, then turn it off. For most distros that's really all you have
to do.

The whole failure case you've come up with is a rare thing anyway.
I can't remember the last time I've needed a beta copy of anything.


--
Dan Espen

[Larry Blanchard]

On Mon, 23 Jan 2012 20:03:16 +0000, J G Miller wrote:

>> I spent several hours in dependency hell, downloading and building one
>> package after another as I worked my way backwards up the critical
>> path.
>
> So, if you want the latest version, that is what you have to do -- also
> install the latest versions of the libraries on which the application
> depends -- and to avoid problems, everything should be installed under
> /usr/local.

OK, let me throw in an old term "static linking". That means all of the
libraries needed are linked into the binary. We always did that with
process control stuff because it loaded and ran faster.

Yes, the binary gets quite a bit larger. But how many run-time libraries
are being used by multiple applications in the environment of most users?

I run Thunderbird to get my mail. Then I run Pan to peruse the
newsgroups. I may or may not run Firefox to do some web browsing, or an
Open Office app for a document, spreadsheet, or database.

The point is I'm running these *one at a time* - the shared runtime
libraries don't buy me anything. Except for possible dependency problems.

I'm not suggesting that developers do away with the dynamically linked
versions. Just offer a choice. That way if someone has a problem with
dependency they can wipe it and get the static version.

Why not?

--
Intelligence is an experiment that failed - G. B. Shaw

[Charlie Gibbs]

In article <icwr8i6...@home.home>, des...@verizon.net (Dan Espen)
writes:

You're right, this is a rare thing. (Unfortunately, that doesn't
help my wife get to the version that downloads and runs on her XP
box.) For the most part, I've found apt-get to be a rather nice
bit of magic - it's allowed me to quickly and easily do installations
that would be a real nightmare otherwise. Now, though, it's time
for me to look under the hood and try to understand the magic.
I'll try the beta repository - thanks for the pointer.

Following my own advice to stay away from the bleeding edge (except
where I needed a less-buggy version of a new package), I'm running
Ubuntu 10.10 instead of trying version 11. (Enough people seem to
hate Unity that I probably would too.)

[Dan Espen]

I'm using Fedora.
No way I'd even think about Unity.

If you're not current on Ubuntu versions, that might explain
why you are having package version problems.

--
Dan Espen

[Dan Espen]

Larry Blanchard <lbl...@fastmail.fm> writes:

> On Mon, 23 Jan 2012 20:03:16 +0000, J G Miller wrote:
>
>>> I spent several hours in dependency hell, downloading and building one
>>> package after another as I worked my way backwards up the critical
>>> path.
>>
>> So, if you want the latest version, that is what you have to do -- also
>> install the latest versions of the libraries on which the application
>> depends -- and to avoid problems, everything should be installed under
>> /usr/local.
>
> OK, let me throw in an old term "static linking".

...
> Why not?

Simple.

The flexibility is at the library level. That's why shared libraries
have version numbers.

Try to run a very old glibc against a newer kernel.
There is no guarantee, or even intent, of compatibility.

--
Dan Espen

[The Natural Philosopher]

Charlie Gibbs wrote:
> In article <jfkee3$spb$2...@dont-email.me>, mil...@yoyo.ORG (J G Miller)
> writes:
>
>> On Monday, January 23rd, 2012, at 10:52:01h -0800, Charlie Gibbs wrote:
>>
>>> Dependency hell is making Linux useless as an application platform.
>> To plagiarize another poster's expression -- the TROLL BELL just
>> sounded.
>
> No, not trolling, just howls of frustration.
>
>>> It's time application developers stopped going after all the flashy
>>> features offered by a myriad of libraries, and started turning out
>>> applications that were more self-sufficient.
>> You just do not understand the concept of code reuse via shared
>> libraries.
>
> I believe I do understand the concept. However, I also understand
> that it's not a magical solution - it has its pitfalls.
>
>> The fact is Ubuntu came with a version of the application you did
>> not want to use.
>
> In other words, you're stuck in a sandbox that's just as circumscribed
> as Windows. To break out of the sandbox - on Windows or Linux - you
> need powerful tools and hackish skills. That's fine, if you're a
> hacker. But it's not going to lure J. Random Luser away from his
> Windows box.

No, the difference is there is no way OUT of the windows sandbox.
And you paid a fortune to get into it.

>
> And that's what drives me crazy. I want to bring users over to Linux.
> But something always goes wrong, and they turn and walk away - and
> Microsoft wins again.
>

nothing ever seems to go wrong for me.

Unlike Macintosh.

Mind you you cant blame Steve Jobs for the dog ripping the headphone
plug in half as he struggled to get out from under the desk.

Some wiggling with the broken plug caused the broken bit to pop out
thank heavens. No WAY could I access the back of the socket from inside
the case. Covered in industrial garde depleted uranium or something.

At least with Linux I can generally fix stuff. Not with DomesDOS. Or OSX.

[Peter Flass]

Most OS/2 packages used to come in two versions. I'd usually want the
dynamically-linked version, but it was nice to have the choice.

[Richard Kettlewell]

1) Because of what has to happen when a vulnerability is found in a
library used by the application.

2) Because there are things that stop working with static linking:
LD_PRELOAD-based tools and (IIRC) NSS.

3) Because some libraries depend on static or mutable state other than
their object code; that would have to be coordinated, by assumption
among all the (perhaps mutually incompatible) versions of the library
used across the system.

Sometimes 2 and 3 don't apply. But 1 you're really stuck with.

--
http://www.greenend.org.uk/rjk/

[JEDIDIAH]

On 2012-01-24, Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
> In article <icwr8i6...@home.home>, des...@verizon.net (Dan Espen)
> writes:
>
>> "Charlie Gibbs" <cgi...@kltpzyxm.invalid> writes:
>>
>>> In article <jfkee3$spb$2...@dont-email.me>, mil...@yoyo.ORG (J G Miller)
>>> writes:
>>>
>>>> The fact is Ubuntu came with a version of the application you did
>>>> not want to use.
>>>
>>> In other words, you're stuck in a sandbox that's just as circumscribed
>>> as Windows. To break out of the sandbox - on Windows or Linux - you
>>> need powerful tools and hackish skills. That's fine, if you're a
>>> hacker. But it's not going to lure J. Random Luser away from his
>>> Windows box.
>>>
>>> And that's what drives me crazy. I want to bring users over to Linux.
>>> But something always goes wrong, and they turn and walk away - and
>>> Microsoft wins again.
>>
>> NO!
>>
>> You aren't stuck in a sandbox, not even close.
>>
>> It doesn't take hackish skills to enable the beta repository,
>> use it, then turn it off. For most distros that's really all you have
>> to do.
>>
>> The whole failure case you've come up with is a rare thing anyway.
>> I can't remember the last time I've needed a beta copy of anything.
>
> You're right, this is a rare thing. (Unfortunately, that doesn't

If it's a beta copy then there is no Windows equivalent anyways.

You are whining about something being hard when that option does
not even exit under Windows. The fact that development is out in the
open means that you can be an early adopter if you are motivated
enough.

There is nothing hard about a well made source tarball. It's no
more difficult than a Windows installshield style installer. Like
anything else, it's up to the individual developer and YMMV. You
don't get away from this problem on Windows.

[deletia]

--

It is not true that Microsoft doesn't innovate.

They brought us the email virus.

In my Atari days, such a notion would have |||
been considered a complete absurdity. / | \

[Larry Blanchard]

On Tue, 24 Jan 2012 09:30:52 +0000, Richard Kettlewell wrote:

>> Why not?
>
> 1) Because of what has to happen when a vulnerability is found in a
> library used by the application.

If it doesn't cause the application to freak out, and isn't an Internet
security problem, I could care less. As has been said here many times,
most of us just want some application to run out of the box.

And there is no such thing as an invulnerable application.

And there's nothing stopping the app's developer from relinking and
making the new version available. In fact, that may be the whole point.
Let one person, who's an expert in the app, do the work so everyone
doesn't have to.

I know what I'm suggesting will never happen - it's "old school" and
sneered at by practitioners of "modern" programming. But it worked. I
wrote software from the late '50s till about 2000 on everything from
mainframes to micros, Univac to PCs, so I do have a little experience in
the matter.

[Larry Blanchard]

On Mon, 23 Jan 2012 21:27:32 -0500, Dan Espen wrote:

> Try to run a very old glibc against a newer kernel. There is no
> guarantee, or even intent, of compatibility.

A Unix(ish) kernel is supposed to supply a certain number of services in
a well defined manner. New ones may be added from time to time, but the
old ones should not change. If an application library is written to use
some non-standard kernel service it's poorly written. IOW, if your
assertion is correct, it's the result of bad programming.

[J G Miller]

On Tuesday, January 24th, 2012, at 02:35:44h +0000,
The Natural Philosopher wrote:

> Not with DomesDOS.

DomesDOS? (That's a good one I had not heard before.)

Well try FreeDOS instead.

[J G Miller]

On Tuesday, January 24th, 2012, at 17:29:17h +0000, Larry Blanchard wrote:

> A Unix(ish) kernel is supposed to supply a certain number of services in
> a well defined manner. New ones may be added from time to time, but the
> old ones should not change.

The problems arise not so much in the static part of the kernel but,
usually in the modules for hardware interfaces.

An example --

Consider multimedia type applications for eg radio and TV -- the
kernel modules and programming interface changed from v4l to v4l2,
and after a while the compatiblity layer that was possible for v4l
to v4l2 has disappeared (as far as I am aware).

So now under Linux 3, applications which worked fine to tune
radio devices no longer work because somebody has not updated
the radio part of the v4l2 modules for the new kernel version.

An even older example would be sound applications which used
OSS. OSS has been replaced by ALSA, but only thanks to the
maintenance of the OSS compatibility layer under ALSA, do these
old OSS only applications still work, but for how much longer?

[Richard Kettlewell]

Larry Blanchard <lbl...@fastmail.fm> writes:
> Richard Kettlewell wrote:

>>> Why not?
>>
>> 1) Because of what has to happen when a vulnerability is found in a
>> library used by the application.
>
> If it doesn't cause the application to freak out, and isn't an
> Internet security problem, I could care less.

A vulnerability will turn out to be remotely exploitable more often than
you think. The obvious example is that anything that reads files of
some kind is going to be used, sooner or later, to read files that came
from an untrusted source.

Moreover in order to determine whether that condition holds requires
application authors to consider whether each bug discovered in each
library they use affects their application in a way that matters.
That's simply not a very productive use of (often unpaid, in this
context) time when their users can _and mostly do_ install the fixed
version of the library on the next automatic update.

> As has been said here many times, most of us just want some
> application to run out of the box.

It's a perfectly reasonable end goal.

> And there is no such thing as an invulnerable application.
>
> And there's nothing stopping the app's developer from relinking and
> making the new version available. In fact, that may be the whole point.
> Let one person, who's an expert in the app, do the work so everyone
> doesn't have to.

The application the OP mentioned ends up linked against over 80
different shared libraries. A free application of my own links against
around 50. It's not surprising that application authors won't give up
their time to do the tracking, analysis, rebuilding and user
notification that would be required.

> I know what I'm suggesting will never happen - it's "old school" and
> sneered at by practitioners of "modern" programming. But it worked. I
> wrote software from the late '50s till about 2000 on everything from
> mainframes to micros, Univac to PCs, so I do have a little experience in
> the matter.

I'm quite happy to believe that. I think the problem is in your
estimation of the relationship between the effort required to achieve
it, the effort available to do so, and the actual in-practice benefit of
doing so.

--
http://www.greenend.org.uk/rjk/

[Richard Kettlewell]

Dan Espen <des...@verizon.net> writes:
> Try to run a very old glibc against a newer kernel.
> There is no guarantee, or even intent, of compatibility.

A system I use had a.out binaries in active use within the last few
months, using a libc version that's been thoroughly obsolete since some
time in the mid 1990s.

I infer that the kernel ABI has pretty good long-term stability in
practice.

--
http://www.greenend.org.uk/rjk/

[Dan Espen]

Yes, but as I said, the _intent_ is to provide compatibility at the
shared library interface. Of course you can go a long time
with selected programs. Other posters have pointed out other
reasons but if you want to go with static linking go for it.

--
Dan Espen

[The Natural Philosopher]

J G Miller wrote:
> On Tuesday, January 24th, 2012, at 02:35:44h +0000,
> The Natural Philosopher wrote:
>
>> Not with DomesDOS.
>
> DomesDOS? (That's a good one I had not heard before.)
>

Kills 999% of all computers stone dead..eventually.

> Well try FreeDOS instead.

"Nothing works faster than FreeDos"
"So use nothing instead?"

[Richard Kettlewell]

I don't think that's true. The syscall ABI for instance has an explicit
promise of compatibility - additions but no removal.

--
http://www.greenend.org.uk/rjk/

[J G Miller]

On Tuesday, January 24th, 2012, at 19:30:43h +0000, The Natural Philosopher wrote:

> J G Miller wrote:
>> On Tuesday, January 24th, 2012, at 02:35:44h +0000, The Natural
>> Philosopher wrote:
>>
>>> Not with DomesDOS.
>>
>> DomesDOS? (That's a good one I had not heard before.)
>>
>>
> Kills 999% of all computers stone dead..eventually.

Aha, I see what you did there -- at first I was being careless
and reading it not as DomesDOS but Doomdos.

I do not think that many readers outside of the UKofGB&NI will
understand DomesDOS though, so an explanation is in order.

Domestos is a brand of bleach equivalent to Javex.

And Javex is just a brand name derived from the French for
bleach - l'eau de javel.

<http://fr.wikipedia.org/wiki/Eau_de_Javel>

>> Well try FreeDOS instead.
>
> "Nothing works faster than FreeDos"
> "So use nothing instead?"

Hmm, that would be AnaDOS.

FreeDOS is a reputable open source GPL DOS

<http://www.freedos.ORG/>

[Peter Flass]

On 1/24/2012 12:23 PM, Larry Blanchard wrote:
>
> I know what I'm suggesting will never happen - it's "old school" and
> sneered at by practitioners of "modern" programming. But it worked. I
> wrote software from the late '50s till about 2000 on everything from
> mainframes to micros, Univac to PCs, so I do have a little experience in
> the matter.
>

That's what I do in my (very) small corner of the world.

[Peter Flass]

No reason not to, unless you're microsoft. It's not rocket science
folks, IBM has been handling this well since the 60s. If you have to
*substantially* add to an OS service, use another call (SVC, INT, etc.)
and keep the old one for compatibility.

[Larry Blanchard]

On Tue, 24 Jan 2012 17:57:45 +0000, J G Miller wrote:

>> A Unix(ish) kernel is supposed to supply a certain number of services
>> in a well defined manner. New ones may be added from time to time, but
>> the old ones should not change.
>
> The problems arise not so much in the static part of the kernel but,
> usually in the modules for hardware interfaces.

True enough. There will always be apps dependent on some particular
hardware and/or device interface. I should have been more clear. But
folks who use those apps are probably aware of the dependencies. I doubt
I'll ever get my old TRS-80 code off of those cassettes :-).

No, I really don't have those, but until recently I had some 800bpi mag
tapes with some IBM 1130 apps on them. Good thing I don't need a
modified Sells COGO program any more :-).

I think I do still have some punched cards around somewhere with some
plotting software I wrote when working for Calcomp :-).

Anyway, your point is well taken, but I wonder how much of the universe
of apps it represents.

[Bernd Felsche]

Larry Blanchard <lbl...@fastmail.fm> wrote:
>On Mon, 23 Jan 2012 21:27:32 -0500, Dan Espen wrote:

>> Try to run a very old glibc against a newer kernel. There is no
>> guarantee, or even intent, of compatibility.

>A Unix(ish) kernel is supposed to supply a certain number of services in
>a well defined manner. New ones may be added from time to time, but the

>old ones should not change. ...

Wrong.

Kernel interfaces change because the inherent structure/architecture
(e.g. process table) changes. While the kernel may provide
compatability for old system calls for some time, carrying such a
burden indefinitely is onerous and comes at the expense of not just
kernel bloat and a great deal of development to maintain that system
call compatability as the underlying architecture changes over the
decades, but also at the performance cost of newer applications that
do the system calls in the "current" manner.

Eventually, the application will only be able to run in a virtual
machine.

>If an application library is written to use
>some non-standard kernel service it's poorly written. IOW, if your
>assertion is correct, it's the result of bad programming.

(g)libc is a system library. Not an application library.

Assumptions *have* to be made while programming. An implied one is
that the kernel will not change. One doesn't usually do system calls
directly in applications but lets the system libraries (libc, et al)
do that. And those libraries do change over time. It would be
necessary to interpose another layer of libraries for each
application (family) to isolate the application program from changes
at system library level.
--
/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia
\ / ASCII ribbon campaign | For every complex problem there is an
X against HTML mail | answer that is clear, simple, and wrong.
/ \ and postings | --HL Mencken

[Bernd Felsche]

Larry Blanchard <lbl...@fastmail.fm> wrote:
>On Tue, 24 Jan 2012 17:57:45 +0000, J G Miller wrote:

>> The problems arise not so much in the static part of the kernel but,
>> usually in the modules for hardware interfaces.

>True enough. There will always be apps dependent on some
>particular hardware and/or device interface. I should have been
>more clear. But folks who use those apps are probably aware of the
>dependencies. I doubt I'll ever get my old TRS-80 code off of
>those cassettes :-).

Depends mostly on how well you've stored those cassettes. Data
recovery is pretty easy. You could do it yourself using an ordinary
cassette player with line-out to a reasonable audio card. Capture
the raw audio to a file first because you never know how much longer
that tape will last. Then DSP is your friend.

[Peter Flass]

On 1/24/2012 9:24 PM, Bernd Felsche wrote:
> Larry Blanchard<lbl...@fastmail.fm> wrote:
>> On Mon, 23 Jan 2012 21:27:32 -0500, Dan Espen wrote:
>
>>> Try to run a very old glibc against a newer kernel. There is no
>>> guarantee, or even intent, of compatibility.
>
>> A Unix(ish) kernel is supposed to supply a certain number of services in
>> a well defined manner. New ones may be added from time to time, but the
>> old ones should not change. ...
>
> Wrong.
>
> Kernel interfaces change because the inherent structure/architecture
> (e.g. process table) changes. While the kernel may provide
> compatability for old system calls for some time, carrying such a
> burden indefinitely is onerous and comes at the expense of not just
> kernel bloat and a great deal of development to maintain that system
> call compatability as the underlying architecture changes over the
> decades, but also at the performance cost of newer applications that
> do the system calls in the "current" manner.

OS/360: 1964, zOS:2012, compatiblity: priceless. There have been a few
cases where IBM had to abandon compatibility, but they were usually
little used anyway, such as reusing the "ASCII" bit in the PSW or, as I
recall, reusing a device-type code in the UCB that had been assigned to
some obscure and long-obsolete tape drive.

[Peter Flass]

On 1/24/2012 9:36 PM, Bernd Felsche wrote:
> Larry Blanchard<lbl...@fastmail.fm> wrote:
>> On Tue, 24 Jan 2012 17:57:45 +0000, J G Miller wrote:
>
>>> The problems arise not so much in the static part of the kernel but,
>>> usually in the modules for hardware interfaces.
>
>> True enough. There will always be apps dependent on some
>> particular hardware and/or device interface. I should have been
>> more clear. But folks who use those apps are probably aware of the
>> dependencies. I doubt I'll ever get my old TRS-80 code off of
>> those cassettes :-).
>
> Depends mostly on how well you've stored those cassettes. Data
> recovery is pretty easy. You could do it yourself using an ordinary
> cassette player with line-out to a reasonable audio card. Capture
> the raw audio to a file first because you never know how much longer
> that tape will last. Then DSP is your friend.

There's also a fairly active 1130 community that might like to look at
any tapes.

[Anne & Lynn Wheeler]

Peter Flass <Peter...@Yahoo.com> writes:
> OS/360: 1964, zOS:2012, compatiblity: priceless. There have been a
> few cases where IBM had to abandon compatibility, but they were
> usually little used anyway, such as reusing the "ASCII" bit in the PSW
> or, as I recall, reusing a device-type code in the UCB that had been
> assigned to some obscure and long-obsolete tape drive.

story about 360 was suppose to be ASCII ... but somebody made a big
mistake:
http://www.bobbemer.com/P-BIT.HTM
other refs from the website
http://www.bobbemer.com/ASCII.HTM
http://www.bobbemer.com/BACSLASH.HTM
http://www.bobbemer.com/FATHEROF.HTM

still compatible wasn't exactly on purpose. In the early 70s, the
company started a project to completely replace 360/370 ... it was going
to be as different from 360/370 as 360 had been different from early
generations ... some past posts
http://www.garlic.com/~lynn/submain.html#futuresys

misc. other web references:
http://www.jfsowa.com/computer/memo125.htm
http://www.cs.clemson.edu/~mark/fs.html
http://www.ecole.org/Crisis_and_change_1995_1.htm
http://en.wikipedia.org/wiki/IBM_Future_Systems_project

during FS, internal politics was even killing off 370 projects as
competitive ... then after the demise of FS ... there was mad rush to
get products back into the 370 product pipelines.

I had continued with 370 activity all during the FS period ... even
periodically ridiculing the FS efforts (which likely wasn't very career
enhancing). The mad rush to get stuff back into 370 product pipelines
contributed to picking up some of the stuff I had been doing and
shipping to customers. Somewhat related old email:
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430

part of the story is that the corporate distraction of the FS effort
(and killing 370 efforts) allowed for clone processors to gain market
foothold. Then some of the aftermath there was some activities possibly
directed at clones ... some touched on in this (long-winded) post
(changes that might not directly affect application programs):
http://www.garlic.com/~lynn/2012.html#92 Has anyone successfully migrated off mainframes?

other references are that top executives reacted adversely to the FS
demise which had long-term downside on corporate culture. Quotes from
Charles Ferguson and Charles Morris, Computer Wars: The Post-IBM World,
Times Books, 1993:

Most corrosive of all, the old IBM candor died with F/S. Top
management, particularly Opel, reacted defensively as F/S headed
toward a debacle. The IBM culture that Watson had built was a harsh
one, but it encouraged dissent and open controversy. But because of
the heavy investment of face by the top management, F/S took years to
kill, although its wrongheadedness was obvious from the very
outset. "For the first time, during F/S, outspoken criticism became
politically dangerous," recalls a former top executive.

... snip ...

One of the other results was that almost all advanced-technology efforts
were killed off (filling the 2-5yr gap between advanced research and
immediate product ship) as the adtech people were thrown into the mad
rush to resume shipping something for 370. I've periodically claimed
that my spring '82 advance technology conference was the first since the
adtech efforts were disappearing in the wake of FS debacle. old
reference
http://www.garlic.com/~lynn/96.html#4a

previous posts in this thread:
http://www.garlic.com/~lynn/2012.html#76 The PC industry is heading for collapse
http://www.garlic.com/~lynn/2012.html#81 The PC industry is heading for collapse
http://www.garlic.com/~lynn/2012.html#83 The PC industry is heading for collapse
http://www.garlic.com/~lynn/2012.html#87 The PC industry is heading for collapse
http://www.garlic.com/~lynn/2012.html#88 The PC industry is heading for collapse

for other PC topic drift:
http://www.garlic.com/~lynn/2012.html#96 Has anyone successfully migrated off mainframes?

before ms/dos there was seattle computer,
http://en.wikipedia.org/wiki/MS-DOS
before seattle computer there was cp/m,
http://en.wikipedia.org/wiki/Seattle_Computer_Products
before cp/m there was cp67/cms
http://en.wikipedia.org/wiki/CP/M

kildall worked on cp67/cms at npg (gone 404, but lives on at the
wayback machine)
http://web.archive.org/web/20071011100440/http://www.khet.net/gmc/docs/museum/en_cpmName.html

npg
http://en.wikipedia.org/wiki/Naval_Postgraduate_School

cp67/cms
http://en.wikipedia.org/wiki/CP/CMS

note that the above mentions CTSS is common ancestor to a number of
things.

above also mentions first cp67/cms release may 1968, however three
people came out from cambridge science center the last week of jan 1968
and installed cp67/cms at the univ. ... misc. past posts mentioning
science center
http://www.garlic.com/~lynn/subtopic.html#545tech

During spring and summer of 1968 I managed to rewrite major sections
of CP67 ... and then did a presentation at the IBM user-group "SHARE"
meeting: SHARE/GUIDE 27 Meeting, Oct. 28-Nov. 1, 1968 Atlantic City,
New Jersey

part of the the presentation previously posted
http://www.garlic.com/~lynn/94.html#18

--
virtualization experience starting Jan1968, online at home since Mar1970

[Charlie Gibbs]

In article <jfn4c3$2kd$1...@dont-email.me>, Peter...@Yahoo.com

Me too. It's nice to be able to just run a free-standing executable
without worrying about installers insinuating their tendrils into
every corner of your file system.

Yes, it's a very small corner of the world. But sometimes
small is beautiful.

--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!

[Charlie Gibbs]

In article <jfn4il$2kd$2...@dont-email.me>, Peter...@Yahoo.com

You don't have to exclude Microsoft; even they see the value in this.
Windows has a lot of APIs which still work even though the documentation
states that DoSomething() is deprecated and you really should be using
DoSomethingEx().

[Peter Flass]

On 1/25/2012 4:27 PM, Morten Reistad wrote:
[snip]
>
> Linux and BSDs have similar mechanisms for handling "alien"
> syscalls, including very old versions of libraries. ALso, BSDS
> may emualate the linux syscalls. Yes, indeed, a FreeBSD kernel
> can run a Linux binary when set up right. For some reason, the
> impetus of doing the opposite does not seem to have been great.
>

Yes, I recently found this out when I wanted to run a BSD binary.

[snip]

>
> Just now, they could use rights to the Crusoe system.
>

I happened to think about Crusoe a few months ago and tried to find out
what happened with it [them]. It sure made a big fuss when first
announced, and then just sort of fizzled out.

[snip]

[Anne & Lynn Wheeler]

re:
http://www.garlic.com/~lynn/2012.html#100 The PC industry is heading for collapse

cp/67 was installed at the univ 44yrs ago this week.

"Before the PC: IBM invents virtualization" discussion in the (linkedin)
z/VM group
http://lnkd.in/kqjVZV

also mentions that I've OCR'ed copy of Comeau's CP40 paper given at 1982
SEAS
http://www.garlic.com/~lynn/cp40seas1982.txt

past posts mentioning "Before the PC" ...
http://www.garlic.com/~lynn/2011i.html#54 Before the PC: IBM invents virtualisation (Cambridge skunkworks)
http://www.garlic.com/~lynn/2011i.html#63 Before the PC: IBM invents virtualisation (Cambridge skunkworks)
http://www.garlic.com/~lynn/2011j.html#1 Before the PC: IBM invents virtualisation
http://www.garlic.com/~lynn/2012.html#107 Before the PC: IBM invents virtualisation