OS X Finder windows vs terminal window weirdness
winston...@yahoo.com
matter.
The next paragraph really isn't necessary to the issue, but just a
background.
I had specified the incorrect target, and had tried "make distclean"
which returned an error 1 and tried "rm config.cache" in the gcc
directory, but the make kept coming back saying my previous target
didn't match the current and telling me to do the two things I just
mentioned.
Both my terminal window and the Finder are in the same directory ../
build-gcc/gcc. I decide to delete the directory gcc (and any in it) by
using the Finder. Voila! Gone. I try to recompile and make the
compiler again, and receive same error as previous paragraph. Delete
stuff again in Finder. Gone. Do an ls in the terminal.
What?!?!?! Terminal shows a list of files, Finder does not. Do a pwd
to check the current dir in terminal, check it in finder. Same
directory. Go up a level in Finder, then back to gcc. Nothing there.
Do an ls on gcc in terminal - still shows files. Do a "cd .." then "cd
gcc" in terminal, then an "ls" - files are no longer there...
Ok, somebody explain this to me...
Greg Menke
"winston...@yahoo.com" <winston...@yahoo.com> writes:
>
> Both my terminal window and the Finder are in the same directory ../
> build-gcc/gcc. I decide to delete the directory gcc (and any in it) by
> using the Finder. Voila! Gone. I try to recompile and make the
> compiler again, and receive same error as previous paragraph. Delete
> stuff again in Finder. Gone. Do an ls in the terminal.
>
> What?!?!?! Terminal shows a list of files, Finder does not. Do a pwd
> to check the current dir in terminal, check it in finder. Same
> directory. Go up a level in Finder, then back to gcc. Nothing there.
> Do an ls on gcc in terminal - still shows files. Do a "cd .." then "cd
> gcc" in terminal, then an "ls" - files are no longer there...
>
> Ok, somebody explain this to me...
Finder is brain-damaged in lots of ways. It treats directories in
various magic ways- I'd rather have Windows Explorer. For anything but
click & drool I wouldn't touch finder. OSX is often hard to compile
things for.
Your error sounds sort-of like automake/autoconf/m4 have version
problems. gcc is occasionally very sensitive to having the right
versions installed.
Gregm
John Varela
(in article
<3dcfd183-8eaa-4a78...@8g2000hse.googlegroups.com>):
> Ok, I'm trying to build gcc. OS X 10.4.9 or whatever, doesn't really matter.
This post belongs in comp.sys.mac.*
--
John Varela
Trade NEW lamps for OLD for email.
winston...@yahoo.com
> On Mon, 9 Jun 2008 03:41:03 -0400, winston19842...@yahoo.com wrote
> (in article
> <3dcfd183-8eaa-4a78-ab89-1a9ded59a...@8g2000hse.googlegroups.com>):
>
> > Ok, I'm trying to build gcc. OS X 10.4.9 or whatever, doesn't really matter.
>
> This post belongs in comp.sys.mac.*
First, there is nothing off topic in alt.folklore.computers.
Second, if I wanted mac fanboys to "dazzle" me with their knowledge
and then have the mac-haters attack me for being stupid even owing a
mac, yes I would post it on comp.sys.mac.*
Third, I wanted the opinion of seasoned professionals as well - people
who aren't just getting their first "computer appliance - in regards
to such weirdness between the GUI and the command prompt of the
machine.
Thank you for your opinion - when I want it, I will ask you, hmm?
Charlton Wilbur
w> First, there is nothing off topic in alt.folklore.computers.
You've been watching the political asshattery for too long.
afc is for discussing computers that are more than 20 years old.
w> Third, I wanted the opinion of seasoned professionals as well -
w> people who aren't just getting their first "computer appliance -
w> in regards to such weirdness between the GUI and the command
w> prompt of the machine.
And your attitude has just ensured that you won't get it.
Charlton
--
Charlton Wilbur
cwi...@chromatico.net
winston...@yahoo.com
> >>>>> "w" == winston19842005@yahoo com <winston19842...@yahoo.com> writes:
>
> w> First, there is nothing off topic in alt.folklore.computers.
>
> You've been watching the political asshattery for too long.
>
> afc is for discussing computers that are more than 20 years old.
>
> w> Third, I wanted the opinion of seasoned professionals as well -
> w> people who aren't just getting their first "computer appliance -
> w> in regards to such weirdness between the GUI and the command
> w> prompt of the machine.
>
> And your attitude has just ensured that you won't get it.
>
> Charlton
>
Oh, please, Charlton...
What is on-topic about Barb's issues with her Mac? Or are you not a
part of the "Definition of file spec in commands" thread?
stre...@rohan.sdsu.edu
[snip]
> Oh, please, Charlton...
>
> What is on-topic about Barb's issues with her Mac? Or are you not a
> part of the "Definition of file spec in commands" thread?
The computer we're programming there lies between her ears.
--
--Stewart Stremler----------------...@rohan.sdsu.edu--
"Some folks you don't have to satirize, you just quote 'em." -- Tom Paxton
stre...@rohan.sdsu.edu
> to check the current dir in terminal, check it in finder. Same
> directory. Go up a level in Finder, then back to gcc. Nothing there.
> Do an ls on gcc in terminal - still shows files. Do a "cd .." then "cd
> gcc" in terminal, then an "ls" - files are no longer there...
>
> Ok, somebody explain this to me...
You're simply not paying attention.
When you delete something in the finder, what do you do?
You "move it to the trash".
If you open the trash in the finder, you'll be able to see your files.
This has been standard Mac behavior for how many years?* Of course,
the early macs didn't have terminal (so far as I know, I was an Amiga
zealot back then, and scoffed at the Macs cooperative multitasking and
lack of a CLI) windows.
* HA! On topic!
--
--Stewart Stremler----------------...@rohan.sdsu.edu--
What you gains in convenience you loses in compost. --Nanny Ogg
Roland Hutchinson
> begin quoting winston...@yahoo.com <winston...@yahoo.com> :
> [snip]
>> Oh, please, Charlton...
>>
>> What is on-topic about Barb's issues with her Mac? Or are you not a
>> part of the "Definition of file spec in commands" thread?
>
> The computer we're programming there lies between her ears.
...and is more than 20 years old.
--
Roland Hutchinson Will play viola da gamba for food.
NB mail to my.spamtrap [at] verizon.net is heavily filtered to
remove spam. If your message looks like spam I may not see it.
winston...@yahoo.com
> begin quoting winston19842...@yahoo.com <winston19842...@yahoo.com> :
> [snip]
>
> > What?!?!?! Terminal shows a list of files, Finder does not. Do a pwd
> > to check the current dir in terminal, check it in finder. Same
> > directory. Go up a level in Finder, then back to gcc. Nothing there.
> > Do an ls on gcc in terminal - still shows files. Do a "cd .." then "cd
> > gcc" in terminal, then an "ls" - files are no longer there...
>
> > Ok, somebody explain this to me...
>
> You're simply not paying attention.
>
> When you delete something in the finder, what do you do?
>
> You "move it to the trash".
>
> If you open the trash in the finder, you'll be able to see your files.
>
> This has been standard Mac behavior for how many years?* Of course,
> the early macs didn't have terminal (so far as I know, I was an Amiga
> zealot back then, and scoffed at the Macs cooperative multitasking and
> lack of a CLI) windows.
>
> * HA! On topic!
Too bad you weren't paying attention. I _know_ where the files go from
the Finder. I delete everything in the "gcc" directory, thereby moving
all the files in the gcc directory, everything in it (including
subdirectories) into the trash.
But the terminal prompt still sees the files there, until you "cd .."
and "cd gcc" again. That is the part that is confusing.
If I try a similar test in Windows XP, I get what I expect - a
listing of no files in the directory after a delete (move to recycle
bin) of everything in the test directory.
Pascal J. Bourguignon
> On Jun 11, 3:18 am, strem...@rohan.sdsu.edu wrote:
>> begin quoting winston19842...@yahoo.com <winston19842...@yahoo.com> :
>> [snip]
>>
>> > What?!?!?! Terminal shows a list of files, Finder does not. Do a pwd
>> > to check the current dir in terminal, check it in finder. Same
>> > directory. Go up a level in Finder, then back to gcc. Nothing there.
>> > Do an ls on gcc in terminal - still shows files. Do a "cd .." then "cd
>> > gcc" in terminal, then an "ls" - files are no longer there...
>>
>> > Ok, somebody explain this to me...
>>
>> You're simply not paying attention.
>>
>> When you delete something in the finder, what do you do?
>>
>> You "move it to the trash".
>>
>> If you open the trash in the finder, you'll be able to see your files.
>>
>> This has been standard Mac behavior for how many years?* Of course,
>> the early macs didn't have terminal (so far as I know, I was an Amiga
>> zealot back then, and scoffed at the Macs cooperative multitasking and
>> lack of a CLI) windows.
>>
>> * HA! On topic!
>
> Too bad you weren't paying attention. I _know_ where the files go from
> the Finder. I delete everything in the "gcc" directory, thereby moving
> all the files in the gcc directory, everything in it (including
> subdirectories) into the trash.
So what did you do? Did you "delete" or did you move the "gcc"
directory to the /.Trash directory?
If you selected the items in the "gcc" directory and typed
Command-DELETE, they would get unlinked immediately from the "gcc"
directory, and a subsequent ls would show no remaining items there.
> But the terminal prompt still sees the files there, until you "cd .."
> and "cd gcc" again. That is the part that is confusing.
This is because your current working directory is still that "gcc"
directory that you moved to the /.Trash directory.
Note that "cd .." may have two interpretation, depending on the shell
you use. In some shell, the built-in cd command interprets the .. as
to remove one item in the last path passed to chdir(2), and call
chdir(2) again with this new path (this is what you get here). In
other shells, perhaps coarser but truer, cd .. is implemented just as
chdir(".."). With such a shell cd .. ; pwd would give you '/.Trash'.
The behavior of your shell is justified by symbolic-links.
--
__Pascal Bourguignon__
winston...@yahoo.com
wrote:
Thanks - that makes _some_ sense. I'm pretty sure I did a pwd but
didn't see "Trash" in the result...
I also thought I'd deleted the stuff in gcc and below, but it sounds
like I deleted "gcc" (a viable alternative) and took a ride with it
into the Trashcan.
This is something Windows will not allow you to do... tried that
earlier and you get a dialog box stating it is in use...
Walter Bushell
wrote:
> begin quoting winston...@yahoo.com <winston...@yahoo.com> :
> [snip]
> > Oh, please, Charlton...
> >
> > What is on-topic about Barb's issues with her Mac? Or are you not a
> > part of the "Definition of file spec in commands" thread?
>
> The computer we're programming there lies between her ears.
Ah, so it is appropriate to this newsgroup.
--
What is done in the heat of battle is (normatively) judged
by different standards than what is leisurely planned in
comfortable conference rooms.
Walter Bushell
Roland Hutchinson <my.sp...@verizon.net> wrote:
> stre...@rohan.sdsu.edu wrote:
>
> > begin quoting winston...@yahoo.com <winston...@yahoo.com> :
> > [snip]
> >> Oh, please, Charlton...
> >>
> >> What is on-topic about Barb's issues with her Mac? Or are you not a
> >> part of the "Definition of file spec in commands" thread?
> >
> > The computer we're programming there lies between her ears.
>
> ...and is more than 20 years old.
More to the point the OS hasn't been upgraded in the past 20.
stre...@rohan.sdsu.edu
Oh, I was paying attention. I just can't read minds, and I refuse to try.
> I _know_ where the files go from
> the Finder. I delete everything in the "gcc" directory, thereby moving
> all the files in the gcc directory, everything in it (including
> subdirectories) into the trash.
Yup.
Everything. Including your point-of-perception.
What might really bake your noodle is the idea that I can delete a file,
and a program can continue reading from the file after the file has been
deleted.
> But the terminal prompt still sees the files there, until you "cd .."
> and "cd gcc" again. That is the part that is confusing.
Ah.... What shell are you using?
If "cd .." doesn't bring you into ~/.Trash, I'd consider your shell to
be broken.
> If I try a similar test in Windows XP, I get what I expect - a
> listing of no files in the directory after a delete (move to recycle
> bin) of everything in the test directory.
But... you were "in" the directory that got moved. Why didn't you move
with it?
--
Stewart Stremler stre...@rohan.sdsu.edu
-----------------------------------------------------------------------------
Sendmail may be safely run set-user-id to root.
-- Eric Allman, "Sendmail Installation Guide"
Roland Hutchinson
> In article <UEL3k.496$n9.122@trndny01>,
> Roland Hutchinson <my.sp...@verizon.net> wrote:
>
>> stre...@rohan.sdsu.edu wrote:
>>
>> > begin quoting winston...@yahoo.com <winston...@yahoo.com> :
>> > [snip]
>> >> Oh, please, Charlton...
>> >>
>> >> What is on-topic about Barb's issues with her Mac? Or are you not a
>> >> part of the "Definition of file spec in commands" thread?
>> >
>> > The computer we're programming there lies between her ears.
>>
>> ...and is more than 20 years old.
>
> More to the point the OS hasn't been upgraded in the past 20.
Exactly. We're trying to interface new peripherals to an old OS, by
tweaking the code of a running monitor on the fly.
We may yet have to rip everything out down to the microcode, but it hasn't
come to that yet!
(Say, where is Barb today, anyway? We had a nasty storm front roll through
the northeastern US last night; maybe she's off the grid today.)
Greg Menke
"winston...@yahoo.com" <winston...@yahoo.com> writes:
> Thanks - that makes _some_ sense. I'm pretty sure I did a pwd but
> didn't see "Trash" in the result...
> I also thought I'd deleted the stuff in gcc and below, but it sounds
> like I deleted "gcc" (a viable alternative) and took a ride with it
> into the Trashcan.
You could well have been the deleted directory- your shell's working
directory being the last "link" to the deleted tree. Probaby you will
not see any files in there if you ls them and would get errors trying to
create things in it. This is a nuance of filesystem different from
Windows (which brings in its own share of different issues). This
apparently weird behavior is a manifestation of how *nix handles removal
of files, which has its uses in other circumstances.
Generally its better to avoid doing anything in Finder that relates to
something you're doing in a terminal window. Windows & OSX share the
fiction of a "trashcan"- its all make-believe since whats happening is
really a move instead of a delete, but rm in a terminal is really
delete.
I'd suggest that if you're doing something in a terminal, then do your
file management there (or at least use a file management app run from
the terminal- midnight commander or equiv). If you're doing click and
drool in the gui, then messing around with Finder is more appropriate.
> This is something Windows will not allow you to do... tried that
> earlier and you get a dialog box stating it is in use...
Shrug... different strokes for different operating sytems.
Gregm
winston...@yahoo.com
> begin quoting winston19842...@yahoo.com <winston19842...@yahoo.com> :
>
> > Too bad you weren't paying attention.
>
> Oh, I was paying attention. I just can't read minds, and I refuse to try.
>
> > I _know_ where the files go from
> > the Finder. I delete everything in the "gcc" directory, thereby moving
> > all the files in the gcc directory, everything in it (including
> > subdirectories) into the trash.
>
> Yup.
>
> Everything. Including your point-of-perception.
>
> What might really bake your noodle is the idea that I can delete a file,
> and a program can continue reading from the file after the file has been
> deleted.
Nope. Had that happen to me when I first started working on the Vax as
a tech support person. I remember trying to backup/nointerlock a file,
on the fly, when it was in use. It errored out, ran out of disk space.
Being in panic mode, and thinking it had left the copy out there
consuming all of the space, I deleted it. The original file - the
"copy" was not kept by VMS.
So, here I was with a "pending" delete against a file that was in use
by others - and trying to find if there was a way to stop the pending
delete.
Not sure if there was, but our admins told me "no", so I had to go
ahead and get the operators to call for the restore tapes.
That was a low point...
(Hey, look, I made this post on-topic!)
>
> > But the terminal prompt still sees the files there, until you "cd .."
> > and "cd gcc" again. That is the part that is confusing.
>
> Ah.... What shell are you using?
>
> If "cd .." doesn't bring you into ~/.Trash, I'd consider your shell to
> be broken.
bash
>
> > If I try a similar test in Windows XP, I get what I expect - a
> > listing of no files in the directory after a delete (move to recycle
> > bin) of everything in the test directory.
>
> But... you were "in" the directory that got moved. Why didn't you move
> with it?
Dunno. Need to try replicating it if I ever get any spare time this
week!
jmfbahciv
w> First, there is nothing off topic in alt.folklore.computers.
You've been watching the political asshattery for too long.
afc is for discussing computers that are more than 20 years old.
No, it's not. It is for passing on our knowledge to current and future
generations.
No wonder we don't communicate.
/BAH
jmfbahciv
> begin quoting winston...@yahoo.com <winston...@yahoo.com> :
> [snip]
>> Oh, please, Charlton...
>>
>> What is on-topic about Barb's issues with her Mac? Or are you not a
>> part of the "Definition of file spec in commands" thread?
>
> The computer we're programming there lies between her ears.
>
It's dropped a lot of core.
/BAH
jmfbahciv
> In article <UEL3k.496$n9.122@trndny01>,
> Roland Hutchinson <my.sp...@verizon.net> wrote:
>
>> stre...@rohan.sdsu.edu wrote:
>>
>>> begin quoting winston...@yahoo.com <winston...@yahoo.com> :
>>> [snip]
>>>> Oh, please, Charlton...
>>>>
>>>> What is on-topic about Barb's issues with her Mac? Or are you not a
>>>> part of the "Definition of file spec in commands" thread?
>>> The computer we're programming there lies between her ears.
>> ...and is more than 20 years old.
>
> More to the point the OS hasn't been upgraded in the past 20.
>
/BAH
jmfbahciv
> Walter Bushell wrote:
>
>> In article <UEL3k.496$n9.122@trndny01>,
>> Roland Hutchinson <my.sp...@verizon.net> wrote:
>>
>>> stre...@rohan.sdsu.edu wrote:
>>>
>>>> begin quoting winston...@yahoo.com <winston...@yahoo.com> :
>>>> [snip]
>>>>> Oh, please, Charlton...
>>>>>
>>>>> What is on-topic about Barb's issues with her Mac? Or are you not a
>>>>> part of the "Definition of file spec in commands" thread?
>>>> The computer we're programming there lies between her ears.
>>> ...and is more than 20 years old.
>> More to the point the OS hasn't been upgraded in the past 20.
>
> Exactly. We're trying to interface new peripherals to an old OS, by
> tweaking the code of a running monitor on the fly.
It doesn't help that it keeps shutting down becauase of tired bits.
>
> We may yet have to rip everything out down to the microcode, but it hasn't
> come to that yet!
I got microcode? Is that the RNA or DNA store?
>
> (Say, where is Barb today, anyway? We had a nasty storm front roll through
> the northeastern US last night; maybe she's off the grid today.)
>
Yep. I didn't wake up when the storm went through; I woke up when the
power went off. I still don't think we had a storm.
I think a power pole down the street broke in half based on the fact of
1. no power for 9-10 hours; and 2. I saw a semi haul a pole down the
street at 02:00.
Rt. 9 East became a parking lot because my road handles a lot of ex-Rt.
9 traffic.
At 09:30, I drove down to the corner store, bought two packages of
cookies and gave them to the cop who was trying to indirect traffic.
told him to tell the crews thanks.
You would not believe how many drivers never saw, or didn't
believe, the "Road Closed except for local traffic" sign.
/BAH
jmfbahciv
"winston...@yahoo.com" <winston...@yahoo.com> writes:
> Thanks - that makes _some_ sense. I'm pretty sure I did a pwd but
> didn't see "Trash" in the result...
> I also thought I'd deleted the stuff in gcc and below, but it sounds
> like I deleted "gcc" (a viable alternative) and took a ride with it
> into the Trashcan.
You could well have been the deleted directory- your shell's working
directory being the last "link" to the deleted tree. Probaby you will
not see any files in there if you ls them and would get errors trying to
create things in it. This is a nuance of filesystem different from
Windows (which brings in its own share of different issues). This
apparently weird behavior is a manifestation of how *nix handles removal
of files, which has its uses in other circumstances.
Generally its better to avoid doing anything in Finder that relates to
something you're doing in a terminal window. Windows & OSX share the
fiction of a "trashcan"- its all make-believe since whats happening is
really a move instead of a delete, but rm in a terminal is really
delete.
I'd suggest that if you're doing something in a terminal, then do your
file management there (or at least use a file management app run from
the terminal- midnight commander or equiv). If you're doing click and
drool in the gui, then messing around with Finder is more appropriate.
> This is something Windows will not allow you to do... tried that
> earlier and you get a dialog box stating it is in use...
Shrug... different strokes for different operating sytems.
I consider this a security feature. It's another thing about Unix
internals that I didn't approve of. If you try to delete a file
which is open, you should get an error message...period.
It tells you, the user, that somebody or something else needs that
file; one would assume that deleting the file is not a Good Idea (TM).
/BAH
Gregm
jmfbahciv
> stre...@rohan.sdsu.edu wrote:
>
>> begin quoting winston...@yahoo.com <winston...@yahoo.com> :
>> [snip]
>>> Oh, please, Charlton...
>>>
>>> What is on-topic about Barb's issues with her Mac? Or are you not a
>>> part of the "Definition of file spec in commands" thread?
>> The computer we're programming there lies between her ears.
>
> ...and is more than 20 years old.
>
You guys are funny.
This computer has acquired a very, very short uptime count before
fading out and then sleeping. It is also beginning to smell.
Sigh! If it ain't one damned thing--it's another damned thing.
/BAH
jmfbahciv
Aha! I figured it out. I plugged in the power surge protector
but forgot to turn it on. I was running on battery power. So
why did the place, which Morten told me was the CPU, stink so
bad?
/BAH
Roland Hutchinson
> jmfbahciv wrote:
>> This computer has acquired a very, very short uptime count before
>> fading out and then sleeping. It is also beginning to smell.
>>
>> Sigh! If it ain't one damned thing--it's another damned thing.
>
> Aha! I figured it out. I plugged in the power surge protector
> but forgot to turn it on.
I hate when that happens. I did exactly the same thing after the storm
passed through here.
> I was running on battery power.
Isn't there a little picture of the battery in the menu bar (toward the
right side) that tells you when you are on battery power?
> So why did the place, which Morten told me was the CPU, stink so
> bad?
Good question. Did the smell go away when you turned on the surge
protector? I hope the magic smoke isn't starting to leak out.
Morten Reistad
Battery getting hot (lukewarm is OK) is seriously bad news.
Smelling is even worse.
CPU getting hot is normal, but smelling like it is going
to let the magic smoke out is bad.
-- mrr
greymaus
Agreed. Plug it out when not present.
--
Greymaus
Don't like the Lisbon brownnoses?.
Vote `No'
jmfbahciv
> jmfbahciv wrote:
>
>> jmfbahciv wrote:
>
>>> This computer has acquired a very, very short uptime count before
>>> fading out and then sleeping. It is also beginning to smell.
>>>
>>> Sigh! If it ain't one damned thing--it's another damned thing.
>> Aha! I figured it out. I plugged in the power surge protector
>> but forgot to turn it on.
>
> I hate when that happens. I did exactly the same thing after the storm
> passed through here.
I did it again today. I'm taking the window in the terminal room apart
and painting all the dark walnut paneling white. Only this time when
the TTY screen faded prematurely, I knew what was wrong and fixed it.
>
>> I was running on battery power.
>
> Isn't there a little picture of the battery in the menu bar (toward the
> right side) that tells you when you are on battery power?
Is that what that piece of mess is supposed to mean?
>
>> So why did the place, which Morten told me was the CPU, stink so
>> bad?
>
> Good question. Did the smell go away when you turned on the surge
> protector?
Yes. This worries me.
> I hope the magic smoke isn't starting to leak out.
Exactly. Is it possible that the [what did you guys call it?]
CMOS battery that wouldn't keep the date-time intact, was getting
tapped for power?
I simply don't like batteries; too much acid to spill out when
broken.
/BAH
greymaus
> Roland Hutchinson wrote:
>> Good question. Did the smell go away when you turned on the surge
>> protector?
>
> Yes. This worries me.
>
>> I hope the magic smoke isn't starting to leak out.
>
> Exactly. Is it possible that the [what did you guys call it?]
> CMOS battery that wouldn't keep the date-time intact, was getting
> tapped for power?
I would think that only supplies a trickle of power.
>
> I simply don't like batteries; too much acid to spill out when
> broken.
Friends son had a slight alcohol problem problem, so if he came home
late, he had a room with an outside entrance to sleep in, came home,
plugged in his mobile phone, fell asleep, pluggedinthingie went on fire,
smoke killed him. He had been a member of a motorcycle gang (not a bad
thing here), and they gave him a good funeral.
Charlie Gibbs
(jmfbahciv) writes:
[insert amusing image of little ferrite donuts trickling out her ear]
--
/~\ 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
(jmfbahciv) writes:
> "winston...@yahoo.com" <winston...@yahoo.com> writes:
>
>> This is something Windows will not allow you to do... tried that
>> earlier and you get a dialog box stating it is in use...
>
> Shrug... different strokes for different operating sytems.
>
> I consider this a security feature. It's another thing about Unix
> internals that I didn't approve of. If you try to delete a file
> which is open, you should get an error message...period.
>
> It tells you, the user, that somebody or something else needs that
> file; one would assume that deleting the file is not a Good Idea (TM).
Often it's not. But in other cases it is. The most FA'd Q in Windows
groups is how you update a currently-running program. The answers run
from "you can't" through some truly horrible kludges. Unix provides a
much cleaner solution.
Scott Lurndal
>and painting all the dark walnut paneling white.
A crime of the first order, almost as bad as painting cherry!
scott
Roland Hutchinson
> Roland Hutchinson wrote:
>> jmfbahciv wrote:
>> Isn't there a little picture of the battery in the menu bar (toward the
>> right side) that tells you when you are on battery power?
>
> Is that what that piece of mess is supposed to mean?
Yup. You can click on it and set some preferences: it can display time
remaining (until fully charged or discharged) in genuine digits or
percentage of charge as well as the little picture of a battery with a
charge "thermometer" down the middle.
Peter Flass
It's interesting that part of the argument is about the relative power
of big countries vs. small countries in EU 2.0. The US solved this
problem some time ago with a bicameral legislature and other fiddles
recently discussed here. We may make pointed remarks about Rhode
Island, but basically the system works as intended.
Steve O'Hara-Smith
jmfbahciv <jmfbahciv@aol> wrote:
> I consider this a security feature. It's another thing about Unix
> internals that I didn't approve of. If you try to delete a file
> which is open, you should get an error message...period.
But Unix does not provide any method for deleting a file, the
mechanism provided is to remove a link to a file. If it happens to be the
last link then the space will be recovered, a process having the file open
has a link to the file (albeit one that is only visible to that process) so
the space will not be recovered until that process closes the file. Why
should there be an error message for removing a link to a file that happens
to be open ?
> It tells you, the user, that somebody or something else needs that
> file; one would assume that deleting the file is not a Good Idea (TM).
But the something that needs that file still has it after you've
removed the link in the filesystem to it. Removing the link may prevent you
from doing whatever the process that had it open was doing again, but this
is no different from removing the file after the process has finished.
--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/
Peter Flass
OOps .. sorry ... I must have replied to the wrong message, or snipped
wrong, or something. Brain not working too well today. Y'all know what
I was replying to, don'tcha?
krw
sc...@slp53.sl.home says...
> jmfbahciv <jmfbahciv@aol> writes:
>
> >and painting all the dark walnut paneling white.
>
> A crime of the first order, almost as bad as painting cherry!
I doubt it's actually walnut. It's likely walnut stained cardboard,
or cardboard with a picture of walnut on it. If it's walnut, as in
T&G, I'll hang her myself. ...and walnut is a lot more rare than
cherry (just bought two rooms full of cherry furniture - forget
walnut).
--
Keith
kkt
More or less, though the interests of small states are not
systematically different than those of large states. There are large
left-leaning states and large right-leaning states, and small
left-leaning states and small right-leaning states. But here we have
Wyoming with fewer people than live in my neighborhood enjoying two
senators and three electors.
-- Patrick
Morten Reistad
jmfbahciv <jmfbahciv@aol> wrote:
>Roland Hutchinson wrote:
>> jmfbahciv wrote:
>>
>>> jmfbahciv wrote:
>>
>>>> This computer has acquired a very, very short uptime count before
>>>> fading out and then sleeping. It is also beginning to smell.
>>>>
>>>> Sigh! If it ain't one damned thing--it's another damned thing.
>>> Aha! I figured it out. I plugged in the power surge protector
>>> but forgot to turn it on.
>>
>> I hate when that happens. I did exactly the same thing after the storm
>> passed through here.
>
>I did it again today. I'm taking the window in the terminal room apart
>and painting all the dark walnut paneling white. Only this time when
>the TTY screen faded prematurely, I knew what was wrong and fixed it.
White paint on black will fade fast. You need many layers.
>>> I was running on battery power.
>>
>> Isn't there a little picture of the battery in the menu bar (toward the
>> right side) that tells you when you are on battery power?
>
>Is that what that piece of mess is supposed to mean?
>
>>
>>> So why did the place, which Morten told me was the CPU, stink so
>>> bad?
>>
>> Good question. Did the smell go away when you turned on the surge
>> protector?
>
>Yes. This worries me.
Have you tried to be track dog and find the source of the smell?
>> I hope the magic smoke isn't starting to leak out.
>
>Exactly. Is it possible that the [what did you guys call it?]
>CMOS battery that wouldn't keep the date-time intact, was getting
>tapped for power?
The CMOS battery should be good for about two years, and the very
least. It only powers a tiny chip.
>I simply don't like batteries; too much acid to spill out when
>broken.
NiMh and LiIon does not have so bad acids, they are reasonably
safe when deenergised. However, the deenergising process can be
pretty violent. If that happens, stand back and find a firehose.
-- mrr
Morten Reistad
Peter Flass <Peter...@Yahoo.com> wrote:
>Peter Flass wrote:
>> greymaus wrote:
>>
>> It's interesting that part of the argument is about the relative power
>> of big countries vs. small countries in EU 2.0. The US solved this
>> problem some time ago with a bicameral legislature and other fiddles
>> recently discussed here. We may make pointed remarks about Rhode
>> Island, but basically the system works as intended.
The EU lacks that wide constituency of patriotic, medium sized
states like Ohio, Maine, Georgia, Idaho, Oregon, Arizona, Virgnia
and Kentucky, These put a lot of dampening on the stress on the US
constitution.
Also, the spread between member states are greater. The US has
only one state that put hard upward stress on the system, (California),
and it seems they would all like to split it if this stress gets out
of hand. Also, a handful states put downward pressure, Like Rhode Island,
Montana, North Dakota and New Hampshire.
In the EU you have a league of very large (Germany, France, the UK) followed
by some large (Italy, Spain, Poland) that stress the system in one direction,
and lots of small ones (Cyprus, Malta, Slovenia, Estonia, Latvia, Luxembourg)
that put hard downward stress on the union.
A constitution for the EU must take account of this.
Perhaps a congressman for every million inhabitants, with all states
of < 1m forming a separate constituency, and one senator for logx(n)
population, with 1m as a base.
-- mrr
Morten Reistad
And, to all of you; if you ever get a battery fire, stand well back and
fetch some firehose or fire blanket. Battery fires usually starts pretty
benignly, and you don't detect them before it is too late to put them out.
When you see flames and smoke from a LiIon or NiMh battery it is Too Late (tm).
Either use a firehose to make a protective mist, or hold a fire blanket
in front of you if you want to approach the battery.
Burning LiIon has a nasty tendency to send small, thin plumes of red hot tar-ish
substance; and this has the same effect on humans as napalm. If you carry it
in a bag, use leather; that is pretty resistant to small fires and sparks over
short periods of time.
The energy density in the battery is like petrol.
>--
>Greymaus
>
>Don't like the Lisbon brownnoses?.
>Vote `No'
Indeed, the Irish did. Now the EU brass don't like you. You are always welcome in EFTA, though.
We (well You, really) need an EU constition. A simple one, with state's rights, and no
"mission drag" as the last two attempts have had. It should fit in 3 A4 pages. Perhaps
we should make one ?
-- mrr
jmfbahciv
> In article <8b2dnY0A99vatMzV...@rcn.net>, jmfbahciv@aol
> (jmfbahciv) writes:
>
>> "winston...@yahoo.com" <winston...@yahoo.com> writes:
>>
>>> This is something Windows will not allow you to do... tried that
>>> earlier and you get a dialog box stating it is in use...
>> Shrug... different strokes for different operating sytems.
>>
>> I consider this a security feature. It's another thing about Unix
>> internals that I didn't approve of. If you try to delete a file
>> which is open, you should get an error message...period.
>>
>> It tells you, the user, that somebody or something else needs that
>> file; one would assume that deleting the file is not a Good Idea (TM).
>
> Often it's not. But in other cases it is. The most FA'd Q in Windows
> groups is how you update a currently-running program. The answers run
> from "you can't" through some truly horrible kludges. Unix provides a
> much cleaner solution.
>
That is overwriting, not deleting. Overwriting, or replacing, is
different from eliminating the file completely.
TOPS-10 keeps the in-use copy of the code in core. The next time
anybody says RUN (which was a "begin executing the code in the
file"), the new copy would be looked up on the disk.
/BAH
jmfbahciv
> In article <XYKdnUYO7dM-u8zV...@rcn.net>, jmfbahciv@aol
> (jmfbahciv) writes:
>
>> stre...@rohan.sdsu.edu wrote:
>>
>>> begin quoting winston...@yahoo.com <winston...@yahoo.com> :
>>> [snip]
>>>> Oh, please, Charlton...
>>>>
>>>> What is on-topic about Barb's issues with her Mac? Or are you not a
>>>> part of the "Definition of file spec in commands" thread?
>>> The computer we're programming there lies between her ears.
>> It's dropped a lot of core.
>
> [insert amusing image of little ferrite donuts trickling out her ear]
>
<grin> Or boogers.
/BAH
jmfbahciv
This is not real walnut but that cheap crap made to look like
walnut. I don't paint my book shelves which are now cypress,
oak, and pine. I was looking at a poplar board yesterday
that had darkened but I didn't buy it.
/BAH
jmfbahciv
> jmfbahciv wrote:
>
>> Roland Hutchinson wrote:
>>> jmfbahciv wrote:
>
>>> Isn't there a little picture of the battery in the menu bar (toward the
>>> right side) that tells you when you are on battery power?
>> Is that what that piece of mess is supposed to mean?
>
> Yup. You can click on it and set some preferences: it can display time
> remaining (until fully charged or discharged) in genuine digits or
> percentage of charge as well as the little picture of a battery with a
> charge "thermometer" down the middle.
>
I haven't dared to click on anything up there except that blue thingie
in the left corner.
/BAH
jmfbahciv
> On Thu, 12 Jun 2008 09:50:35 -0400
> jmfbahciv <jmfbahciv@aol> wrote:
>
>> I consider this a security feature. It's another thing about Unix
>> internals that I didn't approve of. If you try to delete a file
>> which is open, you should get an error message...period.
>
> But Unix does not provide any method for deleting a file, the
> mechanism provided is to remove a link to a file. If it happens to be the
> last link then the space will be recovered, a process having the file open
> has a link to the file (albeit one that is only visible to that process) so
> the space will not be recovered until that process closes the file. Why
> should there be an error message for removing a link to a file that happens
> to be open ?
Think about editing. One user is editing the file; another user comes
along and deletes it. The deletion should always have a fatal error.
>
>> It tells you, the user, that somebody or something else needs that
>> file; one would assume that deleting the file is not a Good Idea (TM).
>
> But the something that needs that file still has it after you've
> removed the link in the filesystem to it. Removing the link may prevent you
> from doing whatever the process that had it open was doing again, but this
> is no different from removing the file after the process has finished.
This may work on a system that has been based on single-user usages.
This is not nice on a system that is timesharing. The computing biz
has to relearn everything we've known for decades. Single-user
stand alone systems have been around too long so a lot of the little
quirks that took years to figure out a long time ago will have to
go through the same kinds of process eliminations.
/BAH
jmfbahciv
> In article <3kA4k.5034$N87....@nlpi068.nbdc.sbc.com>,
> sc...@slp53.sl.home says...
>> jmfbahciv <jmfbahciv@aol> writes:
>>
>>> and painting all the dark walnut paneling white.
>> A crime of the first order, almost as bad as painting cherry!
>
> I doubt it's actually walnut. It's likely walnut stained cardboard,
It's not cardboard; it's that cheap crappy kind of wood that gives
splinters.
> or cardboard with a picture of walnut on it. If it's walnut, as in
> T&G, I'll hang her myself. ...and walnut is a lot more rare than
> cherry (just bought two rooms full of cherry furniture - forget
> walnut).
If it were walnut wood, I'd have hung white bedsheets across it
to lighten up the room.
/BAH
jmfbahciv
> In article <gKadnZjPKr1B1s_V...@rcn.net>,
> jmfbahciv <jmfbahciv@aol> wrote:
>> Roland Hutchinson wrote:
>>> jmfbahciv wrote:
>>>
>>>> jmfbahciv wrote:
>>>
>>>>> This computer has acquired a very, very short uptime count before
>>>>> fading out and then sleeping. It is also beginning to smell.
>>>>>
>>>>> Sigh! If it ain't one damned thing--it's another damned thing.
>>>> Aha! I figured it out. I plugged in the power surge protector
>>>> but forgot to turn it on.
>>> I hate when that happens. I did exactly the same thing after the storm
>>> passed through here.
>> I did it again today. I'm taking the window in the terminal room apart
>> and painting all the dark walnut paneling white. Only this time when
>> the TTY screen faded prematurely, I knew what was wrong and fixed it.
>
> White paint on black will fade fast. You need many layers.
It takes about four. More if I'm painting the real wood. these people
did not take care of their wood. I painted the window wood white
yesterday so I could find all the holes that need to be filled. There
must be 200.
>
>>>> I was running on battery power.
>>> Isn't there a little picture of the battery in the menu bar (toward the
>>> right side) that tells you when you are on battery power?
>> Is that what that piece of mess is supposed to mean?
>>
>>>> So why did the place, which Morten told me was the CPU, stink so
>>>> bad?
>>> Good question. Did the smell go away when you turned on the surge
>>> protector?
>> Yes. This worries me.
>
> Have you tried to be track dog and find the source of the smell?
The smell came from underneath my left palm. You told me that's
where the CPU is.
>
>>> I hope the magic smoke isn't starting to leak out.
>> Exactly. Is it possible that the [what did you guys call it?]
>> CMOS battery that wouldn't keep the date-time intact, was getting
>> tapped for power?
>
> The CMOS battery should be good for about two years, and the very
> least. It only powers a tiny chip.
It didn't get replaced when I had to keep entering the date/time
at boot.
>
>> I simply don't like batteries; too much acid to spill out when
>> broken.
>
> NiMh and LiIon does not have so bad acids, they are reasonably
> safe when deenergised. However, the deenergising process can be
> pretty violent. If that happens, stand back and find a firehose.
There used to be one across the street. The town shut down that
fire station after we passed three overrides specifically for
the fire department. Fuck'em. I'm not voting in favor
of another override for them again.
/BAH
jmfbahciv
Why population for both sets? You need a geographic representation
too or you're going to have resource problems.
/BAH
greymaus
Something like that. There is a problem in the EU, politicians that are a
problem in their own countries (UK: Mendelson (sp?), Ireland:Charlie
McCreevy, that Cypriot woman), are promoted to some post in the EU, with
the result that there are a lot of people up there that are not
representative of the views of their home countries.
The US example is a help, with so many years experience, but far from
perfect, the way the present duo is able to just walk through the setup is
a warning to the rest of the world. The ability and expectation that real
people can object is the only real defence against tyranny.
--
Greymaus
Time for thought.
Roland Hutchinson
Um, you _are_ clear on the concept that the main way you get the Mac to do
things is by clicking on the menus in the menu bar?
Courage!
Christian Brunschen
jmfbahciv <jmfbahciv@aol> wrote:
>That is overwriting, not deleting. Overwriting, or replacing, is
>different from eliminating the file completely.
That depends on how things are modelled. The Unix model is different from
what you may be expecting from other systems.
Specifically, in Unix, a file (a collection of bytes on a filesystem) is
reference-counted. When, and only when, the number of hard references to a
file decreases to zero, that file is destroyed and its space freed.
Those references that are 'hard', i.e., which make a file remain on disk,
are things like 'hard links' in the filesystem (such a 'hard link' is
essentially a name for the file in question in some directory), or if a
running process has the file open, either as data or executable code.
>TOPS-10 keeps the in-use copy of the code in core. The next time
>anybody says RUN (which was a "begin executing the code in the
>file"), the new copy would be looked up on the disk.
This breaks down on systems where executables are demand-paged from their
original binary file (and library file(s) etc). In the model you seem to
be describing, each running program woul require a complete copy of its code
to be made into some other, non-filesystem-related storage, in order to
ensure that it can be swapped or paged out, since there is no guarantee
that the file it was started from remains in place.
The Unix model, howeer, solves this effortlessly, because 'replacing a
file' is actually a slightly inaccurate description of what happens.
'Replacing a file' in Unix is fundamentally composed of these steps:
1) removing the original file
2) creating a new file with the same name as the original file
... where, again, 'removing the original file' is actually:
1) removing the 'hard link' from a particular name in a particular
directory, to the file in question. If this is the only reference, then
the file will actually be removed form the disk; if other references
exist, the file will remain in existance.
Again, in a Unix system, you never actually destroy a file explicitly;
you simply decrement a reference count, and when the reference count goes
to zero, the file is destroyed. This also has the advantage that if the
same file is linked from several places in the filesystem, where each
reference might be owned by a different user, you can still remove your
references with impunity, since the file will remain in place as long as
someone else has a reference to it.
Of course, this does also mean that issuing an 'rm' command on the name of
a big file does not free up the amount of disk space one might expect -
since you might not be deleting the last reference. You would then have to
find all the references in the file sstem to that file (which can be done
using the 'find' command), as well as any programs holding the file open
(using the 'lsof' command, short for 'LiSt Open Files').
>/BAH
// Christian Brunschen
Christian Brunschen
jmfbahciv <jmfbahciv@aol> wrote:
>Steve O'Hara-Smith wrote:
>> On Thu, 12 Jun 2008 09:50:35 -0400
>> jmfbahciv <jmfbahciv@aol> wrote:
>>
>>> I consider this a security feature. It's another thing about Unix
>>> internals that I didn't approve of. If you try to delete a file
>>> which is open, you should get an error message...period.
>>
>> But Unix does not provide any method for deleting a file, the
>> mechanism provided is to remove a link to a file. If it happens to be the
>> last link then the space will be recovered, a process having the file open
>> has a link to the file (albeit one that is only visible to that process) so
>> the space will not be recovered until that process closes the file. Why
>> should there be an error message for removing a link to a file that happens
>> to be open ?
>
>Think about editing. One user is editing the file; another user comes
>along and deletes it. The deletion should always have a fatal error.
That depends on what 'editing a file' means in this context. Usually,
programs that are used to edit files will load the contents of the file
into memory, when saving, write the contents to a new file, delete the
original one (or rename it to a 'backup' name), and then rename the new
version to the same name as the original one. In this scenario, if someone
else deletes the file from underneath the editing user, the editing user
won't really even notice - except the program is likely to say 'hey, your
original file wet away. Do you still want to save?'
Of course, Unix uses a slightly different model: 'removing a file' is
never done as an explicit action, but only when all the references to a
file go away. The 'rm' command simply allows you to remove a reference to
the file, and if that is the last reference, the file goes away -
otherwise, the file remains, but the reference you removed is gone and
cannot be used to access the file any more.
This means that, as long as the editing program actually keeps the file
open, the actual contents of the file won't go away; so the editing
program can write that contents to a _new_ file under the same, or a
different, name, if the original reference to the file should be deleted.
>>> It tells you, the user, that somebody or something else needs that
>>> file; one would assume that deleting the file is not a Good Idea (TM).
>>
>> But the something that needs that file still has it after you've
>> removed the link in the filesystem to it. Removing the link may prevent you
>> from doing whatever the process that had it open was doing again, but this
>> is no different from removing the file after the process has finished.
>
>
>This may work on a system that has been based on single-user usages.
>This is not nice on a system that is timesharing. The computing biz
>has to relearn everything we've known for decades. Single-user
>stand alone systems have been around too long so a lot of the little
>quirks that took years to figure out a long time ago will have to
>go through the same kinds of process eliminations.
The Unix behaviour was developed specifically for multi-user systems, and
has turned out to be very useful specifically in a multi-user system,
because the system, through its reference-counting semantics, frees the
user from having to worry about whether a file should be remoced or not,
since they only interact with te files through the _references_ they
manage (on the filesystem or from running processes). Many users may, in
fact very likely will, be using the same file.
For instance, consider a shared library that is loaded into many different
programs. In the Unix model, each running program has a reference to the
library file, allowing that to be paged in on demand as necessary directly
from its on-disk representation. Whilst these programs are running, the
filesystem reference to the library may be deleted and a new file be
placed at the same name, but that does not change anything for te running
processes. Any *new* processes wll, of course, open the library of that
name through the reference on the filesystem, and will thus get the new,
upgraded behaviour. This allows doing a 'rolling restart' of a service,
for instance, if your programs are relatively well-written:
1) keep the program running on the old version of a library.
2) Replace the old library with the new one (which actually means both
ones are around - but the new one is the only one reachable through the
filesystem, the old one is only around as long as any process still
uses it).
3) Start the programs again, so you have to sets running concurrently -
one set using the old library, one set using the new library - and
ensure that any clients connect to the new rather than old processes.
4) Eventually, all clients that were using the old processes will have
disconnected, and you can shut those processes down, at which point the
last references to the old library will go away and the file will
actually be deleted.
This type of functionality is quite useful, *especially* in a multi-user
setting.
You commented in a different thread about having strong presumptions (when
it was suggested you could take your laptop with you, and you hadn't
considered that possibility because it was not possible with a PDP-10).
Please keep that in mind in other contexts as well: You have very strong
presumptions based on your experience and the particular environment(s)
you are acustomed to. Many times what you see as 'wrong' is simple
_different_, but works quite well.
>/BAH
// Christian Brunschen
Peter Flass
> In article <r72dnZ3abqf0Nc7V...@rcn.net>,
> jmfbahciv <jmfbahciv@aol> wrote:
>
>
>>TOPS-10 keeps the in-use copy of the code in core. The next time
>>anybody says RUN (which was a "begin executing the code in the
>>file"), the new copy would be looked up on the disk.
>
>
> This breaks down on systems where executables are demand-paged from their
> original binary file (and library file(s) etc). In the model you seem to
> be describing, each running program woul require a complete copy of its code
> to be made into some other, non-filesystem-related storage,
Are there any "older" systems that didn't work this way? Every system
I'm familiar with from before around 1989 read in the program and paged
it out before it started to run. OS/2 is the first system I know of
that paged in the executable from file storage.
Peter Flass
> jmfbahciv <jmfbahciv@aol> wrote:
>>>to be open ?
>>
>>Think about editing. One user is editing the file; another user comes
>>along and deletes it. The deletion should always have a fatal error.
>
>
> That depends on what 'editing a file' means in this context. Usually,
> programs that are used to edit files will load the contents of the file
> into memory, when saving, write the contents to a new file, delete the
> original one (or rename it to a 'backup' name), and then rename the new
> version to the same name as the original one.
Again this is "new" behavior. At least one PDP-8 editor, and probably
CP/M, worked on one sector of a file at a time.
Anne & Lynn Wheeler
> Are there any "older" systems that didn't work this way? Every system
> I'm familiar with from before around 1989 read in the program and
> paged it out before it started to run. OS/2 is the first system I
> know of that paged in the executable from file storage.
when i did page mapped support for cms filesystem in the early 70s ...
potentially allowing it to be demand paged from its home position in the
filesystem.
http://www.garlic.com/~lynn/subtopic.html#mmap
there were a number of issues here ... the base cms filesystem (when
possible) would do 64k-byte reads from filesystem (records of executable
had to be allocated sequentlial & contiguously). i did some tricks in
the underlying paged mapped support to dynamically adapt how the
operation was performed ... if it was a really large executable, large
amount of contention for real storage, and very little real storage
... then it would allow things to progress in demand page mode.
If the resources were available, "asyncronous reads" would be queued for
the whole executable ... and underlying paging mechanism would
reorganize for optimal physical transfer ... and execution could start
as soon as the page for execution start was available (even if the rest
weren't all in memory). There are some processor cache operations that
can work like this (as soon as the requested word is available even if
the full cache line isn't). Issue is for large executables ...
reverting to 4k demand page operations has huge number of latencies.
however, a lot of cms compilers and applications were borrowed from
os360 ... which had behavior that lots of program image locations
had to be fetched and "swizzled" before execution could begin. lots
of past posts discussing difficulty of patching os360 implementation
paradigm for operation for high performance page-mapped environment.
http://www.garlic.com/~lynn/subtopic.html#adcon
for other topic drift ... old post about being contacted by people in
the os2 group about adapting stuff that i had done in the 60s and early
70s for os2 implementation:
http://www.garlic.com/~lynn/2007i.html#60 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#61 John W. Backus, 82, Fortran developer, dies
Greg Menke
jmfbahciv <jmfbahciv@aol> writes:
> Steve O'Hara-Smith wrote:
>> On Thu, 12 Jun 2008 09:50:35 -0400
>> jmfbahciv <jmfbahciv@aol> wrote:
>>
>>> I consider this a security feature. It's another thing about Unix
>>> internals that I didn't approve of. If you try to delete a file
>>> which is open, you should get an error message...period.
>>
>> But Unix does not provide any method for deleting a file, the
>> mechanism provided is to remove a link to a file. If it happens to be the
>> last link then the space will be recovered, a process having the file open
>> has a link to the file (albeit one that is only visible to that process) so
>> the space will not be recovered until that process closes the file. Why
>> should there be an error message for removing a link to a file that happens
>> to be open ?
>
> Think about editing. One user is editing the file; another user comes
> along and deletes it. The deletion should always have a fatal error.
Sure- nothing in *nix prevents the use of such a locking protocol to
provide this functionality- lots of ways to handle it. The fact that it
is not extensively implemented shows its not needed as often as you
think it needs to be.
>
>>
>>> It tells you, the user, that somebody or something else needs that
>>> file; one would assume that deleting the file is not a Good Idea (TM).
>>
>> But the something that needs that file still has it after you've
>> removed the link in the filesystem to it. Removing the link may prevent you
>> from doing whatever the process that had it open was doing again, but this
>> is no different from removing the file after the process has finished.
>
>
> This may work on a system that has been based on single-user usages.
> This is not nice on a system that is timesharing. The computing biz
> has to relearn everything we've known for decades. Single-user
> stand alone systems have been around too long so a lot of the little
> quirks that took years to figure out a long time ago will have to
> go through the same kinds of process eliminations.
It works just fine. I run a server with 20+ people hopping on and off
it to edit files, version control work, etc. The problem hasn't occured
once.
Gregm
jmfbahciv
> jmfbahciv wrote:
>
>> Roland Hutchinson wrote:
>>> jmfbahciv wrote:
>>>
>>>> Roland Hutchinson wrote:
>>>>> jmfbahciv wrote:
>>>>> Isn't there a little picture of the battery in the menu bar (toward the
>>>>> right side) that tells you when you are on battery power?
>>>> Is that what that piece of mess is supposed to mean?
>>> Yup. You can click on it and set some preferences: it can display time
>>> remaining (until fully charged or discharged) in genuine digits or
>>> percentage of charge as well as the little picture of a battery with a
>>> charge "thermometer" down the middle.
>>>
>> I haven't dared to click on anything up there except that blue thingie
>> in the left corner.
>
> Um, you _are_ clear on the concept that the main way you get the Mac to do
> things is by clicking on the menus in the menu bar?
>
> Courage!
>
mistake and clicked before hunted and all kinds of weird things
happened. I restarted the system because I had no idea how to
get back to "normal". The one saving grace of this gooey mess is
that most menus aren't invoked if you just point at it. However,
now that the clicker is underneath my palms, (not to mention
the fucking moush director, resting my hands produces <ahem>
interesting beahaviours.
/BAH
jmfbahciv
> In article <r72dnZ3abqf0Nc7V...@rcn.net>,
> jmfbahciv <jmfbahciv@aol> wrote:
>> That is overwriting, not deleting. Overwriting, or replacing, is
>> different from eliminating the file completely.
>
> That depends on how things are modelled. The Unix model is different from
> what you may be expecting from other systems.
I understand that is the Unix OS philosophy. I don't approve.
<snip>
/BAH
Roland Hutchinson
Well, at least the menu bar is in the right place, at the top of the screen.
Just slam the pointer upwards and you can't miss it.
jmfbahciv
multi-user and timesharing. When an OS' philosophy is based on
tasking, it isn't really timesharing.
/BAH
Christian Brunschen
That is not, however, the same thing as it being a bad thing, or not
working in a multi-user setting. Especially since the Unix model has
proven over several decades to be working quite well, in particular in
multi-user settings.
><snip>
>
>/BAH
// Christian Brunschen
jmfbahciv
Oh, I see it. I just don't want to increase the probability of fucking
yet another thing up. Two things already went wrong this morning. I
can wait to see the third one.
Question: What does the extension .dmg mean? My cybercrud guesser
is out of whack because the only words that enter my mind is
demigod.
I have two square glyphs that appear to be a piece of paper with
a corner turned down (that's suppoed to mean document or something?).
Each one represents the two software packages I downloaded over the
net.
I know they are not DEC-flavored docs because that's the glphy
I click on to install and/or start the things up each morning.
/BAH
jmfbahciv
> In article <Ksudna7COvhAbMnV...@rcn.net>,
> jmfbahciv <jmfbahciv@aol> wrote:
>> Christian Brunschen wrote:
>>> In article <r72dnZ3abqf0Nc7V...@rcn.net>,
>>> jmfbahciv <jmfbahciv@aol> wrote:
>>>> That is overwriting, not deleting. Overwriting, or replacing, is
>>>> different from eliminating the file completely.
>>> That depends on how things are modelled. The Unix model is different from
>>> what you may be expecting from other systems.
>> I understand that is the Unix OS philosophy. I don't approve.
>
> That is not, however, the same thing as it being a bad thing, or not
> working in a multi-user setting. Especially since the Unix model has
> proven over several decades to be working quite well, in particular in
> multi-user settings.
Sigh! The Unix philosophy evolved to address the needs of a certain
class of computing services that were needed. Now the description
of the needs for today's system owners, who are also users, have
changed. Unix' philosophy is going to evolve to match these
requirements.
How files are handled is going to undergo a change.
/BAH
Roland Hutchinson
> Question: What does the extension .dmg mean? My cybercrud guesser
> is out of whack because the only words that enter my mind is
> demigod.
It's a disk image. Open it [1] and the Mac will do an integrity check on
the file and then mount it. An icon for the mounted volume will appear on
your desktop. Open that, and do what you want to with the files (e.g.,
copy them somewhere). If the image is of a read-only volume, you can't do
anything to the files on the mounted volume, of course.
When you are done with the volume, unmount it. (Either select it and hunt
around for an "Eject volume" command in the menus, or control-click on it
and choose from the contextual menu, select it and push the F12 key, or
just drag it towards the trash basket, which will turn into an Eject icon
as you start to drag, and drop it thereupon.)
> I have two square glyphs
Icons. Fonts have glyphs (by the hundreds and thousands nowadays).
> that appear to be a piece of paper with
> a corner turned down (that's suppoed to mean document or something?).
Yes, variations on the piece-of-paper idea are used to indicate many kinds
of documents. Do they have a tiny little picture of a disk on them if you
look real close?
> Each one represents the two software packages I downloaded over the
> net.
What are the packages? I hope they came from someplace respectable (like
apple.com).
One common way of distributing Mac software is to put a package (i.e., a
file that opens with the Apple installer when you double click on it) on a
read-only disk image and ship the image.
[1] Ways to open a document or application:
EITHER: Select with mouse (click once), then choose "Open" from the File
menu (or use the command-O shortcut for open).
OR: Double click on it with the mouse in a finder window or on the desktop.
(Single-click if it's in the Dock.)
Christian Brunschen
It would appear that you are pretty much approaching the system from the
diametrically opposite direction that most users would: A common way to
explore a Mac and its software is to look at the menus, learning about the
concepts and the general way to interact with the system in the process,
and only venture to the command line once one is familar with the GUI.
This may have something to do with your difficulties getting accustomed:
you're working against, rather han with, the system.
>Question: What does the extension .dmg mean? My cybercrud guesser
>is out of whack because the only words that enter my mind is
>demigod.
'Disk iMaGe'. It's an entire filesystem contained in a file;
double-clicking it will 'mount' it, making its contents available, as if
it were a removable disk. Disk images are frequently used instead of other
types of archives these days, because they can be accessed in a
random-access fashion.
>I have two square glyphs that appear to be a piece of paper with
>a corner turned down (that's suppoed to mean document or something?).
The general shape of a sheet of paper with the top-right corner turned is
used to indicate a document; the specifics of the contents of the sheet
usually indicate the type, or even a partial preview of, the document.
>Each one represents the two software packages I downloaded over the
>net.
>
>I know they are not DEC-flavored docs because that's the glphy
>I click on to install and/or start the things up each morning.
You can always control-click on any given icon and select 'Get Info' to
see a comprehensive description, including showing the file access
permissions, he default application that will be used to open the document
when you double-click it, etc. In fact, please try it on a few files.
>/BAH
// Christian Brunschen
Christian Brunschen
You might have a point. if it were the case that the current philosophy
were not able to handle the way that users mange files. But it turns out
that the current Unix approach works very well across the entire range
that Unix systems are depoyed - from mobile phones to high-performance
clusters, form single-user to multi-user timesharing. So there's no need
for any such change.
>/BAH
// Christian Brunschen
Roland Hutchinson
How files are handled -- meaning in this case linking and unlinking and
locking files -- is not broken. Nobody is going to fix it unless they are
convinced that it is broken, and you are not going to convince anyone.
If you want it "fixed", I suggest you start coding. At the very least, this
will make you understand the architectural issues involved. When you have
working code, perhaps someone can be persuaded to adopt it -- or at least
to explain to you in specific terms why you are misguided.
You need to re-read this:
http://www.lisp.org/humor/ai-koans.html
and then calmly, humbly, and joyfully embrace your condition as a Unix
novice.
I particularly encourage meditation on the following excerpt:
One day a student came to Moon and said, "I understand how to make a better
garbage collector. We must keep a reference count of the pointers to each
cons." Moon patiently told the student the following story-
"One day a student came to Moon and said, "I understand how to make
a better garbage collector...
Mike Spencer
I haven't been following this thread closely but...
jmfbahciv <jmfbahciv@aol> wrote:
> Sigh! The Unix philosophy evolved to address the needs of a certain
> class of computing services that were needed. Now the description
> of the needs for today's system owners, who are also users, have
> changed. Unix' philosophy is going to evolve to match these
> requirements.
Today's system owner-users require one virtual button on the screen.
Training consists of learning to use the mouse to click on that
button. A popup window then informs you, "I took care of it" and does
whatever you were thinking you'd like to do just then. The net is now
top-heavy to people for whom the net is a variant of TV and they are
happy to the extent that it comes to resemble TV. But you're smarter
than that, eh?
If I get this thread correctly, a bunch of mostly aging computer
demi-gods, wizards and gurus are trying to walk another (aging? :-)
computer wizard through the use of the most uncompromisingly
obnoxious and supercilious GUI in existence. Say what? Can you say
"vexed"?
Um, why don't you:
+ buy a used Intel machine, anything PII or later
+ stick a newish 20-gig or larger HD into it.
+ install Linux and X
+ buy Anderson & Anderson's Unix C Shell Field Guide and read it all.
+ run Linux, X, window manager but no GUI.
Then you can use your presumably superior language skills and
experience to do what you want via the C shell[1] in an xterm. X will be
available to run intrinsically GUI-based apps such as a GUI browser,
media player or image editor. But all the basic stuff can happen in
shell-based apps. By the time you need to know stuff beyond the
abovementioned Field Guide, you'll be comfy with *ix-style stuff and
have no problem finding and understanding answers.
(Advising GNU Emacs for mail, news, file manager etc. etc. will be
left for another flamebait^H^H^H^H^H^H^H^H^H post.)
[1] No flames, plz, about csh vs. sh/bash. We're talking about
learning here, not an optimal scripting environment.
--
Mike Spencer Nova Scotia, Canada
Steve O'Hara-Smith
jmfbahciv <jmfbahciv@aol> wrote:
> Think about editing. One user is editing the file; another user comes
> along and deletes it. The deletion should always have a fatal error.
No need - simple example here - where x is a text file
user 1 user 2
vi x
edits away
rm x
edits
finishes editing and saves
x reappears
The thing is the person who "deleted" it didn't delete it all they
did was remove the link to it in the filesystem. The person editing (well
the editor process) had the file open so there was still a reference so the
file was not removed and all is well.
> > But the something that needs that file still has it after you've
> > removed the link in the filesystem to it. Removing the link may prevent
> > you from doing whatever the process that had it open was doing again,
> > but this is no different from removing the file after the process has
> > finished.
>
>
> This may work on a system that has been based on single-user usages.
Erm Unix was designed for multi-user usage and this is the way Unix
filesystems have always worked.
> This is not nice on a system that is timesharing. The computing biz
> has to relearn everything we've known for decades. Single-user
> stand alone systems have been around too long so a lot of the little
> quirks that took years to figure out a long time ago will have to
> go through the same kinds of process eliminations.
Unix has decades of use in multiuser environments - this "quirk"
has proved to be a very useful feature in those environments.
--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/
jmfbahciv
> jmfbahciv wrote:
>
>> Question: What does the extension .dmg mean? My cybercrud guesser
>> is out of whack because the only words that enter my mind is
>> demigod.
>
> It's a disk image. Open it [1] and the Mac will do an integrity check on
> the file and then mount it. An icon for the mounted volume will appear on
> your desktop. Open that, and do what you want to with the files (e.g.,
> copy them somewhere). If the image is of a read-only volume, you can't do
> anything to the files on the mounted volume, of course.
Right. I have to do that to start SeaMonkey.
Oh, I see...d[isk i]mg[age]
>
> When you are done with the volume, unmount it. (Either select it and hunt
> around for an "Eject volume" command in the menus, or control-click on it
> and choose from the contextual menu, select it and push the F12 key, or
> just drag it towards the trash basket, which will turn into an Eject icon
> as you start to drag, and drop it thereupon.)
>
>> I have two square glyphs
>
> Icons. Fonts have glyphs (by the hundreds and thousands nowadays).
Oh, hell. I wonder what else my brain dropped yesterday.
>
>> that appear to be a piece of paper with
>> a corner turned down (that's suppoed to mean document or something?).
>
> Yes, variations on the piece-of-paper idea are used to indicate many kinds
> of documents. Do they have a tiny little picture of a disk on them if you
> look real close?
those are disks?
>
>> Each one represents the two software packages I downloaded over the
>> net.
>
> What are the packages? I hope they came from someplace respectable (like
> apple.com).
AOL and SeaMonkey have the paper underneath the disk. The one at the
top is labelled Mac HD.
>
> One common way of distributing Mac software is to put a package (i.e., a
> file that opens with the Apple installer when you double click on it) on a
> read-only disk image and ship the image.
>
>
> [1] Ways to open a document or application:
>
> EITHER: Select with mouse (click once), then choose "Open" from the File
> menu (or use the command-O shortcut for open).
>
> OR: Double click on it with the mouse in a finder window or on the desktop.
> (Single-click if it's in the Dock.)
I'm assuming the Dock is the stripe of junk at the bottom of the TTY
screen?
The way I found to start SeaMonkey is single click on the square, and
something flashes. Then double click on the square and the square
enlarges and resumes normal size. I never click on the AOL .dmg;
that created headaches in the arse when I did that...but I don't
remember what they were now.
I think I have established the "habits" that avoid messes w.r.t.
comm on this system now. Knock on wood--declare an anti-Murphy
incantation.
/BAH
Greg Menke
jmfbahciv <jmfbahciv@aol> writes:
>>
>> It works just fine. I run a server with 20+ people hopping on and off
>> it to edit files, version control work, etc. The problem hasn't occured
>> once.
>>
>> Gregm
> Wait until real timesharing is done. There can be difference between
> multi-user and timesharing. When an OS' philosophy is based on
> tasking, it isn't really timesharing.
>
C'mon BAH, *nix does everything you think a "real OS" has to do and has
been doing it for years- decades in fact. Just because it doesn't
exactly match up with your own ideas doesn't make it wrong. We've been
through all this before.
Gregm
jmfbahciv
> jmfbahciv <jmfbahciv@aol> writes:
>>> It works just fine. I run a server with 20+ people hopping on and off
>>> it to edit files, version control work, etc. The problem hasn't occured
>>> once.
>>>
>>> Gregm
>> Wait until real timesharing is done. There can be difference between
>> multi-user and timesharing. When an OS' philosophy is based on
>> tasking, it isn't really timesharing.
>>
>
>
> C'mon BAH, *nix does everything you think a "real OS" has to do and has
> been doing it for years- decades in fact.
So has NT, nee VMS.
Have you noticed how this particular revision of that OS philosophy has
evolved (or, IMO, devolved)?
< Just because it doesn't
> exactly match up with your own ideas doesn't make it wrong. We've been
> through all this before.
There are common ways to do certain things, depending on the philosophy
of the OS. This doesn't make one "wrong" and the other "right". It
depends on the tenets of what the OS was supposed to use as a
tradeoff razor.
I don't know how to explain this in English ASCII. When you work
on any code, the first thing you do is figure out its philosophy and
then write your code using that philosophy. Don't any of you do this?
/BAH
Roland Hutchinson
> AOL and SeaMonkey have the paper underneath the disk. The one at the
> top is labelled Mac HD.
That's not a disk image. That's the icon of a mounted disk: namely your
hard drive inside your computer. You can rename it if you like.
Roland Hutchinson
> I'm assuming the Dock is the stripe of junk at the bottom of the TTY
> screen?
Yup.
> The way I found to start SeaMonkey is single click on the square, and
> something flashes. Then double click on the square and the square
> enlarges and resumes normal size. I never click on the AOL .dmg;
> that created headaches in the arse when I did that...but I don't
> remember what they were now.
That sounds like you are running SeaMonkey off of the disk image. This will
work, but it is not optimal, and not how it's designed to work.
Instead, open the disk image to mount it, then -- one time only -- drag the
SeaMonkey application to your applications folder[1] (which will copy it
there -- dragging from one disk to another copies rather than moves, by
default). Unmount the disk image. Double click on the SeaMonkey in your
applications folder to launch it. There will be a SeaMonkey icon in the
Dock while it is running. Click and hold on it (or control-click) and
choose "keep in dock". Then you can start it up from the dock in future.
Keep reading that Missing Manual in your copious free time!
[1] Can you find that? Open a browser window -- open its sidebar if need
be -- click on Applications in the sidebar. Alternatively, open up that
MacHD and have a look for it.
Roland Hutchinson
Absolutely!
The thing is, it's considered good form to do it without proclaiming in a
public forum that the philosophy is all wrong and can't possibly work.
_Confessing_ in a public forum that the philosophy _seems_ all wrong to you
and that you don't see how it can possibly work is okay -- note the subtle
difference.
Note also that your postings seem to all of us quite clearly to be doing the
former rather than the latter.
jmfbahciv
a disclaimer that states I am not talking about the Universe :-).
And some of Unix philosophy isn't a matter of what "seems" to be wrong,
it is a matter of trying to fit a square peg in a round hole. this is
not a new evaluation of mine. Some of it was formed when I studied the
internals back in the mid-80s.
/BAH
jmfbahciv
> jmfbahciv wrote:
>
>> AOL and SeaMonkey have the paper underneath the disk. The one at the
>> top is labelled Mac HD.
>
> That's not a disk image. That's the icon of a mounted disk: namely your
> hard drive inside your computer. You can rename it if you like.
>
{{{{{{{{{{{{shudder}}}}}}}}}}}}}}} And tempt an invocation of Murphy's
Law? I'm may be old and bit worn and decrepit. I haven't become
stupid ...yet.
/BAH
jmfbahciv
> jmfbahciv wrote:
>
>> I'm assuming the Dock is the stripe of junk at the bottom of the TTY
>> screen?
>
> Yup.
>
>> The way I found to start SeaMonkey is single click on the square, and
>> something flashes. Then double click on the square and the square
>> enlarges and resumes normal size. I never click on the AOL .dmg;
>> that created headaches in the arse when I did that...but I don't
>> remember what they were now.
>
> That sounds like you are running SeaMonkey off of the disk image. This will
> work, but it is not optimal, and not how it's designed to work.
I figured that installation of SEaMonkey required starting from .dmg
every time. The AOL install doesn't have to start with the .dmg.
I can hit the blue apple, finger the "recent items", cross over
to get the list and click on AOL COnnect. I can't do this with
the SeaMonkey entry in that list.
There are lots of things wrong with SeaMonkey, mostly at the
PITA annoying level. I still have a goal of using trn in the
TTY window to post here.
>
> Instead, open the disk image to mount it, then -- one time only -- drag the
> SeaMonkey application to your applications folder[1] (which will copy it
> there -- dragging from one disk to another copies rather than moves, by
> default). Unmount the disk image. Double click on the SeaMonkey in your
> applications folder to launch it. There will be a SeaMonkey icon in the
> Dock while it is running. Click and hold on it (or control-click) and
> choose "keep in dock". Then you can start it up from the dock in future.
>
> Keep reading that Missing Manual in your copious free time!
>
> [1] Can you find that?
It doesn't seem familiar. Browser window? Sidebar?
> Open a browser window -- open its sidebar if need
> be -- click on Applications in the sidebar. Alternatively, open up that
> MacHD and have a look for it.
Gawd! I HATE GOOIES. All this shite trying to find the magic pixel
at exactly the right layer to do what used to take
a three character command with a few arguments at monitor level.
These fucking gooey pages are like the King's Quest games. You had
to find the single pixel that would display the hidden object you
needed to continue onto the next screen of the game.
Sorry. I've just been wrestling with webbiting trying to find
a piece of information.
/BAH
Roland Hutchinson
You do well to be cautions, but I assure you that it is perfectly save to
rename your hard drive on a Mac. No one has ever lost data by doing this
in over 20 years.
Roland Hutchinson
Start by clicking on the desktop (the background; the wallpaper) to make
sure you are talking to the finder. (You always can know who you are
talking to by looking at the first menu to the right of the little apple in
the corner, which will have the name of the application that's got the
focus).
Then select "New finder window" or some-such from the File menu -- or just
use the shortcut for New (applicable Mac-wide)
There will open a window showing your home folder; a sidebar panel at the
left (ifI remember how Tiger does it correctly) will be shown by default.
You also have a Go menu that will open Applications directly, if memory
serves.
You don't need me at this point -- you need the "Using the Finder" chapter
of the Missing Manual.
>> Open a browser window -- open its sidebar if need
>> be -- click on Applications in the sidebar. Alternatively, open up that
>> MacHD and have a look for it.
>
> Gawd! I HATE GOOIES. All this shite trying to find the magic pixel
> at exactly the right layer to do what used to take
> a three character command with a few arguments at monitor level.
>
>
> These fucking gooey pages are like the King's Quest games. You had
> to find the single pixel that would display the hidden object you
> needed to continue onto the next screen of the game.
>
> Sorry. I've just been wrestling with webbiting trying to find
> a piece of information.
It's really quite logical. Applications go in the Applications folder --
it's not mandatory, just a sensible idea. Becomes second nature after a
while.
Oh -- and here's a hint: inside the Appplications folder is a Utilities
folder, where all the geeky apps live.
Roland Hutchinson
Have you got a copy of The UNIX-HATERS Handbook?
http://www.simson.net/ref/ugh.pdf
You will find a version of Dick Gabriel's original "Worse is Better" essay
(which I have recommended here before) as an appendix in it, but the full
story, with sequels, is here:
http://www.dreamsongs.com/WorseIsBetter.html
All of this will bring you up to date with the 1990s. (It's a start.)
Lars Poulsen
>> Think about editing. One user is editing the file; another user comes
>> along and deletes it. The deletion should always have a fatal error.
Steve O'Hara-Smith wrote:
> No need - simple example here - where x is a text file
>
> user 1 user 2
> vi x
> edits away
> rm x
> edits
> finishes editing and saves
> x reappears
This is one of those examples, where people can honestly have
different ideas about how it should work, and where minor
variations in how a program is written "to do the obvious
and natural thing" can yield different results.
If the program used by "user1" opens the file in shared access
mode (many readers one writer), reads it in, keeps the file open;
then when it is time to write it back, it just does so and closes
the file ... the file will be gone as it is closed. If "user2"
had renamed the file instead of removing it, it would be written
back to the same file, which has now been renamed.
If the program is written to open the file and read it in,
then close the input file. And when it is time to write it back,
open it again, now for output, write and then close ... the file
will be back under the original name. (This is in fact what
vi[m] does.)
If the two users have differently named links to the same file,
even more subtly hard-to-predict-for-the-ignorant-user
variations in behaviour will pop up. The behavior is slightly
different if the links are symbolic rather than hard.
Windows "shortcuts" are a bit different again. And if the
file lives in a filesystem that was remote-mounted from a file
server, it can get downright funny. (To say nothing about the
downright craziness of "file name tunneling"!!)
The operating systems of the "golden age" when TOPS-x0 was
new and shiny may not have had these issues ... because they
did not have so much flexibility, and frankly, I would not
want to give up the flexibilty to avoid the ambiguities of
these "corner cases" ... except on the day I have to figure out
what is happening when my business partner wants to know why
this oddball program is doing something unexpected that he
can't quite explain.
A couple of weeks ago, I had such a case, where a Windows user
could not write to some files on a Linux (SaMBa) file server
that he should have had write permission to via a group access
privilege mask. Eventually it turned out that years ago he had
talked a sysadmin into creating a second userid for him on the
server, with the same numeric userid and same password, and the
same home directory. At the time, he needed to get into two
servers, and Windows95 insisted that all remote file access must
use the same username as the desktop login. The sysadmins of
the two servers had different formulas for creating userids.
Windows XP does not have this limitation. The other server is
long gone anyway. The extra userid was forgotten. But that day,
when the user logged into the file server, finger memory kicked
in and he typed the long-forgotten alternate userid. It took
a couple of hours to figure out what had happened!!
(That second userid is now gone from the Linux box.)
/ Lars Poulsen
greymaus
>
> That sounds like you are running SeaMonkey off of the disk image. This will
> work, but it is not optimal, and not how it's designed to work.
>
> Instead, open the disk image to mount it, then -- one time only -- drag the
> SeaMonkey application to your applications folder[1] (which will copy it
> there -- dragging from one disk to another copies rather than moves, by
> default). Unmount the disk image. Double click on the SeaMonkey in your
checking for free HD space..first.
> applications folder to launch it. There will be a SeaMonkey icon in the
> Dock while it is running. Click and hold on it (or control-click) and
> choose "keep in dock". Then you can start it up from the dock in future.
>
> Keep reading that Missing Manual in your copious free time!
>
> [1] Can you find that? Open a browser window -- open its sidebar if need
> be -- click on Applications in the sidebar. Alternatively, open up that
> MacHD and have a look for it.
>
--
Greymaus
.
.
...
Stan Barr
My Mac hard disks are named Homer, Bartman and Lisa, with appropriate icons,
doesn't cause me any problems! Mind you, that's *old* MacOS... :-)
--
Cheers,
Stan Barr t-bone .at. dial .dot. pipex .dot. com
The future was never like this!
Roland Hutchinson
> On Mon, 16 Jun 2008 09:10:24 -0400, jmfbahciv <jmfbahciv@aol> wrote:
>>Roland Hutchinson wrote:
>>> jmfbahciv wrote:
>>>
>>>> AOL and SeaMonkey have the paper underneath the disk. The one at the
>>>> top is labelled Mac HD.
>>>
>>> That's not a disk image. That's the icon of a mounted disk: namely your
>>> hard drive inside your computer. You can rename it if you like.
>>>
>>
>>{{{{{{{{{{{{shudder}}}}}}}}}}}}}}} And tempt an invocation of Murphy's
>>Law? I'm may be old and bit worn and decrepit. I haven't become
>>stupid ...yet.
>
> My Mac hard disks are named Homer, Bartman and Lisa, with appropriate
> icons,
> doesn't cause me any problems! Mind you, that's *old* MacOS... :-)
Quite possibly the same file system, though. Is is HFS+?
Roland Hutchinson
> On 2008-06-16, Roland Hutchinson <my.sp...@verizon.net> wrote:
>>
>> That sounds like you are running SeaMonkey off of the disk image. This
>> will work, but it is not optimal, and not how it's designed to work.
>>
>> Instead, open the disk image to mount it, then -- one time only -- drag
>> the SeaMonkey application to your applications folder[1] (which will copy
>> it there -- dragging from one disk to another copies rather than moves,
>> by default).
> checking for free HD space..first.
Not strictly necessary, as far as I can see. We have machines to do that
sort of thing for us nowadays: the copy will fail with an error dialog if
there isn't enough room.
Walter Bushell
t-b...@address.invalid (Stan Barr) wrote:
> On Mon, 16 Jun 2008 09:10:24 -0400, jmfbahciv <jmfbahciv@aol> wrote:
> >Roland Hutchinson wrote:
> >> jmfbahciv wrote:
> >>
> >>> AOL and SeaMonkey have the paper underneath the disk. The one at the
> >>> top is labelled Mac HD.
> >>
> >> That's not a disk image. That's the icon of a mounted disk: namely your
> >> hard drive inside your computer. You can rename it if you like.
> >>
> >
> >{{{{{{{{{{{{shudder}}}}}}}}}}}}}}} And tempt an invocation of Murphy's
> >Law? I'm may be old and bit worn and decrepit. I haven't become
> >stupid ...yet.
>
> My Mac hard disks are named Homer, Bartman and Lisa, with appropriate icons,
> doesn't cause me any problems! Mind you, that's *old* MacOS... :-)
I named my Hard Disk "After Ewe" in honor of a woman named Rachel, at
one point.
--
What is done in the heat of battle is (normatively) judged
by different standards than what is leisurely planned in
comfortable conference rooms.
Rich Alderson
> Christian Brunschen wrote:
>> jmfbahciv <jmfbahciv@aol> wrote:
>>> Think about editing. One user is editing the file; another user comes
>>> along and deletes it. The deletion should always have a fatal error.
>> That depends on what 'editing a file' means in this context. Usually,
>> programs that are used to edit files will load the contents of the file
>> into memory, when saving, write the contents to a new file, delete the
>> original one (or rename it to a 'backup' name), and then rename the new
>> version to the same name as the original one.
> Again this is "new" behavior. At least one PDP-8 editor, and probably
> CP/M, worked on one sector of a file at a time.
On Tops-10, TECO (the default editor) works on "pages" of text, which are
defined by a trailing formfeed (ASCII 12 decimal, ^L) or EOF. It is possible
to read multiple pages into memory, but not necessary. Other PDP-10 editors
used the same model, for example E (the default--only?--editor on WAITS, the
SAIL OS), though the page-break character differed (^V on E, IIRC).
It may be that SOS (the line editor) also works on pages, but I simply don't
remember, and I haven't use SOS for more than a few minutes at a time for
nearly 30 years, since shortly after I learned EMACS on TOPS-20.
--
Rich Alderson "You get what anybody gets. You get a lifetime."
ne...@alderson.users.panix.com --Death, of the Endless
Stan Barr
wrote:
>Stan Barr wrote:
>>
>> My Mac hard disks are named Homer, Bartman and Lisa, with appropriate
>> icons,
>> doesn't cause me any problems! Mind you, that's *old* MacOS... :-)
>
>Quite possibly the same file system, though. Is is HFS+?
Aaah...I forget :-( I set it up many years ago, originally with OS9.1
but reverted to 8.6 'cos a few of my old apps didn't like 9.1.
Probably HFS+, I think.
Roland Hutchinson
> On Mon, 16 Jun 2008 18:25:16 GMT, Roland Hutchinson
> <my.sp...@verizon.net> wrote:
>>Stan Barr wrote:
>>>
>>> My Mac hard disks are named Homer, Bartman and Lisa, with appropriate
>>> icons,
>>> doesn't cause me any problems! Mind you, that's *old* MacOS... :-)
>>
>>Quite possibly the same file system, though. Is is HFS+?
>
> Aaah...I forget :-( I set it up many years ago, originally with OS9.1
> but reverted to 8.6 'cos a few of my old apps didn't like 9.1.
> Probably HFS+, I think.
Seems likely.
jmfbahciv
> jmfbahciv wrote:
>
>> Roland Hutchinson wrote:
>>> jmfbahciv wrote:
>>>
>>>> AOL and SeaMonkey have the paper underneath the disk. The one at the
>>>> top is labelled Mac HD.
>>> That's not a disk image. That's the icon of a mounted disk: namely your
>>> hard drive inside your computer. You can rename it if you like.
>>>
>> {{{{{{{{{{{{shudder}}}}}}}}}}}}}}} And tempt an invocation of Murphy's
>> Law? I'm may be old and bit worn and decrepit. I haven't become
>> stupid ...yet.
>
> You do well to be cautions, but I assure you that it is perfectly save to
> rename your hard drive on a Mac. No one has ever lost data by doing this
> in over 20 years.
>
/BAH
jmfbahciv
If there were no form feeds in the file, SOS would read consider the
file as one page; it used buffered mode to read so the whole file
didn't have to be in core for an edit. Howeever, the line numbers
continued in ascending order until EOF. If there were form feeds,
then the numbering was restarted after each <FF>.
/BAH
Roland Hutchinson
More than you might suppose! The creative, different-thinking types who
have been the traditional core Mac constituency have a propensity for
pushing machines into scenarios unanticipated by their designers.
David Powell
Rich Alderson <ne...@alderson.users.panix.com> in
alt.folklore.computers wrote:
>Peter Flass <Peter...@Yahoo.com> writes:
>
>> Christian Brunschen wrote:
>
>>> jmfbahciv <jmfbahciv@aol> wrote:
>
>>>> Think about editing. One user is editing the file; another user comes
>>>> along and deletes it. The deletion should always have a fatal error.
>
>>> That depends on what 'editing a file' means in this context. Usually,
>>> programs that are used to edit files will load the contents of the file
>>> into memory, when saving, write the contents to a new file, delete the
>>> original one (or rename it to a 'backup' name), and then rename the new
>>> version to the same name as the original one.
>
>> Again this is "new" behavior. At least one PDP-8 editor, and probably
>> CP/M, worked on one sector of a file at a time.
>
>On Tops-10, TECO (the default editor) works on "pages" of text, which are
>defined by a trailing formfeed (ASCII 12 decimal, ^L) or EOF. It is possible
>to read multiple pages into memory, but not necessary. Other PDP-10 editors
>used the same model, for example E (the default--only?--editor on WAITS, the
>SAIL OS), though the page-break character differed (^V on E, IIRC).
>
The same for the PDP8. The only editor I can think of that works per
sector (actally per block) is EPIC, the Edit, Punch and Cmpare
Utility. Useful it you wanted to do an edit on an executable and save
a paper tape copy, not very useful as a text editor unless you can
mentally pack/unpack three ASCII chars to two twelve bit words. I
think I played with it once, life was much easier after FUTIL
Alternatively, perhaps a pre OS/8 program using the TC08 DECtape
subroutines on a memory restricted machine.
>It may be that SOS (the line editor) also works on pages, but I simply don't
>remember, and I haven't use SOS for more than a few minutes at a time for
>nearly 30 years, since shortly after I learned EMACS on TOPS-20.
Eight megabytes and continuously swapping would be fun on a PDP8.
Regards,
David P.
Stan Barr
>jmfbahciv wrote:
>
>> Roland Hutchinson wrote:
>>>
>>> You do well to be cautions, but I assure you that it is perfectly save to
>>> rename your hard drive on a Mac. No one has ever lost data by doing this
>>> in over 20 years.
>>>
>> How many had the den mother touch?
>
>More than you might suppose! The creative, different-thinking types who
>have been the traditional core Mac constituency have a propensity for
>pushing machines into scenarios unanticipated by their designers.
I recall seeing photos of one Mac enthusiast who built his own flight sim
aircraft cockpit with a Mac and three monitors, one for straight ahead,
and two for diagonal left and right views, all controlled by a real
stick and pedals!
My old Mac's screens look nothing like how Apple intended them...e.g. the
window borders are not necessarily even rectangular, depending on what
theme is currently in vogue here. Being originally an art student I
*like* my eye candy, but it must have style... :-)
Morten Reistad
jmfbahciv <jmfbahciv@aol> wrote:
>Greg Menke wrote:
>> jmfbahciv <jmfbahciv@aol> writes:
>Wait until real timesharing is done. There can be difference between
>multi-user and timesharing. When an OS' philosophy is based on
>tasking, it isn't really timesharing.
You have your eyes shut for reality. MacOS X, any windows since w2k,
any Linux or BSD are signoficantly _MORE_ capable of timesharing than
any pre 1980 OS. They are all orders of magnitudes better at timeslicing,
task switching, heavy loads, extreme I/O than anything DEC, Prime, DG,
ND ever made.
I have just been involved in a Linux stresstest where a 2 inch high
box switched more packets than the entire pre-nsf arpanet ever did at
any one time (380k pps), and ran more than 5k real logged in users
with over 12k threads. The system was still responsive, so you could
edit a file in emacs with 5k others running traffic.
Yes, it was a real server, $5k in price. But it runs the same timesharing
code as all the other linux machines. (IBM xSeries with 2x4 Xeon, hyper-
transport, 4G ram. )
Tops10, Tops20, Multics, Primos etc would all have fallen over in
microseconds.
You could probably handle a few hundred logged-in users on your mac.
-- mrr
stre...@rohan.sdsu.edu
> On Mon, 16 Jun 2008 09:10:24 -0400, jmfbahciv <jmfbahciv@aol> wrote:
> >Roland Hutchinson wrote:
> >> jmfbahciv wrote:
> >>
> >>> AOL and SeaMonkey have the paper underneath the disk. The one at the
> >>> top is labelled Mac HD.
> >>
> >> That's not a disk image. That's the icon of a mounted disk: namely your
> >> hard drive inside your computer. You can rename it if you like.
> >>
> >
> >{{{{{{{{{{{{shudder}}}}}}}}}}}}}}} And tempt an invocation of Murphy's
> >Law? I'm may be old and bit worn and decrepit. I haven't become
> >stupid ...yet.
>
> My Mac hard disks are named Homer, Bartman and Lisa, with appropriate icons,
> doesn't cause me any problems! Mind you, that's *old* MacOS... :-)
I always rename the main disk icon. Generally, I rename it to be the name
of the computer (which are always chosen to some theme, if I have any say
about it), and any additional partitions/disks are named "Data" or "Storage"
or "Archive" or somesuch.
--
--Stewart Stremler----------------...@rohan.sdsu.edu--
Our only hope is that the general literacy level falls fast enough that
the newsgroups are left to those of us who still have the ability and
desire to deal with text. -- Charlie Gibbs (1998)
stre...@rohan.sdsu.edu
[snip]
> I have just been involved in a Linux stresstest where a 2 inch high
> box switched more packets than the entire pre-nsf arpanet ever did at
> any one time (380k pps), and ran more than 5k real logged in users
> with over 12k threads. The system was still responsive, so you could
> edit a file in emacs with 5k others running traffic.
>
> Yes, it was a real server, $5k in price. But it runs the same timesharing
> code as all the other linux machines. (IBM xSeries with 2x4 Xeon, hyper-
> transport, 4G ram. )
>
> Tops10, Tops20, Multics, Primos etc would all have fallen over in
> microseconds.
>
> You could probably handle a few hundred logged-in users on your mac.
I dunno. I can make it hurt with just a few dozen Terminals.
I no longer have access to a real PRIME to compare it to.
Maybe if I niced all the logged-in users to something really bad...
--
--Stewart Stremler---------------...@rohan.sdsu.edu--
Good software doesn't make assumptions about the specific implementation
details of the VM system in order to work. --Peter Berger (May 2003)