Re: The OS wars and DOOM...
To: Phil Fraering
Subject: Re: The OS wars and DOOM...
From: Andrew Loewenstern
Date: Fri, 21 Jul 95 18:17:12 -0500
Cc: cypherpunks@toad.com
Sender: owner-cypherpunks@toad.com
> Apps have migrated from Unix to the Mac and the PC before in the
> past. In the further past, this has included curses and
> other-types-of-text-control packages such as PC versions of Emacs
> and nethack and the like.
> Of course, this was not done with graphical programs; everyone
> knows that graphics isn't Unix's strong suit, and what it has is
> so different from the PC, etc., blah, blah,...
> Except that for the past two or three years, it's been WRONG.
> One of the hottest games on the PC, DOOM, was originally written
> in Nextstep (a Unix variant, and a ghetto even amidst the "ghetto"
> of Unix) and then ported to the PC.
Being a resident of the NeXTSTEP ghetto, please allow me to chime in. While
Doom is written on NeXTSTEP boxes, that's about all the game itself has in
common with it. The game is carefully written in strict ANSI-C and any
portions that must be OS specific are separate. They have a VGA emulator
that allows them to run Doom on non-DOS boxes. All of the platform
independance comes from the discipline of the developers (who are extremely
talented, IMHO). In contrast, Lotus Improv was NeXT native and had to be
completely rewritten over a period of at least 3 years to get it to work on
Windoze.
The primary reason Id software (and Trilobyte among others) uses NeXTSTEP
(over DOS or any other unix environment) is because it lets them write
in-house tools like map and monster editors really fast (and really slick
too!). On any other platform it would take much more time and effort to
write the tools and they probably wouldn't be as nice either. Since these
tools aren't being sold to customers, it doesn't matter that they only run on
a dead-end niche software platform that costs $1000 per user (and $5k per
developer!!).
This strategy makes sense for a commercial video game where there is the
opportunity to save major amounts of time and effort through the use of
custom tools (and the incentive of major amounts of cash if it is
successful). However, this strategy definitely doesn't make sense when you
are talking about a cypherpunk donating their spare time to write a freeware
(or copyleft) crypto app. Better would be to just write the app for the
target platform or write it using an environment that is designed to be
platform independant (like Java).
andrew...able to work cypherpunks relevance into virtually any thread......and uses
Python instead of NeXTSTEP when writing stuff that needs to be
platform-independant...
Has that little fascist hell-hole burned down yet?
This is Daryl Issa territory. Home to the recall, Pete Wilson, and manifest other horrors.
Funny how the rich white pigs in Scripps are burning it up.
Chula Vista and National City - with Democratic and non-white majorities, got no worry over the fires. 'Cept when the money is doled out county-wide - they'll get nothing again. Al paid-out to rebuild the 5-bedroom homes of retired naval officers outside Tierrasanta.
Python as a required part of the base install... Some will dance, others will puke.
Also, tiny root partitions w/ everything other than/bin/lib/etc mounted did not work w/ Ananconda - at least with RH 7x. You needed a couple hundred MBs free in / to install. This required some fancy "behind the scenes" work - from a console between installer stages - for me to get my 6.2 boxes up to 7.0.
Of course, if you throw the works into/dev/hda1 - there's no prob! Unless you are worried about local priv escalation and other *NIX security issues...
I have to say that I welcome these developments, but do not believe a merger is possible or desireable.
Debian is not defined by its technologies, but by its social contract - whch determines exactly what software and technologies can be included in the disrtibution. True, RedHat / Fedora shares a large intersection with the licensing philosophy and package base of Debian. What they do not share makes them wholly exclusive of eachother - at least from the Debian side of the picture.
This is not meant to be a damper on the technical and practical aspects of Anaconda/Apt! I am "champing at the bit" for this, myself! Think -- no more overriding dependancies after using alien - and subsequently breaking apt-get...
Rob Enderle, a TechNewsWorld columnist, is the Principal Analyst for the Enderle Group, a company founded on the concept of providing a unique perspective on personal technology products and trends.
Cool.
I didn't know that "Unique" was a synonym for "MicroSoft".
Gandi has been fantastic for me. No flashy junk adverts on their pages. No B.S. "features". Just good control of DNS, SOA, forwarding, etc. at a good price.
They are particularly oriented at servicing non-profits, education, etc., which is cool.
I like the combo of gandi.net/zoneedit.com for small networks at the mercy of telco residential service-levels.
Why not? And because I can. It'll eventually make my life easier with optFiles/patches which allow me to upgrade packages while keeping most/all of any customizations I make to the original source package intact. I appreciate the work Debian maintainers do, but sometimes I would like to add my own flavor to things.
Why Debian? Why not just use another source-based distribution?
Debian has thousands of software packages, more than any other distribution I know of. I can always fall back to using a binary package if I'm not in the mood a particular day to wait for the source to compile, especially if I only plan on using it occasionally.
Debian also distributes source code in an easy-to-download format with APT, just like every other source-based distribution. Not only that, Debian has been doing this long before source-based Linux distributions became well-known.
Debian has the resources, infrastructure and quality that many of the smaller, newer, source distributions don't have. It has long-ago achieved critical mass. It has already been around for 10 years, and I can be reasonably certain it will be around for many more years. It is in no danger of being abandoned due to lack of interest, time, or funding; common problems with smaller projects. I don't have to worry about a mirror being down with Debian because there's always another one to pick and choose from.
Often, I hear of a new package and just want to quickly try it out. I'm far less likely to want to try it out if I have to wait a long time for it to compile. Sometimes I want the power and flexibility of a sourced-based distro, and sometimes I'd rather just download and be reasonably assured that it works fine the way it is from binaries.
The Debian package management system also offers clean uninstalls and reverse-dependency checking. I can uninstall a lot of non-essential stuff on a whim and not worry about breaking my system. I consider the safe and clean uninstallation and of software just as important, if not more so, than being able to merely install software.
Why APT-Fu? Why not use an existing source-building tool in Debian?
The source-building tools I've encountered in Debian have all had their strong points, but none of them had nearly all the features I wanted.
I wanted something that would let me install a package from source with one command: `apt-fu src-install pkg`
The ability to automatically modify the source code through simple configuration scripts with inline-patches: optFiles.
The ability to easily preserve my changes if I manually edited something: configurable auto-diff generation with the --prompt=pre-build option.
I also wanted to keep the scores of rarely used, and sometimes conflicting build-dependencies off my system: --no-keep-builddeps, the the default setting
apt-fu can also decide which build-dependencies to build from source, choosing only the ones with static libraries or objects in them. It won't build every single build-dependency from source because the resulting binaries won't benefit from it: (--recursive|-R option)
Furthermore, I wanted something that would work on the latest 'stable' distribution (3.0, at the time of writing). Correctly selecting the default source package version and build-deps is important to me since I keep unstable deb-src lines in the sources.list for my stable machine in case I need a backport done to stable: `apt-fu src-policy pkg` to check.
Slashdot Mirror
Glad to make your aquaintance, Mr. Ritchie!
I'm writing one in Ruby, and a BINARY clock in shell, awk and dd!
Re: The OS wars and DOOM...
To: Phil Fraering
Subject: Re: The OS wars and DOOM...
From: Andrew Loewenstern
Date: Fri, 21 Jul 95 18:17:12 -0500
Cc: cypherpunks@toad.com Sender: owner-cypherpunks@toad.com
> Apps have migrated from Unix to the Mac and the PC before in the
> past. In the further past, this has included curses and
> other-types-of-text-control packages such as PC versions of Emacs
> and nethack and the like.
> Of course, this was not done with graphical programs; everyone
> knows that graphics isn't Unix's strong suit, and what it has is
> so different from the PC, etc., blah, blah,...
> Except that for the past two or three years, it's been WRONG.
> One of the hottest games on the PC, DOOM, was originally written
> in Nextstep (a Unix variant, and a ghetto even amidst the "ghetto"
> of Unix) and then ported to the PC.
Being a resident of the NeXTSTEP ghetto, please allow me to chime in. While Doom is written on NeXTSTEP boxes, that's about all the game itself has in
common with it. The game is carefully written in strict ANSI-C and any
portions that must be OS specific are separate. They have a VGA emulator
that allows them to run Doom on non-DOS boxes. All of the platform
independance comes from the discipline of the developers (who are extremely
talented, IMHO). In contrast, Lotus Improv was NeXT native and had to be
completely rewritten over a period of at least 3 years to get it to work on
Windoze.
The primary reason Id software (and Trilobyte among others) uses NeXTSTEP
(over DOS or any other unix environment) is because it lets them write
in-house tools like map and monster editors really fast (and really slick
too!). On any other platform it would take much more time and effort to
write the tools and they probably wouldn't be as nice either. Since these
tools aren't being sold to customers, it doesn't matter that they only run on
a dead-end niche software platform that costs $1000 per user (and $5k per
developer!!).
This strategy makes sense for a commercial video game where there is the
opportunity to save major amounts of time and effort through the use of
custom tools (and the incentive of major amounts of cash if it is
successful). However, this strategy definitely doesn't make sense when you
are talking about a cypherpunk donating their spare time to write a freeware
(or copyleft) crypto app. Better would be to just write the app for the
target platform or write it using an environment that is designed to be
platform independant (like Java).
andrew ...able to work cypherpunks relevance into virtually any thread......and uses
Python instead of NeXTSTEP when writing stuff that needs to be
platform-independant...
If I am not mistaken, DOOM was originally proto'd on NeXT Stations - so this would have some precedent and cultural continuity.
Orbital
Mind-Control
L^HMasers!
NSA, CIA or MOSSAD?
The target was Windows. They can get off - it was entrapment!
Thank you. Glad to see that your compassion is so all-encompassing.
...was meant as humor! Obviously increasing background disk activity is gonna suck juice outta yer battery like a Whitehouse intern...
I think it's a battery-saving feature for the new PowerBooks...
In my opinion, Luskin would eat a turd if he thought it came from Bushes ass.
On the occupation of Iraq!
This is Daryl Issa territory. Home to the recall, Pete Wilson, and manifest other horrors.
Funny how the rich white pigs in Scripps are burning it up.
Chula Vista and National City - with Democratic and non-white majorities, got no worry over the fires. 'Cept when the money is doled out county-wide - they'll get nothing again. Al paid-out to rebuild the 5-bedroom homes of retired naval officers outside Tierrasanta.
I get lazy nowadays, and have been pulling signed kernels from the adamantix project.
but it is just one more - required - interpreter for base functionality, on top of ash/bash and Perl.
It gets messy when something like this is so basic at the root of the dependancy tree.
I want a single purpose firewall, or http reverse proxy, or SMTP forwarder - Debian is often my choice for this kind of work.
I don't like putting compilers or heavy-duty interperter on these.
These are a start.
Python as a required part of the base install... Some will dance, others will puke.
Also, tiny root partitions w/ everything other than /bin /lib /etc mounted did not work w/ Ananconda - at least with RH 7x. You needed a couple hundred MBs free in / to install. This required some fancy "behind the scenes" work - from a console between installer stages - for me to get my 6.2 boxes up to 7.0.
Of course, if you throw the works into /dev/hda1 - there's no prob! Unless you are worried about local priv escalation and other *NIX security issues...
I have to say that I welcome these developments, but do not believe a merger is possible or desireable.
Debian is not defined by its technologies, but by its social contract - whch determines exactly what software and technologies can be included in the disrtibution. True, RedHat / Fedora shares a large intersection with the licensing philosophy and package base of Debian. What they do not share makes them wholly exclusive of eachother - at least from the Debian side of the picture.
This is not meant to be a damper on the technical and practical aspects of Anaconda/Apt! I am "champing at the bit" for this, myself! Think -- no more overriding dependancies after using alien - and subsequently breaking apt-get...
We use echo and dd. I have resorted to cat as a crutch.
I only wish I didn't encounter ridiculous speed problems with it...
BITTORRENT
BITTORRENT
BITTORRENT
!!!!!!!!!!!!!!!!
Is this stuff on Freenet yet? (Then no one will see it.... :-) )
Cool.
I didn't know that "Unique" was a synonym for "MicroSoft".
They are particularly oriented at servicing non-profits, education, etc., which is cool.
I like the combo of gandi.net/zoneedit.com for small networks at the mercy of telco residential service-levels.
From the Project Page:
Introduction to APT-Fu
Why?
Why not? And because I can. It'll eventually make my life easier with optFiles/patches which allow me to upgrade packages while keeping most/all of any customizations I make to the original source package intact. I appreciate the work Debian maintainers do, but sometimes I would like to add my own flavor to things.
Why Debian? Why not just use another source-based distribution?
Debian has thousands of software packages, more than any other distribution I know of. I can always fall back to using a binary package if I'm not in the mood a particular day to wait for the source to compile, especially if I only plan on using it occasionally.
Debian also distributes source code in an easy-to-download format with APT, just like every other source-based distribution. Not only that, Debian has been doing this long before source-based Linux distributions became well-known.
Debian has the resources, infrastructure and quality that many of the smaller, newer, source distributions don't have. It has long-ago achieved critical mass. It has already been around for 10 years, and I can be reasonably certain it will be around for many more years. It is in no danger of being abandoned due to lack of interest, time, or funding; common problems with smaller projects. I don't have to worry about a mirror being down with Debian because there's always another one to pick and choose from.
Often, I hear of a new package and just want to quickly try it out. I'm far less likely to want to try it out if I have to wait a long time for it to compile. Sometimes I want the power and flexibility of a sourced-based distro, and sometimes I'd rather just download and be reasonably assured that it works fine the way it is from binaries.
The Debian package management system also offers clean uninstalls and reverse-dependency checking. I can uninstall a lot of non-essential stuff on a whim and not worry about breaking my system. I consider the safe and clean uninstallation and of software just as important, if not more so, than being able to merely install software.
Why APT-Fu? Why not use an existing source-building tool in Debian?
The source-building tools I've encountered in Debian have all had their strong points, but none of them had nearly all the features I wanted.
I wanted something that would let me install a package from source with one command: `apt-fu src-install pkg`
The ability to automatically modify the source code through simple configuration scripts with inline-patches: optFiles.
The ability to easily preserve my changes if I manually edited something: configurable auto-diff generation with the --prompt=pre-build option.
I also wanted to keep the scores of rarely used, and sometimes conflicting build-dependencies off my system: --no-keep-builddeps, the the default setting
apt-fu can also decide which build-dependencies to build from source, choosing only the ones with static libraries or objects in them. It won't build every single build-dependency from source because the resulting binaries won't benefit from it: (--recursive|-R option)
Furthermore, I wanted something that would work on the latest 'stable' distribution (3.0, at the time of writing). Correctly selecting the default source package version and build-deps is important to me since I keep unstable deb-src lines in the sources.list for my stable machine in case I need a backport done to stable: `apt-fu src-policy pkg` to check.
1.2! Wooo Hoo! If they're original, image 'em off onto different media. dd, tar, whatever!