On 03/08/2015 21:32, Tim Streater wrote:
In article . com,
dennis@home wrote:

I remember the first ethernet I ordered and installed used ISO
protocols, TCP was just a labs thing.

When was that then, and which ISO protocols?


It was an Intel NRM system, the first in Europe, you can probably google
it but I am too busy.

On 03/08/2015 21:49, Huge wrote:
On 2015-08-03, Tim Streater wrote:
In article . com,
dennis@home wrote:

I remember the first ethernet I ordered and installed used ISO
protocols, TCP was just a labs thing.

When was that then, and which ISO protocols?

I expect he means X.25, but being dennis he probably thinks it was
tiny goblins, a la Terry Pratchett.



I know what x25 is, I designed the hardware and wrote the firmware for
the x25 card used on System X before I designed the whole thing out in
favour of a Unix system and networking a few years later..

It wasn't x25 and your lack of knowledge about the early days of
networking is only matched by your current lack.

On Mon, 03 Aug 2015 21:12:39 +0100, Vir Campestris wrote:

On 31/07/2015 23:50, The Natural Philosopher wrote:

If you upgrade a DLL that is in use by a running program in windows you
need to reboot mor at leats close that program

In Linux, you don't.

End of.

In Windows if a program has a DLL loaded it has an open handle to the
file with a write lock. That stops the code getting changed on the fly.
Seems quite sensible.

AIUI (and ICBW) in Linux the file (inode) will hang around, and the name
will be associated to the new file. Which means new processes get the
new file.

But I don't understand how existing processes get the bug fix. I suspect
they don't.

Indeed, they don't.

On Mon, 03 Aug 2015 21:24:58 +0100, Tim Streater wrote:

I expect you write the new file and delete the old one, then rename (or
some sequence). The old file will not actually be deleted (as in, space
freed) until the last program using it stops doing so, so there are no
longer any open file handles on it. Not sure of the details but I think
the delete also renames it to either a null file name of some flavour of
illegal one so no new program can open the old one.

No, there just isn't a file name at that point. Directory entry points to
the inode. The inode describes the file.

When the file is replaced, the directory entry points to the new inode.
The 'use count' in the old inode drops to zero (this is 'use' in the
sense of the number of directory entries pointing to it, not now many
users of the file there are).

When the *user count* of that inode drops to zero, then the file is
deleted and the inode is freed.

On Mon, 03 Aug 2015 19:54:09 +0100, The Natural Philosopher wrote:

On 03/08/15 14:09, dennis@home wrote:
On 03/08/2015 10:10, J.B.Treadstone wrote:
On Mon, 03 Aug 2015 08:12:03 +0000, Huge wrote:

On 2015-08-02, newshound wrote:

[47 lines snipped]

Don't get me wrong, Linux is fine for a lot of people, just not
sufficient if you need to interchange files with a client using an MS
Office system.

I've been doing this for years. No-one's noticed.

I've done it quite a few times, with spreadsheets, documents etc, &
those people using MSOffice haven't complained.


Its usually the linux users that complain that they can't read the stuff
written by M$.

Ot isn't. Linux (Libre office) can in fact read MS word docs that MSword
users of the previous version cannot.

In deed, in some cases MSOffice isn't compatible with other versions of
MSOffice.

On Mon, 03 Aug 2015 12:37:12 +0100, F wrote:

On 01/08/2015 00:09, Johnny B Good wrote:

[snip]

and visit: http://www.bleepingcomputer.com/ and download
"Combofix.exe"

I thought I'd give that a try here but it refuses to run on Windows 8.1.
Is it really only for XP, Vista, 7 and 8?

Ah, sorry about that. It didn't occur to me to check but it seems win8.1
support isn't there yet.

I used it recently to good effect on a win7 laptop and I have a dim
recollection from last year of it failing to run in a win8.x system
(might even have been a win8.0 system at that time rather than win8.1).

I just had to shrug my shoulders and carry on with MBAM free and SpyBot
S&D (along with whatever other cleanup tools I felt might help clean out
the more obscure pests).

CrapCleaner is a pretty useful tool to help delouse the registry of
orphaned entries left over by various 'uninstallers' as well as the kack
left over from removed malware/adware/trojans along with various files
hiding away in temp and cache folders.

CrapCleaner is well regarded. It's free and, IME (and that of most
others), hasn't caused problems due to its registry cleanup activities.

Ignore the outrageous claims by alternative registry cleaning tools of
100 to 300 percent performance boosts. It's extremely rare that any such
registry 'spring cleans' show any hint of a performance enhancement. The
minute you see any such claims is the minute you give such products the
wide berth they so richly deserve.

--
Johnny B Good

On 03/08/15 21:31, charles wrote:
In article ,
The Natural Philosopher wrote:
On 03/08/15 21:12, Vir Campestris wrote:
On 31/07/2015 23:50, The Natural Philosopher wrote:

If you upgrade a DLL that is in use by a running program in windows you
need to reboot mor at leats close that program

In Linux, you don't.

End of.

In Windows if a program has a DLL loaded it has an open handle to the
file with a write lock. That stops the code getting changed on the fly.
Seems quite sensible.

AIUI (and ICBW) in Linux the file (inode) will hang around, and the name
will be associated to the new file. Which means new processes get the
new file.

But I don't understand how existing processes get the bug fix. I suspect
they don't.

No, they don't, obviously. But the point is you don't need to crash
running programs (or the whole machine) just to get an update in.

nor do you with Windows. You can delay the restart until you are ready.

no you cant.

You cant *install* the files while programs using them are still running.



--
New Socialism consists essentially in being seen to have your heart in
the right place whilst your head is in the clouds and your hand is in
someone else's pocket.

In article , The Natural Philosopher
wrote:
On 03/08/15 21:31, charles wrote:
In article , The Natural Philosopher
wrote:
On 03/08/15 21:12, Vir Campestris wrote:
On 31/07/2015 23:50, The Natural Philosopher wrote:

If you upgrade a DLL that is in use by a running program in windows
you need to reboot mor at leats close that program

In Linux, you don't.

End of.

In Windows if a program has a DLL loaded it has an open handle to the
file with a write lock. That stops the code getting changed on the
fly. Seems quite sensible.

AIUI (and ICBW) in Linux the file (inode) will hang around, and the
name will be associated to the new file. Which means new processes
get the new file.

But I don't understand how existing processes get the bug fix. I
suspect they don't.

No, they don't, obviously. But the point is you don't need to crash
running programs (or the whole machine) just to get an update in.

nor do you with Windows. You can delay the restart until you are ready.

no you cant.

You cant *install* the files while programs using them are still running.

as I said: wait until you've finished using them.

--
Please note new email address:

On 04/08/15 09:24, charles wrote:
In article , The Natural Philosopher
wrote:
On 03/08/15 21:31, charles wrote:
In article , The Natural Philosopher
wrote:
On 03/08/15 21:12, Vir Campestris wrote:
On 31/07/2015 23:50, The Natural Philosopher wrote:

If you upgrade a DLL that is in use by a running program in windows
you need to reboot mor at leats close that program

In Linux, you don't.

End of.

In Windows if a program has a DLL loaded it has an open handle to the
file with a write lock. That stops the code getting changed on the
fly. Seems quite sensible.

AIUI (and ICBW) in Linux the file (inode) will hang around, and the
name will be associated to the new file. Which means new processes
get the new file.

But I don't understand how existing processes get the bug fix. I
suspect they don't.

No, they don't, obviously. But the point is you don't need to crash
running programs (or the whole machine) just to get an update in.

nor do you with Windows. You can delay the restart until you are ready.

no you cant.

You cant *install* the files while programs using them are still running.

as I said: wait until you've finished using them.

so all work on your computer stops whilst you upgrade?

Meanwhile here's the latest on spyware. Windows 10

http://www.theregister.co.uk/2015/08...vacy_defaults/


I occurs to me that the fashionable myth these days is the
'precautionary principle'. Don't do anyth8ing *in case it might* lead to
something bad.

In the case of Windows, the precautionary principles says never ever
install it at all.


--
New Socialism consists essentially in being seen to have your heart in
the right place whilst your head is in the clouds and your hand is in
someone else's pocket.

In article , The Natural Philosopher
wrote:
On 04/08/15 09:24, charles wrote:
In article , The Natural Philosopher
wrote:
On 03/08/15 21:31, charles wrote:
In article , The Natural Philosopher
wrote:
On 03/08/15 21:12, Vir Campestris wrote:
On 31/07/2015 23:50, The Natural Philosopher wrote:

If you upgrade a DLL that is in use by a running program in
windows you need to reboot mor at leats close that program

In Linux, you don't.

End of.

In Windows if a program has a DLL loaded it has an open handle to
the file with a write lock. That stops the code getting changed on
the fly. Seems quite sensible.

AIUI (and ICBW) in Linux the file (inode) will hang around, and the
name will be associated to the new file. Which means new processes
get the new file.

But I don't understand how existing processes get the bug fix. I
suspect they don't.

No, they don't, obviously. But the point is you don't need to crash
running programs (or the whole machine) just to get an update in.

nor do you with Windows. You can delay the restart until you are
ready.

no you cant.

You cant *install* the files while programs using them are still
running.

as I said: wait until you've finished using them.

so all work on your computer stops whilst you upgrade?

so, you even use your computer when you're asleep in bed?

Meanwhile here's the latest on spyware. Windows 10

http://www.theregister.co.uk/2015/08...vacy_defaults/


I occurs to me that the fashionable myth these days is the
'precautionary principle'. Don't do anyth8ing *in case it might* lead to
something bad.

In the case of Windows, the precautionary principles says never ever
install it at all.

--
Please note new email address:

On 04/08/15 10:31, charles wrote:
In article , The Natural Philosopher
wrote:
On 04/08/15 09:24, charles wrote:
In article , The Natural Philosopher
wrote:
On 03/08/15 21:31, charles wrote:
In article , The Natural Philosopher
wrote:
On 03/08/15 21:12, Vir Campestris wrote:
On 31/07/2015 23:50, The Natural Philosopher wrote:

If you upgrade a DLL that is in use by a running program in
windows you need to reboot mor at leats close that program

In Linux, you don't.

End of.

In Windows if a program has a DLL loaded it has an open handle to
the file with a write lock. That stops the code getting changed on
the fly. Seems quite sensible.

AIUI (and ICBW) in Linux the file (inode) will hang around, and the
name will be associated to the new file. Which means new processes
get the new file.

But I don't understand how existing processes get the bug fix. I
suspect they don't.

No, they don't, obviously. But the point is you don't need to crash
running programs (or the whole machine) just to get an update in.

nor do you with Windows. You can delay the restart until you are
ready.

no you cant.

You cant *install* the files while programs using them are still
running.

as I said: wait until you've finished using them.

so all work on your computer stops whilst you upgrade?

so, you even use your computer when you're asleep in bed?

No, but I don't let unattended upgrades happen nor do I leave my desktop
on 24x7.

Many upgrades require user input anyway.


Meanwhile here's the latest on spyware. Windows 10

http://www.theregister.co.uk/2015/08...vacy_defaults/


I occurs to me that the fashionable myth these days is the
'precautionary principle'. Don't do anyth8ing *in case it might* lead to
something bad.

In the case of Windows, the precautionary principles says never ever
install it at all.



--
New Socialism consists essentially in being seen to have your heart in
the right place whilst your head is in the clouds and your hand is in
someone else's pocket.

On 04/08/2015 07:35, The Natural Philosopher wrote:
On 03/08/15 21:31, charles wrote:
In article ,
The Natural Philosopher wrote:
On 03/08/15 21:12, Vir Campestris wrote:
On 31/07/2015 23:50, The Natural Philosopher wrote:

If you upgrade a DLL that is in use by a running program in windows
you
need to reboot mor at leats close that program

In Linux, you don't.

End of.

In Windows if a program has a DLL loaded it has an open handle to the
file with a write lock. That stops the code getting changed on the fly.
Seems quite sensible.

AIUI (and ICBW) in Linux the file (inode) will hang around, and the
name
will be associated to the new file. Which means new processes get the
new file.

But I don't understand how existing processes get the bug fix. I
suspect
they don't.

No, they don't, obviously. But the point is you don't need to crash
running programs (or the whole machine) just to get an update in.

nor do you with Windows. You can delay the restart until you are ready.

no you cant.

You cant *install* the files while programs using them are still running.



Windows update manages to put the updates on the system which is all the
user cares about. Most never require a reboot either. Not that you would
know because all your windows "knowledge" comes from some hate pit
somewhere in lala land, probably from someone like harry.

On 04/08/2015 10:44, The Natural Philosopher wrote:

No, but I don't let unattended upgrades happen nor do I leave my desktop
on 24x7.

Many upgrades require user input anyway.

Not on windows they don't, the odd one might if its a new feature you
need to agree to. Must be a TNP linux thing.

I thought some distros did work without input but I guess yours is the
odd one out.

I suppose it has to ask so it can stop all the user processing while it
does a "seamless" kernel upgrade as it can take rather a long time and
you don't want the user thinking its died, its probably quicker to
reboot but its not so nerdy.

On 04/08/2015 10:44, The Natural Philosopher wrote:

Meanwhile here's the latest on spyware. Windows 10

http://www.theregister.co.uk/2015/08...vacy_defaults/

Oh dear that makes it the same as chrome, android, ios, OSX and ubuntu,
mint, etc., at least windows tells you and you can change the defaults
if you are paranoid. Not that that stops anyone collecting you web
habits whatever OS you are using.

In article , The Natural Philosopher
writes
Unix was designed for multi tasking and multi users in a busy
environment where one of the more important things was that you didn't
take a machine with hundreds of users on it down unless you had to.
Well just like a PABX - I did say it was produced by a telephone
company.
--
bert

In article . com,
lid writes
On 03/08/2015 21:49, Huge wrote:
On 2015-08-03, Tim Streater wrote:
In article . com,
dennis@home wrote:

I remember the first ethernet I ordered and installed used ISO
protocols, TCP was just a labs thing.

When was that then, and which ISO protocols?

I expect he means X.25, but being dennis he probably thinks it was
tiny goblins, a la Terry Pratchett.



I know what x25 is, I designed the hardware and wrote the firmware for
the x25 card used on System X before I designed the whole thing out in
favour of a Unix system and networking a few years later..

It wasn't x25 and your lack of knowledge about the early days of
networking is only matched by your current lack.
Xerox and DEC were early players in the ethernet scene. XNS (Xerox
Network System) formed the basis of the early ethernet implementations.
I was implementing such systems commercially in about 1983. ICL had
company wide network at the time. IBM of course refused to accept anyone
else's standards and came up with their utterly hopeless token ring
system. - "some of our tokens are missing" was often the despairing cry
in network Support.
The mainframe suppliers including ICL were determined that the mainframe
would remain king and control the network and of course they were
ultimately proved totally wrong.

I first came across TCP in about 1983/4 with a bespoke office system
when Mini's first appeared. Can't remember what it was called but dumb
terminals hung of the central system which provided e-mail, word
processing and a few applications. Spreadsheet database and the like.
This is what I was told at the time. TCP or Transaction Control Program,
was produce by General Motors as part of a batch system to control
demand and supply of parts around their production lines. You know the
sort of thing - punched cards input and pages and pages of printout of
which only about two were relevant. Then they went to interactive input
and TCP/IP was born - the IP bit stranding for interactive protocol. I
can't vouch for this other than it's what I was told in marketing
briefings.

ICL took the system and transferred it to UNIX and sold it as
Officepower. No idea how many they sold. I put one into Sandwell
Hospital in Birmingham.


--
bert

On 03/08/2015 21:21, The Natural Philosopher wrote:
On 03/08/15 21:12, Vir Campestris wrote:
On 31/07/2015 23:50, The Natural Philosopher wrote:

If you upgrade a DLL that is in use by a running program in windows you
need to reboot mor at leats close that program

In Linux, you don't.

End of.

In Windows if a program has a DLL loaded it has an open handle to the
file with a write lock. That stops the code getting changed on the fly.
Seems quite sensible.

AIUI (and ICBW) in Linux the file (inode) will hang around, and the name
will be associated to the new file. Which means new processes get the
new file.

But I don't understand how existing processes get the bug fix. I suspect
they don't.

No, they don't, obviously. But the point is you don't need to crash
running programs (or the whole machine) just to get an update in.

Oh. So the running programs haven't had the update applied?

Isn't that a bit of a problem if they are services that never restart
and are available from the network?

Andy

"bert" wrote in message ...
In article , The Natural Philosopher
writes
Unix was designed for multi tasking and multi users in a busy environment where one of
the more important things was that you didn't take a machine with hundreds of users on
it down unless you had to.
Well just like a PABX - I did say it was produced by a telephone company.
--
bert

Researchers working at Bell Labs are credited with the development
of radio astronomy, the transistor, the laser, the charge-coupled
device (CCD), information theory (Claude Shannon), the UNIX operating
system, the C programming language, S programming language and the
C++ programming language. Eight Nobel Prizes have been awarded for
work completed at Bell Laboratories.
https://en.wikipedia.org/wiki/Bell_Labs

And not mentioned on there is John.L.Kelly maybe most famous for his
staking system - the Kelly System first published in the form of
an incomprehensible formal proof in the Bell Labs Technical Journal.
He also devised roulette systems with Claude Shannon a colleague
at Bell Labs.
https://en.wikipedia.org/wiki/Gambli...rmation_theory

michael adams

....

On 04/08/15 21:20, Vir Campestris wrote:
On 03/08/2015 21:21, The Natural Philosopher wrote:
On 03/08/15 21:12, Vir Campestris wrote:
On 31/07/2015 23:50, The Natural Philosopher wrote:

If you upgrade a DLL that is in use by a running program in windows you
need to reboot mor at leats close that program

In Linux, you don't.

End of.

In Windows if a program has a DLL loaded it has an open handle to the
file with a write lock. That stops the code getting changed on the fly.
Seems quite sensible.

AIUI (and ICBW) in Linux the file (inode) will hang around, and the name
will be associated to the new file. Which means new processes get the
new file.

But I don't understand how existing processes get the bug fix. I suspect
they don't.

No, they don't, obviously. But the point is you don't need to crash
running programs (or the whole machine) just to get an update in.

Oh. So the running programs haven't had the update applied?

Isn't that a bit of a problem if they are services that never restart
and are available from the network?


Normally the update will restart them if they are daemons.

Andy



--
New Socialism consists essentially in being seen to have your heart in
the right place whilst your head is in the clouds and your hand is in
someone else's pocket.

On 04/08/15 21:19, bert wrote:
Then they went to interactive input and TCP/IP was born - the IP bit
stranding for interactive protocol. I can't vouch for this other than
it's what I was told in marketing briefings.

No. IP stands for
https://en.wikipedia.org/wiki/Internet_Protocol


I am not sure what your are on, but your memory seems to be scrambled.

--
New Socialism consists essentially in being seen to have your heart in
the right place whilst your head is in the clouds and your hand is in
someone else's pocket.

On 03/08/2015 21:33, dennis@home wrote:
On 03/08/2015 21:12, Vir Campestris wrote:
On 31/07/2015 23:50, The Natural Philosopher wrote:

If you upgrade a DLL that is in use by a running program in windows you
need to reboot mor at leats close that program

In Linux, you don't.

End of.

In Windows if a program has a DLL loaded it has an open handle to the
file with a write lock. That stops the code getting changed on the fly.
Seems quite sensible.

AIUI (and ICBW) in Linux the file (inode) will hang around, and the name
will be associated to the new file. Which means new processes get the
new file.

But I don't understand how existing processes get the bug fix. I suspect
they don't.



Neither does TNP or he would say how.

One way would be to send a kill to restart the process but that doesn't
fit with never doing restarts.

Of course you could use the kernel thread locking to lock the kernel so
no user programs are actually using it and then update the bits in the
kernel which will work as long as no functional changes are made, just
bug fixes. It won't work if the code is part of the lock handling
though, so if you find a bug there you are stuffed.

You can also do stuff with the shadow copy locking facility... that's
how backup programs are able to get access to files that applications
have an exclusive lock on.

--
Cheers,

John.

/================================================== ===============\
| Internode Ltd - http://www.internode.co.uk |
|-----------------------------------------------------------------|
| John Rumm - john(at)internode(dot)co(dot)uk |
\================================================= ================/