 | | | | | | |
| |
|
In lugnet.cad.dev, Lars C. Hassing wrote:
> The data contained in either environment variables or ini files
> should have exactly the same format.
I agree, and prefer <> around all tags.
> > > Quotation marks should not be necessay if we use the < >.
> >
> > You are right but I still would allow them for the rare case of
> > blanks at the end of a directory name.
>
> Trailing blanks are preserved in both env var and ini files.
> So I still don't think quotation marks are necessary...
Ah, but what about leading blanks. ;^) Nevermind, I don't think you
can create an absolute path that starts with leading blanks.
> I'm almost done writing the library and the LDrawSetup application.
> I want the library to be as simple as possible to use.
> Reading the env vars and ini files is platform independent,
> only the hunt for ini files goes into #ifdef's.
> I think having ldraw.ini in LDRAWDIR is contradictory, the hen and
> egg problem. To keep thing simple I would like to have only *one*
> ldraw.ini, and since we're going to have it in
> HOME/USERPROFILE/windir anyway to find the LDRAWDIR, I don't see any
> reason to spread it out.
> The hunt for ldraw.ini could be:
> Windows:
> %LDRAWINI%
> %USERPROFILE%\ldraw.ini
> %ALLUSERSPROFILE%\ldraw.ini
> %windir%\ldraw.ini
But wait. The reason given for looking in LDRAWDIR is for a central
networked LDRAW installation at a school. It'd be nice to have a
default ldraw.ini file at the central location that can be overridden
by one in a users home directory. This doesn't work for that scenario
because %WINDIR% is on the client PC, not on the server. However, you
still have the chicken/egg problem because you need an LDRAWDIR
setting somewhere on the client to find the LDRAWDIR on the server.
You can however limit the number of chickens by making LDRAWDIR the
only setting required to be set on the client pc.
Or are you promoting LDRAWINI as the one and only setting required to
be on the client? Should we depreciate the LDRAWDIR environment
variable since it can be set in the file found by the LDRAWINI hunt?
I don't like this. I think we can use LDRAWDIR if we're clever.
On windows the envronment variables are global. You don't get a
personal login script to set your own, so I'd look in USERPROFILE
first. Now an administrator can set the %LDRAWDIR% variable in the
\\PDC\netlogin\login.bat script for all users on an NT style domain.
That solves the chicken/egg problem for the centralized Windows
scenario and eliminates any need for an LDRAWINI variable.
So, how about this search strategy?
Windows:
%USERPROFILE%\ldraw.ini
%ALLUSERSPROFILE%\ldraw.ini
%LDRAWDIR%\ldraw.ini
%WINDIR%\ldraw.ini
Unix:
$HOME/.ldrawrc
$HOME/ldraw.ini
$LDRAWDIR/ldraw.ini
/etc/ldraw.ini
Mac OS X:
~/Library/Preferences/org.ldraw.plist
/Library/Preferences/org.ldraw.plist
$LDRAWDIR/ldraw.ini (I'm not sure about this one)
Obviously if you don't have LDRAWDIR set by an environment variable
you'll have to skip the step that looks in the LDRAWDIR.
Enjoy,
Don
| | | | | | | | | | | | | | | |
In lugnet.cad.dev, Don Heyse wrote:
> But wait. The reason given for looking in LDRAWDIR is for a central
> networked LDRAW installation at a school. It'd be nice to have a
> default ldraw.ini file at the central location that can be overridden
> by one in a users home directory.
Oh yeah. One other thing about an ldraw.ini located on a central server.
I'd prefer to leave the client OS up to the user. This reinforces my case
for the <LDRAWDIR>parts path format without the nasty OS specific slash
character.
Enjoy,
Don
| | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Don Heyse wrote:
> Oh yeah. One other thing about an ldraw.ini located on a central server.
> I'd prefer to leave the client OS up to the user. This reinforces my case
> for the <LDRAWDIR>parts path format without the nasty OS specific slash
> character.
It's no problem handling the \ or /'s.
We do that all the time already in our parts referencing e.g. S\3039S01.DAT,
we do manage to find the subpart on unix too :-)
My library reads env vars and ini files in any format
and converts it to the format used on the platform it is running.
/Lars
| | | | | | | | | | | | | | | | | | | |
| |
|
"Don Heyse" <dheyse@hotmail.spam.go.away.com> schrieb im Newsbeitrag
news:Hu0CMF.1Fyv@lugnet.com...
> In lugnet.cad.dev, Lars C. Hassing wrote:
> > The data contained in either environment variables or ini files
> > should have exactly the same format.
>
> I agree, and prefer <> around all tags.
Ok, agreed too. So with have <HIDE> and optionally <SHOW> - right?
>
> > > > Quotation marks should not be necessay if we use the < >.
> > >
> > > You are right but I still would allow them for the rare case of
> > > blanks at the end of a directory name.
> >
> > Trailing blanks are preserved in both env var and ini files.
> > So I still don't think quotation marks are necessary...
>
> Ah, but what about leading blanks. ;^) Nevermind, I don't think you
> can create an absolute path that starts with leading blanks.
I would still like the quotation marks as an option - not a must. If a user
uses them fine, if not also fine - if there is a problem with blanks or tabs
the user can still use quotation marks.
<SNIP>
> So, how about this search strategy?
>
> Windows:
> %USERPROFILE%\ldraw.ini
> %ALLUSERSPROFILE%\ldraw.ini
> %LDRAWDIR%\ldraw.ini
> %WINDIR%\ldraw.ini
That would be a perfect way I guess. MLCad also allows to let the user
specify the ldraw dir manualy in a dialog. I could imagine having this
option as an emergency solution if no ldraw dir can be found.
>
> Unix:
> $HOME/.ldrawrc
> $HOME/ldraw.ini
> $LDRAWDIR/ldraw.ini
> /etc/ldraw.ini
>
> Mac OS X:
> ~/Library/Preferences/org.ldraw.plist
> /Library/Preferences/org.ldraw.plist
> $LDRAWDIR/ldraw.ini (I'm not sure about this one)
no idea about Mac's but unix looks good.
>
> Obviously if you don't have LDRAWDIR set by an environment variable
> you'll have to skip the step that looks in the LDRAWDIR.
Or open a dialog to ask the user for this path once, my feeling is if the
user didn't setup the variable - the user will not modify the ldraw.ini file
either - at least that is what I learned from houndreds of support requests
from MLCad users.
Michael
| | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Michael Lachmann wrote:
> > I agree, and prefer <> around all tags.
>
> Ok, agreed too. So with have <HIDE> and optionally <SHOW> - right?
Sure.
> > > > > Quotation marks should not be necessay if we use the < >.
> > > >
> > > > You are right but I still would allow them for the rare case of
> > > > blanks at the end of a directory name.
> > >
> > > Trailing blanks are preserved in both env var and ini files.
> > > So I still don't think quotation marks are necessary...
> >
> > Ah, but what about leading blanks. ;^) Nevermind, I don't think you
> > can create an absolute path that starts with leading blanks.
>
> I would still like the quotation marks as an option - not a must. If a user
> uses them fine, if not also fine - if there is a problem with blanks or tabs
> the user can still use quotation marks.
OK.
> <SNIP>
> > So, how about this search strategy?
> >
> > Windows:
> > %USERPROFILE%\ldraw.ini
> > %ALLUSERSPROFILE%\ldraw.ini
> > %LDRAWDIR%\ldraw.ini
> > %WINDIR%\ldraw.ini
>
> That would be a perfect way I guess. MLCad also allows to let the user
> specify the ldraw dir manualy in a dialog. I could imagine having this
> option as an emergency solution if no ldraw dir can be found.
Fine.
> Or open a dialog to ask the user for this path once, my feeling is if the
> user didn't setup the variable - the user will not modify the ldraw.ini file
> either - at least that is what I learned from houndreds of support requests
> from MLCad users.
I think so too.
Users will also have the option to use the new app LDrawSetup,
which can setup LDrawDir, SearchDirs, LgeoDirectory, MIME-types.
/Lars
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Lars C. Hassing wrote:
> > Trailing blanks are preserved in both env var and ini files.
> > So I still don't think quotation marks are necessary...
>
> Ah, but what about leading blanks. ;^) Nevermind, I don't think you
> can create an absolute path that starts with leading blanks.
No, but leading blanks would be preserved as well...
> > I think having ldraw.ini in LDRAWDIR is contradictory, the hen and
> > egg problem. To keep thing simple I would like to have only *one*
> > ldraw.ini, and since we're going to have it in
> > HOME/USERPROFILE/windir anyway to find the LDRAWDIR, I don't see any
> > reason to spread it out.
>
> > The hunt for ldraw.ini could be:
> > Windows:
> > %LDRAWINI%
> > %USERPROFILE%\ldraw.ini
> > %ALLUSERSPROFILE%\ldraw.ini
> > %windir%\ldraw.ini
>
> But wait. The reason given for looking in LDRAWDIR is for a central
> networked LDRAW installation at a school. It'd be nice to have a
> default ldraw.ini file at the central location that can be overridden
> by one in a users home directory.
Isn't that what %ALLUSERSPROFILE% is for?
> Or are you promoting LDRAWINI as the one and only setting required to
> be on the client? Should we depreciate the LDRAWDIR environment
> variable since it can be set in the file found by the LDRAWINI hunt?
> I don't like this. I think we can use LDRAWDIR if we're clever.
LDRAWINI is just an opportunity for quickly temporarily using another
specific ldraw.ini file.
/Lars
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Lars C. Hassing wrote:
> In lugnet.cad.dev, Don Heyse wrote:
> > In lugnet.cad.dev, Lars C. Hassing wrote:
> > > I think having ldraw.ini in LDRAWDIR is contradictory, the hen and
> > > egg problem. To keep thing simple I would like to have only *one*
> > > ldraw.ini, and since we're going to have it in
> > > HOME/USERPROFILE/windir anyway to find the LDRAWDIR, I don't see any
> > > reason to spread it out.
> >
> > > The hunt for ldraw.ini could be:
> > > Windows:
> > > %LDRAWINI%
> > > %USERPROFILE%\ldraw.ini
> > > %ALLUSERSPROFILE%\ldraw.ini
> > > %windir%\ldraw.ini
> >
> > But wait. The reason given for looking in LDRAWDIR is for a central
> > networked LDRAW installation at a school. It'd be nice to have a
> > default ldraw.ini file at the central location that can be overridden
> > by one in a users home directory.
>
> Isn't that what %ALLUSERSPROFILE% is for?
I'm logged onto an NT domain right now at work and it's set to this:
ALLUSERSPROFILE=C:\Documents and Settings\All Users
That's on the local drive. But I suppose you're right, a competent
administrator could set it up somewhere on the network. What does a
typical networked Windows installation look like? My USERPROFILE
and ALLUSERSPROFILE are on the C drive, but the "My Documents" folder
on the start menu is mapped to a location on the network via the
"%USERPROFILE%\Start Menu\Shortcut to My Documents.lnk" file. I suspect
the admins created that lnk via the login script, but I'm not positive.
> LDRAWINI is just an opportunity for quickly temporarily using another
> specific ldraw.ini file.
I don't think I'll ever use it because it confuses me. If you have
both LDRAWDIR and LDRAWINI environment variables set, which setting
do you use to determine the LDRAWDIR: the LDRAWDIR environment var,
or the BaseDirectory setting in $LDRAWINI/ldraw.ini? If you have a
particularly evil Windows administrator who points both LDRAWINI and
LDRAWDIR to his undesireable parts directories, how does the poor
Windows user go about overriding it?
Don
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Lars C. Hassing wrote:
> > In lugnet.cad.dev, Don Heyse wrote:
> > > In lugnet.cad.dev, Lars C. Hassing wrote:
> > > > I think having ldraw.ini in LDRAWDIR is contradictory, the hen and
> > > > egg problem. To keep thing simple I would like to have only *one*
> > > > ldraw.ini, and since we're going to have it in
> > > > HOME/USERPROFILE/windir anyway to find the LDRAWDIR, I don't see any
> > > > reason to spread it out.
> > >
> > > > The hunt for ldraw.ini could be:
> > > > Windows:
> > > > %LDRAWINI%
> > > > %USERPROFILE%\ldraw.ini
> > > > %ALLUSERSPROFILE%\ldraw.ini
> > > > %windir%\ldraw.ini
> > >
> > > But wait. The reason given for looking in LDRAWDIR is for a central
> > > networked LDRAW installation at a school. It'd be nice to have a
> > > default ldraw.ini file at the central location that can be overridden
> > > by one in a users home directory.
> >
> > Isn't that what %ALLUSERSPROFILE% is for?
>
> I'm logged onto an NT domain right now at work and it's set to this:
>
> ALLUSERSPROFILE=C:\Documents and Settings\All Users
>
> That's on the local drive. But I suppose you're right, a competent
> administrator could set it up somewhere on the network. What does a
> typical networked Windows installation look like? My USERPROFILE
> and ALLUSERSPROFILE are on the C drive, but the "My Documents" folder
> on the start menu is mapped to a location on the network via the
> "%USERPROFILE%\Start Menu\Shortcut to My Documents.lnk" file. I suspect
> the admins created that lnk via the login script, but I'm not positive.
>
> > LDRAWINI is just an opportunity for quickly temporarily using another
> > specific ldraw.ini file.
>
> I don't think I'll ever use it because it confuses me. If you have
> both LDRAWDIR and LDRAWINI environment variables set, which setting
> do you use to determine the LDRAWDIR: the LDRAWDIR environment var,
> or the BaseDirectory setting in $LDRAWINI/ldraw.ini? If you have a
> particularly evil Windows administrator who points both LDRAWINI and
> LDRAWDIR to his undesireable parts directories, how does the poor
> Windows user go about overriding it?
Seems to me programs need the ability to specify the LDRAWINI directory (and
possibly LDRAWDIR) on the command line, for non-standard setups.
Maybe the library needs an Ldraw-specific getopt[1] function as well.
ROSCO
[1] http://www.rt.com/man/getopt.3.html
| | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Ross Crawford wrote:
> Seems to me programs need the ability to specify the LDRAWINI directory
> (and possibly LDRAWDIR) on the command line, for non-standard setups.
I'm not sure what you're trying to say. Do you mean "USERS need the
ability to specify", or "programs need the ability to READ"? Either way,
that approach is for advanced users (software geeks) only. We're trying
to improve things for ordinary users, and forcing them run a command
prompt to use their preferred non-standard settings in their LDRAW
programs is just wrong. Even for an advanced user, how is this better
than just setting an environment variable right before running the
program?
Don
| | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Ross Crawford wrote:
> > Seems to me programs need the ability to specify the LDRAWINI directory
> > (and possibly LDRAWDIR) on the command line, for non-standard setups.
>
> I'm not sure what you're trying to say. Do you mean "USERS need the
> ability to specify", or "programs need the ability to READ"? Either way,
> that approach is for advanced users (software geeks) only. We're trying
> to improve things for ordinary users, and forcing them run a command
> prompt to use their preferred non-standard settings in their LDRAW
> programs is just wrong. Even for an advanced user, how is this better
> than just setting an environment variable right before running the
> program?
And I'm pretty sure on Mac OS X, if you use the finder to activate
your program, you have no control whatsoever over the command line.
So you already need another way if you want to click on a LDR file
or link and have something happen.
Don
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Ross Crawford wrote:
> > Seems to me programs need the ability to specify the LDRAWINI directory
> > (and possibly LDRAWDIR) on the command line, for non-standard setups.
>
> I'm not sure what you're trying to say. Do you mean "USERS need the
> ability to specify", or "programs need the ability to READ"?
Well to be usable, both must be implemented.
> Either way,
> that approach is for advanced users (software geeks) only. We're trying
> to improve things for ordinary users, and forcing them run a command
> prompt to use their preferred non-standard settings in their LDRAW
> programs is just wrong. Even for an advanced user, how is this better
> than just setting an environment variable right before running the
> program?
As I said it would only be for non-standard setups. I think the Lars' search
list is ample for the vast majority of people.
Those using networks, etc, probably would classify as "advanced users" or need
help from their network administrators to set stuff up anyway, so creating a
shortcut (or whatever for their platform) with command line parameters is
probably not gonna be a big issue.
I think trying to get a solution that works automatically for every environment
is next to impossible, this would cater for those that "dont fit the mold".
ROSCO
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Ross Crawford wrote:
> In lugnet.cad.dev, Don Heyse wrote:
> > In lugnet.cad.dev, Ross Crawford wrote:
> > > Seems to me programs need the ability to specify the LDRAWINI directory
> > > (and possibly LDRAWDIR) on the command line, for non-standard setups.
> >
> > That approach is for advanced users (software geeks) only. We're trying
> > to improve things for ordinary users, and forcing them run a command
> > prompt to use their preferred non-standard settings in their LDRAW
> > programs is just wrong. Even for an advanced user, how is this better
> > than just setting an environment variable right before running the
> > program?
>
> As I said it would only be for non-standard setups. I think the Lars'
> search list is ample for the vast majority of people.
>
> Those using networks, etc, probably would classify as "advanced users"
> or need help from their network administrators to set stuff up anyway,
> so creating a shortcut (or whatever for their platform) with command
> line parameters is probably not gonna be a big issue.
>
> I think trying to get a solution that works automatically for every
> environment is next to impossible, this would cater for those that
> "dont fit the mold".
Ok, I can see where I myself might use this in a pinch because I
almost always run things from the command prompt. However, even I
would rather set an environment variable or use some other global
setting in an ini file. Why? Because if I use the commandline
shortcut, or script file, I have to duplicate the same setting (perhaps
with a different syntax) for every LDRAW program I want to use. That's
exactly what we're trying to avoid here. We want a way for all the
LDRAW programs to easily SHARE the SAME settings.
But hey, if you're only interested in one program then maybe a command
line option is for you. Which program were you thinking of, and what
sort of command line syntax are we talking about? Might as well flesh
the idea out.
Don
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Ross Crawford wrote:
> > In lugnet.cad.dev, Don Heyse wrote:
> > > In lugnet.cad.dev, Ross Crawford wrote:
> > > > Seems to me programs need the ability to specify the LDRAWINI directory
> > > > (and possibly LDRAWDIR) on the command line, for non-standard setups.
> > >
> > > That approach is for advanced users (software geeks) only. We're trying
> > > to improve things for ordinary users, and forcing them run a command
> > > prompt to use their preferred non-standard settings in their LDRAW
> > > programs is just wrong. Even for an advanced user, how is this better
> > > than just setting an environment variable right before running the
> > > program?
> >
> > As I said it would only be for non-standard setups. I think the Lars'
> > search list is ample for the vast majority of people.
> >
> > Those using networks, etc, probably would classify as "advanced users"
> > or need help from their network administrators to set stuff up anyway,
> > so creating a shortcut (or whatever for their platform) with command
> > line parameters is probably not gonna be a big issue.
> >
> > I think trying to get a solution that works automatically for every
> > environment is next to impossible, this would cater for those that
> > "dont fit the mold".
>
> Ok, I can see where I myself might use this in a pinch because I
> almost always run things from the command prompt. However, even I
> would rather set an environment variable or use some other global
> setting in an ini file. Why? Because if I use the commandline
> shortcut, or script file, I have to duplicate the same setting (perhaps
> with a different syntax) for every LDRAW program I want to use. That's
> exactly what we're trying to avoid here. We want a way for all the
> LDRAW programs to easily SHARE the SAME settings.
>
> But hey, if you're only interested in one program then maybe a command
> line option is for you. Which program were you thinking of, and what
> sort of command line syntax are we talking about? Might as well flesh
> the idea out.
Well I don't know how mac command lines work but I was thinking along these
lines:
Windoze:
xxx.exe /LDRAWDIR=C:\LDRAW /LDRAWINI=\\LDRAW_BOX\INI
Unix:
xxx --ldrawdir ${HOME}/ldraw --ldrawini /etc/ldraw
You might also wanna provide old single letter switches -d & -i or something.
If this could be handled by a platform independent library, then any or all of
the Ldraw suite programs could easily parse these options.
ROSCO
| | | | | | | | | | | | | | | | | |
"Ross Crawford" <rosscraw@bigpond.net.au> schrieb im Newsbeitrag
news:Hu4L6M.1Eyo@lugnet.com...
<SNIP>
> Well I don't know how mac command lines work but I was thinking along • these
> lines:
>
> Windoze:
> xxx.exe /LDRAWDIR=C:\LDRAW /LDRAWINI=\\LDRAW_BOX\INI
in some cases "xxx.exe /LDRAWDIR=C:/LDRAW /LDRAWINI=\\LDRAW_BOX/INI will
work too.
There is no standard function set in windows parsing this commands, every
program can do that how it likes. e.g. you could replace the = by a white
space.
Michael
| | | | | | | | | | | | | | | | | | |
| |
|
> Well I don't know how mac command lines work but I was thinking along these
> lines:
>
> Windoze:
> xxx.exe /LDRAWDIR=C:\LDRAW /LDRAWINI=\\LDRAW_BOX\INI
>
> Unix:
> xxx --ldrawdir ${HOME}/ldraw --ldrawini /etc/ldraw
Mac OS 9 does not have a command line. That OS is a dinosaur.
You can think of Mac OS X as a decendant of BSD, with a Mac OS 9 look-a-like
window server. In fact, you can remove Apple's window server and add X11,
turning Mac OS X into just another Unix.
Also, the Unix core of Mac OS X (Darwin) is open source (headed by Jordan
Hubbard, creator of FreeBSD) and can be installed on a PC (x86). You can't
install Apple's window server though. But you can install X11.
http://www.opendarwin.org/
So, just think of OS X as just another UNIX.
The biggest difference between Mac OS X and other Unixes is the users. Mac OS X
users are very untechnical compared to other Unix users. It would be a bad idea
to require them to use the command line. They wont even know what you are
talking about.
James
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, James Reynolds wrote:
> > Well I don't know how mac command lines work but I was thinking along these
> > lines:
> >
> > Windoze:
> > xxx.exe /LDRAWDIR=C:\LDRAW /LDRAWINI=\\LDRAW_BOX\INI
> >
> > Unix:
> > xxx --ldrawdir ${HOME}/ldraw --ldrawini /etc/ldraw
>
> Mac OS 9 does not have a command line. That OS is a dinosaur.
[snip]
> So, just think of OS X as just another UNIX.
>
> The biggest difference between Mac OS X and other Unixes is the users. Mac OS X
> users are very untechnical compared to other Unix users. It would be a bad idea
> to require them to use the command line. They wont even know what you are
> talking about.
Again, I'm not talking about most users - most will be covered by the search
paths proposed earlier in the thread. This would only be for non-standard
installations, where the people installing WOULD be likely to know what I am
talking about.
The only reason I proposed this idea is so the parts & ini file location is
"open-ended" - to provide the ultimate flexibility for those that want to abuse
it. If you create a closed list of options, sure as eggs someone will come along
later saying "but how do I get it to work THIS way?". Better to allow for that
eventuality from the start, IMO.
ROSCO
| | | | | | | | | | | | | | | | | | | | | |
| |
|
> > The biggest difference between Mac OS X and other Unixes is the users. Mac OS X
> > users are very untechnical compared to other Unix users. It would be a bad idea
> > to require them to use the command line. They wont even know what you are
> > talking about.
>
> Again, I'm not talking about most users - most will be covered by the search
> paths proposed earlier in the thread. This would only be for non-standard
> installations, where the people installing WOULD be likely to know what I am
> talking about.
>
> The only reason I proposed this idea is so the parts & ini file location is
> "open-ended" - to provide the ultimate flexibility for those that want to abuse
> it. If you create a closed list of options, sure as eggs someone will come along
> later saying "but how do I get it to work THIS way?". Better to allow for that
> eventuality from the start, IMO.
Right. I actually manage 350 Macs and I tried to put LDraw on them and ran into
several problems that I had to take up with the Mac developers. So anything
that makes this easier for admins is good in my opinion.
| | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, James Reynolds wrote:
> Mac OS 9 does not have a command line. That OS is a dinosaur.
rofl. I think this qualifies as quote of the day.
Steve
| | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Steve Bliss wrote:
> In lugnet.cad.dev, James Reynolds wrote:
>
> > Mac OS 9 does not have a command line. That OS is a dinosaur.
>
> rofl. I think this qualifies as quote of the day.
Ok, so maybe there was a bit of irony, considering Mac OS X's roots are much
older than 9's. But the lack of pre-emptive multiprocessing, protected memory,
and other more evolved stuff does make OS 9 a dinosaur. Apple's washed their
hands of the OS. One of the funnies thing I saw about this was the Mac OS 9's
technical lead talk about the future of Mac OS 9 *after* the release of Mac OS
X.
http://homepage.mac.com/stattenf/FutureOfMacOS9/
audio is kinda bad though :(
James
| | | | | | |
