One significant (and annoying) difference I have noticed between Windows
and Linux is that Windows seems to grow over time. It's not *completely*
Windows' own fault, but for the most part it is.

  Something like a half year ago I had 10 GB of free space in my C: drive.
Today I had less than 4 GB, and I had to do some serious cleanup to regain
that space again. (I always install all games and most programs to my D:
drive. I only install the most critical system tools and such in the C:
drive. The ones I have installed in the past 6 months certainly don't take
6 GB of space.)

  It wasn't any one single file or program. It was the sum of a ton of
little things.

  Every time Windows installs an update or service pack, it writes the
necessary info inside the \WINDOWS directory to uninstall it. Since there
are hundreds of such updates, these directories end up taking a rather
significant amount of space, even though individually they are relatively
small. I think they took over half a GB in total. They can be safely
removed if you are OK with not being able to uninstall the updates and
service packs (I have never heard of anybody doing that; certainly I have
never encountered the need).

  Every time Windows installs a new version of .NET, it writes a huge amount
of files to the C: drive. These are important files and cannot be removed
(unless you really want to uninstall .NET, making many programs not work).
There's little that can be done to remedy this problem, other than making
NTFS compress those directories (which saves about 20-30% of the disk space
they take).

  There are tons of temporary files which are *not* removed by Windows' disk
cleaning utility. You have to manually search for them and remove them.
Those alone accounted for several tens of megabytes.

  Every time you install a program, even if you don't install it in C:,
Windows will write uninstallation info for that program in the C: drive.
AFAIK there's no way around it. The only way to remove them safely is
to remove the program itself.

  Also, many programs (especially games) want to write tons of data
under the "Documents and Settings" directory in the C: drive. AFAIK there's
no way to change this. Most programs write just a few megabytes, but some
of them write really huge amounts of (mostly useless) data in there. What's
worse, many of the programs don't remove the data when they are uninstalled.
This alone easily accounts for a gigabyte of useless data, or even more.

  Every time any part of Java updates itself, it feels the need to leave
its old files in their place, and install the new files in new directories
(under C:, naturally). This easily accounts for hundreds of megabytes.

  And so on. There are tons of things which make the C: partition grow,
even if you try to avoid it. If the C: partition is relatively small, you
are going to run out of space sooner or later.

  I have never noticed this phenomenon in Linux. It doesn't grow over time,
even if you regularly install and uninstall programs.

  The somewhat equivalent of "Documents and Settings" in Linux (and in Unix
in general) is your home directory, but programs don't tend to write tons
of data there (except Firefox and Thunderbird, but cleaning their caches
is easy enough). Even if some programs do write tons of data there, it's
somehow easier to find that data and remove it if you don't need it anymore.
It's more hidden and somehow more "silent" in Windows.

  But the point is that program data tends to keep confined inside your
home directory (inside subdirectories starting with a dot), rather than
being scattered all over the system. I have so far not found the need to
clean up my Linux system, while I have found the need to do so with my
Windows system several times because of space running alarmingly low.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   Every time Windows installs a new version of .NET, it writes a huge amount
> of files to the C: drive. These are important files and cannot be removed
> (unless you really want to uninstall .NET, making many programs not work).

AFAIK, my Windows system didn't have *any* version of .NET installed 
until that time I installed VisualStudio. (But then, I guess it depends 
which software you're trying to run...)

>   Every time you install a program, even if you don't install it in C:,
> Windows will write uninstallation info for that program in the C: drive.
> AFAIK there's no way around it. The only way to remove them safely is
> to remove the program itself.

It's usually fairly small though. So unless you install *a lot* of stuff...

>   Also, many programs (especially games) want to write tons of data
> under the "Documents and Settings" directory in the C: drive. AFAIK there's
> no way to change this.

Ah yes, this is loads of fun.

I'm told you can change some registry key (manually of course) to make 
this folder live somewhere else. But I'm not sure how many programs 
would actually take notice; ever tried installing Windows in, say, 
D:\WINDOWS, and seeing programs stuff files into C:\WINDOWS anyway?

>   Every time any part of Java updates itself, it feels the need to leave
> its old files in their place, and install the new files in new directories
> (under C:, naturally). This easily accounts for hundreds of megabytes.

Yeah. The updater for Adobe Acrobat Reader likes to stuff the installer 
files in a temp folder inside Documents and Settings. For no defined reason.

>   The somewhat equivalent of "Documents and Settings" in Linux (and in Unix
> in general) is your home directory, but programs don't tend to write tons
> of data there.

I'm still wondering why no OS has yet come up with the idea of 
seperating "documents" from "settings", but hey...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp schrieb:
>   One significant (and annoying) difference I have noticed between Windows
> and Linux is that Windows seems to grow over time. It's not *completely*
> Windows' own fault, but for the most part it is.

It's not like Linux wouldn't been growing over time, too, if you install 
new software occasionally. For instance, when installing an image 
processing software package, it may pull in some image library packages 
in addition. I don't think Linux package managers will automatically 
un-install those if you uninstall that image processing package (it 
would be ill-advised, as I might have installed other, 
non-package-managed software that also relies on that library).

The only difference is that in Linux this is less opaque, and having 
additional libraries installed may therefore not be regarded as "growing 
of the system".

The reason is that by convention, Unix software doesn't automatically 
install (or even ship with) libraries it needs, while Windows software 
comes full with all components required, automatically installing them 
if not already present. I guess this is one of the core benefits and 
banes of Windows.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> It's not like Linux wouldn't been growing over time, too, if you install 
> new software occasionally. For instance, when installing an image 
> processing software package, it may pull in some image library packages 
> in addition. I don't think Linux package managers will automatically 
> un-install those if you uninstall that image processing package (it 
> would be ill-advised, as I might have installed other, 
> non-package-managed software that also relies on that library).

  Note that I didn't even mention DLLs in my original post. Everything
that makes the Windows partition grow over time is stuff which is *not*
related to system libraries. (Of course the DLLs also make the system
larger, but that's another story in itself.)

  There's little of that in Linux.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
> 
>   Note that I didn't even mention DLLs in my original post. Everything
> that makes the Windows partition grow over time is stuff which is *not*
> related to system libraries. (Of course the DLLs also make the system
> larger, but that's another story in itself.)

You didn mention .NET, which I'd definitely file in this category.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> > 
> >   Note that I didn't even mention DLLs in my original post. Everything
> > that makes the Windows partition grow over time is stuff which is *not*
> > related to system libraries. (Of course the DLLs also make the system
> > larger, but that's another story in itself.)

> You didn mention .NET, which I'd definitely file in this category.

  Except that .NET installs a whole lot of things which are not simply
some DLLs in the \WINDOWS\system32 directory. And with "a whole lot",
I mean exactly that. All the .NET versions combined take like a gigabyte
or more.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>> You didn mention .NET, which I'd definitely file in this category.
> 
>   Except that .NET installs a whole lot of things which are not simply
> some DLLs in the \WINDOWS\system32 directory. And with "a whole lot",
> I mean exactly that. All the .NET versions combined take like a gigabyte
> or more.

That doesn't change the fact that those files are part of the .NET 
"package".

Post a reply to this message

On 09/19/09 07:51, clipka wrote:
> It's not like Linux wouldn't been growing over time, too, if you install
> new software occasionally. For instance, when installing an image

	Barely. Probably depends on your distribution, but on mine (Gentoo) it 
is easy to control.

> processing software package, it may pull in some image library packages
> in addition. I don't think Linux package managers will automatically
> un-install those if you uninstall that image processing package (it
> would be ill-advised, as I might have installed other,
> non-package-managed software that also relies on that library).

	Gentoo usually does, unless it is well known that a package will 
definitely _need_ the old library. Usually, you have to run an 
additional command where it will find all packages that depended on the 
old library, and recompile them against the new library (Gentoo is 
source based).

	The only real part where Gentoo can "grow" if you're careless is when 
you install a package that requires a lot of dependencies. It will 
install the dependencies and that package. When you remove that package, 
the dependencies are still there. So once or twice a year, I have to 
give a special command to figure out all those dependency packages that 
are no longer needed, and uninstall them.

	Don't know how other distros handle that.

-- 
No, Taco Bell is NOT the Mexican Phone Company!

Post a reply to this message

Warp wrote:
> (I have never heard of anybody doing that; certainly I have
> never encountered the need).

I've done it ever so occasionally, but usually by the time I figured out it 
broke something, it has been too late to fix it that way. I think the 
corporate world likely uses it more often.

>   Every time Windows installs a new version of .NET, it writes a huge amount
> of files to the C: drive. These are important files and cannot be removed
> (unless you really want to uninstall .NET, making many programs not work).

Yep. Every new version has basically a complete copy of the whole thing, and 
.NET is really pretty big.  .NET 2.0 programs break if you install only .NET 
3.5 runtime, because they're trying to avoid DLL hell. You *could* uninstall 
the 2.0 runtime tho, if you weren't still using it.

>   There are tons of temporary files which are *not* removed by Windows' disk
> cleaning utility. You have to manually search for them and remove them.
> Those alone accounted for several tens of megabytes.

It always ticks me off that things like Java and Adobe and QuickTime and all 
those people are too lazy to write the plug-in that'll let "disk cleanup" 
delete the stuff. Having to track down where Java is caching every applet I 
ever looked at and Adobe is storing every font it uses like I can't download 
it faster than Adobe can read it from the disk is rather a PITA.

Indeed, I'm a bit annoyed that firefox doesn't plug into that system as 
well. :-)  I really don't want to go to every program that might be holding 
a bunch of stuff cached and find the appropriate menu entry to clean it off.

>   Every time you install a program, even if you don't install it in C:,
> Windows will write uninstallation info for that program in the C: drive.
> AFAIK there's no way around it. The only way to remove them safely is
> to remove the program itself.

Unfortunately, the number of uninstallers is similar to the number of 
installers, so unless you get everyone using the standard systems (which, of 
course, become legacy with new standards showing up every year or so) you 
can't necessarily interpret the data to remove it.

> many of the programs don't remove the data when they are uninstalled.

Yeah. The old uninstallers would just delete that which they installed, 
without actually cleaning out the data left behind. Usually leaving 
directories sitting around where the game had saved state into the program 
files subdirectories. Kind of a safety thing - don't uninstall the data just 
because you uninstalled the program. Reasonable, but annoying sometimes.

>   I have never noticed this phenomenon in Linux. It doesn't grow over time,
> even if you regularly install and uninstall programs.

It cleans up after itself better, perhaps. New functionality makes it grow, 
of course. I'm sure if you install OpenOffice, build a bunch of 
spreadsheets, then uninstall OpenOffice, you don't wind up deleting those 
spreadsheets. If you uninstall Beagle, it leaves all its thumbnails and crap 
around, too. The dot files don't go away when you delete a program.

The problem with Windows is every program somehow feels the need to cache a 
bunch of crap and not hook into the standard ways for cleaning that up.

> is easy enough). Even if some programs do write tons of data there, it's
> somehow easier to find that data and remove it if you don't need it anymore.

Yeah, it's all dot files in the home directory, for the most part. On the 
other hand, Linux I think has far fewer background type services. Stuff to 
watch for updates will, for example, grow with the size of the repository.

> It's more hidden and somehow more "silent" in Windows.

I wonder if it's because it's more heirarchical and library-driven in 
Windows than in Linux. I.e., there's not just "a dot file in your home dir", 
but "a dot file inside a product directory inside a vendor directory inside 
one of three different hidden directories depending on how you're logged in" 
sort of thing.

But nowadays, most of the stuff that's per-user cruft winds up in 
/users/warp and usually /users/warp/appdata, organized pretty logically if 
you actually go exploring.

>   But the point is that program data tends to keep confined inside your
> home directory (inside subdirectories starting with a dot), rather than
> being scattered all over the system.

That's not really true. The global stuff in Linux is in global places in the 
system, like /var and such. I was frequently running out of room in /var and 
had to go in and clean things up, altho I don't remember now what it was 
that was sticking things in there.

You have to clean up web server logs, audit logs, wtmp, all that sort of thing.

Granted, everyone and their uncle writes crap into your home directory in 
Windows, and then leaves it there indefinitely. I don't think you can 
reasonably complain tho that installing programs leaves data installed in 
your system directories. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Orchid XP v8 wrote:
> I'm told you can change some registry key (manually of course) to make 
> this folder live somewhere else. 

You don't have to change things manually. You right-click on the folder, 
select "properties", select "location", and give it a new location. 
Everything respects that nowadays, unless you're installing programs from 
the Win98 era perhaps.

> But I'm not sure how many programs 
> would actually take notice; ever tried installing Windows in, say, 
> D:\WINDOWS, and seeing programs stuff files into C:\WINDOWS anyway?

The "windows" directories are harder than the "doc&set" directories, yes.

> Yeah. The updater for Adobe Acrobat Reader likes to stuff the installer 
> files in a temp folder inside Documents and Settings. For no defined 
> reason.

Because that's where it has permission to write temp files. Putting it in 
the local tempfile direcotry would have been better, yes.

> I'm still wondering why no OS has yet come up with the idea of 
> seperating "documents" from "settings", but hey...

They did. They called it "the registry". Everyone bitched about it being 
separate from the file system. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

clipka wrote:
> I don't think Linux package managers will automatically 
> un-install those if you uninstall that image processing package 

Actually, Windows will do this, too. The problem is that not every installer 
will mark what dependencies it uses, so you'll often get the question "Hey, 
the DLL called <incomprehensible>.DLL looks unused, should I uninstall it?"

If some installer somewhere that someone wrote just looked to see some 
package was already installed and skipped the installation, instead of 
bumping the use count, then uninstalling X mysteriously breaks Y, which of 
course is exactly what everyone complains about on Windows.

Many, many of these problems are caused by lazy third-party programmers. 
Windows would be a lot cleaner if they only supported the latest version of 
stuff. :-) Or if MS had gotten everything right on the first try and never 
had to support the broken stuff.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> clipka wrote:
> > I don't think Linux package managers will automatically 
> > un-install those if you uninstall that image processing package 

> Actually, Windows will do this, too. The problem is that not every installer 
> will mark what dependencies it uses, so you'll often get the question "Hey, 
> the DLL called <incomprehensible>.DLL looks unused, should I uninstall it?"

  Btw, that's another annoying feature of Windows. Even though Windows
moved away from 8+3 characters long file names in 1995, most if not all
DLLs and other system files still adhere to that convention, for no
apparent or logical reason, so instead of getting a nice descriptive
file name telling you exactly what the DLL is for, you get a crpyptic
8-characters-long name which could well be random for all you know.

  Why are they doing that? I understand it that they did it the first
few years, but even today, 14 years later? That makes no sense.

-- 
                                                          - Warp

Post a reply to this message

>> I'm told you can change some registry key (manually of course) to make 
>> this folder live somewhere else. 
> 
> You don't have to change things manually. You right-click on the folder, 
> select "properties", select "location", and give it a new location. 

And which version of Windows do you need for this option to appear?

> Everything respects that nowadays, unless you're installing programs 
> from the Win98 era perhaps.

Heh. On Monday, I've got to see if a Windows 2.0 program works OK under 
Windows XP. The fun part? To run it, you must replace SERIAL.SYS with a 
custom modified version. (!!)

It still amuses me that this program can't print on any network printer 
who's name is more than 8 characters long...

>> Yeah. The updater for Adobe Acrobat Reader likes to stuff the 
>> installer files in a temp folder inside Documents and Settings. For no 
>> defined reason.
> 
> Because that's where it has permission to write temp files. Putting it 
> in the local tempfile direcotry would have been better, yes.

Oh, sure, it could put the installer file in

   %profile%\Local Settings\Temp

But it doesn't. It puts it in

   %profile%\Application Settings\Adobe\Acrobat\Updater

The Java installer does something similarly retarded for some reason. 
Maybe it's an IE quirk of some kind?

>> I'm still wondering why no OS has yet come up with the idea of 
>> seperating "documents" from "settings", but hey...
> 
> They did. They called it "the registry". Everyone bitched about it being 
> separate from the file system. :-)

You can't put, for example, the Word "normal" template in the registry. 
But then, I guess it depends on what you consider to be "settings" and 
what is "documents"...

FWIW, I think the registry actually works quite well for what it's 
supposed to be for. You can lock it down with security, it's got 
seperate user and system sections, and so on. The only real flaw is that 
it's more or less impossible to do manual things like copy one user's 
preferences to another user account, but only for one specific 
application. (Because you will never, ever determine which keys to copy...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> > many of the programs don't remove the data when they are uninstalled.

> Yeah. The old uninstallers would just delete that which they installed, 
> without actually cleaning out the data left behind. Usually leaving 
> directories sitting around where the game had saved state into the program 
> files subdirectories. Kind of a safety thing - don't uninstall the data just 
> because you uninstalled the program. Reasonable, but annoying sometimes.

  The best uninstallers ask you whether you want to also remove save files
and such, giving you the option of preserving them or removing them safely.
That's how all programs should do it, but unfortunately not many do.

  (Preserving save files can be handy if you want to uninstall a game which
you might want to re-install later and continue from where you got stuck,
if you are in the mood.)

-- 
                                                          - Warp

Post a reply to this message

>   Btw, that's another annoying feature of Windows. Even though Windows
> moved away from 8+3 characters long file names in 1995, most if not all
> DLLs and other system files still adhere to that convention, for no
> apparent or logical reason, so instead of getting a nice descriptive
> file name telling you exactly what the DLL is for, you get a crpyptic
> 8-characters-long name which could well be random for all you know.
> 
>   Why are they doing that? I understand it that they did it the first
> few years, but even today, 14 years later? That makes no sense.

I have no idea either, but it's pretty annoying.

The thing that makes me laugh is installers and splash screens and icons 
in glorious 256-colour dithered halftones. Um, WHY? We have 24-bit 
displays today, ya know. And *not* dithering the graphics makes it so 
much more compressible, while also looking much cooler...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

clipka wrote:
> in addition. I don't think Linux package managers will automatically 
> un-install those if you uninstall that image processing package (it 
> would be ill-advised, as I might have installed other, 
> non-package-managed software that also relies on that library).

Non-package-managed software installed by hand is of no concern to the 
package manager.  It will uninstall swiftly.

I'm used to compile up-to-date libs required by some hand-compiled 
up-to-date software and install it to my ~/lib.  It's only annoying to 
do the usual "LD_LIBRARY_PATH=~/lib foo" everytime, but, hey!, that's 
why bash history is for. :)

> The only difference is that in Linux this is less opaque, and having 
> additional libraries installed may therefore not be regarded as "growing 
> of the system".

At least .NET is capable of having multiple versions of the same lib 
installed at the same time.  The .NET runtime resolves the right 
dependency for each program.  So, as .NET advances through desktop apps, 
be prepared to see lots and lots more junk like this! XD

> The reason is that by convention, Unix software doesn't automatically 
> install (or even ship with) libraries it needs, while Windows software 
> comes full with all components required, automatically installing them 
> if not already present. I guess this is one of the core benefits and 
> banes of Windows.

Don't forget huge statically compiled executables... easy to install, no 
DLL hell and lots of space lost...

Post a reply to this message

Orchid XP v8 wrote:
> And which version of Windows do you need for this option to appear?

I think it was there in XP but you got to it a different way. I.e., it was 
buried in the control panel somewhere.

>> Everything respects that nowadays, unless you're installing programs 
>> from the Win98 era perhaps.
> 
> Heh. On Monday, I've got to see if a Windows 2.0 program works OK under 
> Windows XP. The fun part? To run it, you must replace SERIAL.SYS with a 
> custom modified version. (!!)

I'm not surprised. All the old 16-bit apps seemed to bypass the COM drivers 
and go right to hardware.

> The Java installer does something similarly retarded for some reason. 
> Maybe it's an IE quirk of some kind?

Could just be ... retarded! :-)  What makes you think the people writing the 
installers know anything more about Windows than you do? :-)

> You can't put, for example, the Word "normal" template in the registry. 
> But then, I guess it depends on what you consider to be "settings" and 
> what is "documents"...

Right. ANd yes, you probably could, but you wouldn't want to. :-)

> (Because you will never, ever determine which keys to copy...)

Yeah, I always thought so. It's very optimized for what it's good at. 
Unfortunately, it's quite undocumented as you say, and there's no permission 
system in Windows that's at a per-program level rather than a per-user level.

Which is kind of funny, given that nowadays how many people writing programs 
want to be in charge of your computer.  You would think by now people had 
figured out that the user might not want "the program from Adobe" to always 
have all the privs that the user has.  Altho Singularity has the only 
ACL-based permissions system I've ever seen address this.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Warp wrote:
>   Why are they doing that?

I don't know. I can't imagine anyone cares whether there's both a long name 
and a short name in the directories at this point. Disk space just isn't 
that dear. :-)

For the Windows stuff, I'd guess it's at least "ain't broke don't fix it". 
But anything written in the last 8 years or so should get over themselves. 
Certainly anything that won't run on Win98 shouldn't be using short names 
liek that.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Warp wrote:
>   The best uninstallers ask you whether you want to also remove save files
> and such, giving you the option of preserving them or removing them safely.
> That's how all programs should do it, but unfortunately not many do.

Exactly.  A lot of the cruft left behind is due to the fact it's commercial. 
Was it worth *their* time to add that question to the uninstaller? Sucks, 
but what are you going to do?

But the crap like caching java applets forever is hellishly annoying, I 
find. That grows forever. I can remember to clean up junk the thrice a year 
I uninstall something.

Now I have a bat file that deletes all the crap I can find I run before backups.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Orchid XP v8 wrote:
> I'm still wondering why no OS has yet come up with the idea of 
> seperating "documents" from "settings", but hey...

?

It's called the "registry", and it's one of the most complained about 
"features" of Windows.

...Chambers

Post a reply to this message

Orchid XP v8 schrieb:

> Heh. On Monday, I've got to see if a Windows 2.0 program works OK under 
> Windows XP. The fun part? To run it, you must replace SERIAL.SYS with a 
> custom modified version. (!!)

Uh - Windows TWO-point-zero?? Sure it isn't 3.1 at least? Who on earth 
used 2.0?

> It still amuses me that this program can't print on any network printer 
> who's name is more than 8 characters long...

Comes as not much of a surprise. It's rather a miracle that it can 
access networked printers at all...

> Oh, sure, it could put the installer file in
> 
>   %profile%\Local Settings\Temp
> 
> But it doesn't. It puts it in
> 
>   %profile%\Application Settings\Adobe\Acrobat\Updater
> 
> The Java installer does something similarly retarded for some reason. 
> Maybe it's an IE quirk of some kind?

I'd presume it's a safety measure to not end up with a crippled 
installation: Files in %profile%\Local Settings\Temp can be recycled by 
Windows' disk cleanup assistant. If the updater is designed using a 
multi-step approach, and there's a serious possibility that the steps 
may be run at very distinct points in time, you'll want those files to 
still exist when the second step commences.

If the updater cleans up after work, there shouldn' be a problem. If it 
fails to do, it somehow defies the exact purpose of the disk cleanup 
assistant, and would therefore need to be called poor design.

> You can't put, for example, the Word "normal" template in the registry. 
> But then, I guess it depends on what you consider to be "settings" and 
> what is "documents"...

Indeed, a clear line cannot always be drawn; for instance, are POV-Ray 
.ini files settings for POV-Ray, or are they part of the scene?

> FWIW, I think the registry actually works quite well for what it's 
> supposed to be for. You can lock it down with security, it's got 
> seperate user and system sections, and so on. The only real flaw is that 
> it's more or less impossible to do manual things like copy one user's 
> preferences to another user account, but only for one specific 
> application. (Because you will never, ever determine which keys to copy...)

Most software is pretty sane about this, storing /user/-specific 
settings in HKCU/Software/CompanyName/ProgramName, so the biggest 
obstacle is figuring the users' IDs.

Plus the fact that some software may not be using the registry to store 
settings, but files in one of the many %profile% subfolders instead.

Post a reply to this message

Darren New schrieb:
> clipka wrote:
>> I don't think Linux package managers will automatically un-install 
>> those if you uninstall that image processing package 
> 
> Actually, Windows will do this, too. The problem is that not every 
> installer will mark what dependencies it uses, so you'll often get the 
> question "Hey, the DLL called <incomprehensible>.DLL looks unused, 
> should I uninstall it?"

BTW, does Linux provide such a feature as well? If so, where does the 
"use count" live there?

Post a reply to this message

nemesis schrieb:
> clipka wrote:
>> in addition. I don't think Linux package managers will automatically 
>> un-install those if you uninstall that image processing package (it 
>> would be ill-advised, as I might have installed other, 
>> non-package-managed software that also relies on that library).
> 
> Non-package-managed software installed by hand is of no concern to the 
> package manager.  It will uninstall swiftly.
> 
> I'm used to compile up-to-date libs required by some hand-compiled 
> up-to-date software and install it to my ~/lib.  It's only annoying to 
> do the usual "LD_LIBRARY_PATH=~/lib foo" everytime, but, hey!, that's 
> why bash history is for. :)

I have no idea what you're talking about here, nor do I know whether you 
understood my point.

What I mean is this: Suppose I install a package-managed piece of 
software (let's name it "FooPNG" for now) that needs the libpng package. 
Of couse the package manager will recognize, and ask me whether I want 
to install the package as well. (Sure I do, yes please, go ahead.)

Now I compile this strange piece of software called POV-Ray, which 
obviously isn't package managed. But it needs the libpng nonetheless. No 
problem here, as the libpng is already there, so it compiles (and 
installs) fine.

Now I decide to uninstall FooPNG.

Will the package manager uninstall libpng as well, figuring that only 
FooPNG should rely on it? Will it leave libpng alone, figuring it 
/might/ be used by /some/ other app? Or will it actually have any way of 
/knowing/ that POV-Ray relies on it?

(I really don't care whether the package manager will uninstall 
/swiftly/ or /slowly/, I care /what/ it uninstalls :-))

Post a reply to this message

>> It still amuses me that this program can't print on any network 
>> printer who's name is more than 8 characters long...
> 
> Comes as not much of a surprise. It's rather a miracle that it can 
> access networked printers at all...

I'm guessing Windows does a sufficiently good job of pretending they're 
actually local. ;-)

We have another program that goes with this one. It's written in QBASIC. 
It requires a laser printer that understands PCL to be mapped to LPT2:. 
(I'm not sure what I could add to this description that would make it 
sound any worse...)

>> Oh, sure, it could put the installer file in
>>
>>   %profile%\Local Settings\Temp
>>
>> But it doesn't. It puts it in
>>
>>   %profile%\Application Settings\Adobe\Acrobat\Updater
>>
>> The Java installer does something similarly retarded for some reason. 
>> Maybe it's an IE quirk of some kind?
> 
> I'd presume it's a safety measure to not end up with a crippled 
> installation: Files in %profile%\Local Settings\Temp can be recycled by 
> Windows' disk cleanup assistant. If the updater is designed using a 
> multi-step approach, and there's a serious possibility that the steps 
> may be run at very distinct points in time, you'll want those files to 
> still exist when the second step commences.
> 
> If the updater cleans up after work, there shouldn' be a problem. If it 
> fails to do, it somehow defies the exact purpose of the disk cleanup 
> assistant, and would therefore need to be called poor design.

It downloads the installer, runs it, and then JUST LEAVES IT THERE. So, 
yeah, poor design.

But then again, as Warp pointed out, Java likes to cache every applet 
you've ever run, and provides no easy way (that I can discover) to 
remove this cache...

> Most software is pretty sane about this, storing /user/-specific 
> settings in HKCU/Software/CompanyName/ProgramName, so the biggest 
> obstacle is figuring the users' IDs.
> 
> Plus the fact that some software may not be using the registry to store 
> settings, but files in one of the many %profile% subfolders instead.

The really fun thing is that you can't edit a user's registry chunk 
without loading it first...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New wrote:

> Now I have a bat file that deletes all the crap I can find I run before 
> backups.

I had that.

Then I discovered that it can't delete the IE web cache. (Due to some 
kind of weirdness with it being system and hidden or something like 
that.) So I switched to a Tcl script. Even built a little Tk GUI for it, 
so you can see how much longer it's going to take. (Deleting 0.8GB of 
web cache takes a while...)

And then I switched it to Haskell, so I could more precisely control the 
file deletion algorithm. And I added logging. And I ran it as a service, 
scripted to run on the profile server every 300 seconds...

And then HQ IT decided that roaming profiles were too efficient, and 
disabled them. Now every...single...time...I set up a new PC, I have a 
stream of people asking me to come over and configure their email 
settings. And people whining that they have to adjust their Word 
settings manually for every PC they use. *sigh*

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Sat, 19 Sep 2009 22:15:24 +0200, Darren New <dne### [at] sanrrcom> wrote:
> But the crap like caching java applets forever is hellishly annoying, I  
> find. That grows forever.

Are you talking about the deployment cache? If so, you can change that in  
the Java control panel. Alternatively, CCleaner can clear it for you.



-- 
FE

Post a reply to this message

Orchid XP v8 schrieb:
> The really fun thing is that you can't edit a user's registry chunk 
> without loading it first...

You could generate a registry patch (I think .reg is the extension) that 
would be written to the HKCU tree, and somehow make sure that thing 
executed next time the user logs in.

(The only thing which is a real nuisance there is that this doesn't 
allow you to /delete/ registry keys.)

Post a reply to this message

On Sun, 20 Sep 2009 18:11:27 +0200, clipka <ano### [at] anonymousorg> wrote:
> You could generate a registry patch (I think .reg is the extension) that  
> would be written to the HKCU tree, and somehow make sure that thing  
> executed next time the user logs in.
>
> (The only thing which is a real nuisance there is that this doesn't  
> allow you to /delete/ registry keys.)

Of course it does. What makes you think otherwise?



-- 
FE

Post a reply to this message

Fredrik Eriksson schrieb:
> On Sun, 20 Sep 2009 18:11:27 +0200, clipka <ano### [at] anonymousorg> wrote:
>> You could generate a registry patch (I think .reg is the extension) 
>> that would be written to the HKCU tree, and somehow make sure that 
>> thing executed next time the user logs in.
>>
>> (The only thing which is a real nuisance there is that this doesn't 
>> allow you to /delete/ registry keys.)
> 
> Of course it does. What makes you think otherwise?

Experience.

Name any syntax in a .reg file that will make a registry key /disappear/ 
when that .reg file is executed.

(And I'm not talking about setting it to zero or an empty string or some 
such, I mean really /eliminating/ it.)

Post a reply to this message

clipka wrote:
> Indeed, a clear line cannot always be drawn; for instance, are POV-Ray 
> .ini files settings for POV-Ray, or are they part of the scene?

Generally, if the user can change them, they shouldn't be in the 
program-files directory. :-)

> Most software is pretty sane about this, 

Mainly because that's the only place users have permissions to write. :)

Altho I have had software that was licensed per-user that stored its 
licensing settings in the per-machine area. It was broken in many other ways 
too, and written by the CEO's son, so I wasn't surprised.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Orchid XP v8 wrote:
> remove this cache...

I've found that almost everyone stores junk with either the word "temp" in 
it or the word "cache" in it, so it's actually not too hard to do a scan and 
find most of the places accumulating cruft.

> The really fun thing is that you can't edit a user's registry chunk 
> without loading it first...

But not as the user.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

clipka wrote:
> You could generate a registry patch (I think .reg is the extension) that 
> would be written to the HKCU tree, and somehow make sure that thing 
> executed next time the user logs in.

You have to load the hive. You don't have to load the hive under HKCU.

> (The only thing which is a real nuisance there is that this doesn't 
> allow you to /delete/ registry keys.)

Yes you can.

[HKEY_LOCAL_MACHINE\SOFTWARE\Blah\Blah\Blah]
"DeleteThisKey"=-

[-HKEY_LOCAL_MACHINE\SOFTWARE\Blah\Blah\Blah]

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

On Sun, 20 Sep 2009 18:59:07 +0200, clipka <ano### [at] anonymousorg> wrote:
> Experience.
>
> Name any syntax in a .reg file that will make a registry key /disappear/  
> when that .reg file is executed.
>
> (And I'm not talking about setting it to zero or an empty string or some  
> such, I mean really /eliminating/ it.)

http://support.microsoft.com/kb/310516

Scroll down to "Deleting Registry Keys and Values".



-- 
FE

Post a reply to this message

clipka wrote:
> BTW, does Linux provide such a feature as well? If so, where does the 
> "use count" live there?

Each package manager has its own way of dealing with such things. In the PM, 
it's somewhere in the mess of stuff stored under /var

I.e., it's handled by the package manager, not by install scripts and so on, 
so if you compile and install from source, it's not going to bump the use 
count on your libraries.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Orchid XP v8 wrote:
> Darren New wrote:
> 
>> Now I have a bat file that deletes all the crap I can find I run 
>> before backups.
> 
> I had that.
> 
> Then I discovered that it can't delete the IE web cache. (Due to some 
> kind of weirdness with it being system and hidden or something like 
> that.)

Well, you do have to turn that off. "attrib -h -s junkdir /s"

> So I switched to a Tcl script. 

That was the first one. Now I'm more lazy. :-)

> Even built a little Tk GUI for it, 
> so you can see how much longer it's going to take. (Deleting 0.8GB of 
> web cache takes a while...)

You can do this with "disk cleanup" tho.

> And then HQ IT decided that roaming profiles were too efficient, and 
> disabled them. Now every...single...time...I set up a new PC, I have a 
> stream of people asking me to come over and configure their email 
> settings. And people whining that they have to adjust their Word 
> settings manually for every PC they use. *sigh*

Sounds like you need to point out to your boss that machine inefficiencies 
are designed to reduce human inefficiencies.  Here's an example where you 
have people on your side - everyone actually working there hates the change, 
so you can tell them "I won't be able to get to fixing the problem for three 
hours. In the meantime, tell your boss you need roaming profiles."

Damn, you need a new job.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Fredrik Eriksson schrieb:
> http://support.microsoft.com/kb/310516
> 
> Scroll down to "Deleting Registry Keys and Values".

Ah, that's definitely news to me. So either they must have changed it 
since I looked last, or it wasn't documented back then. I must confess 
that it was quite a while ago.

Post a reply to this message

Darren New schrieb:
> 
> I.e., it's handled by the package manager, not by install scripts and so 
> on, so if you compile and install from source, it's not going to bump 
> the use count on your libraries.

That's what I wanted to know - thanks.

So, Windows is actually a lot better at this... /theoretically/.

Post a reply to this message

clipka wrote:
> nemesis schrieb:
>> Non-package-managed software installed by hand is of no concern to the 
>> package manager.  It will uninstall swiftly.
>>
>> I'm used to compile up-to-date libs required by some hand-compiled 
>> up-to-date software and install it to my ~/lib.  It's only annoying to 
>> do the usual "LD_LIBRARY_PATH=~/lib foo" everytime, but, hey!, that's 
>> why bash history is for. :)
> 
> I have no idea what you're talking about here, nor do I know whether you 
> understood my point.
> 
> What I mean is this: Suppose I install a package-managed piece of 
> software (let's name it "FooPNG" for now) that needs the libpng package. 
> Of couse the package manager will recognize, and ask me whether I want 
> to install the package as well. (Sure I do, yes please, go ahead.)
> 
> Now I compile this strange piece of software called POV-Ray, which 
> obviously isn't package managed. But it needs the libpng nonetheless. No 
> problem here, as the libpng is already there, so it compiles (and 
> installs) fine.
> 
> Now I decide to uninstall FooPNG.
> 
> Will the package manager uninstall libpng as well, figuring that only 
> FooPNG should rely on it? Will it leave libpng alone, figuring it 
> /might/ be used by /some/ other app? Or will it actually have any way of 
> /knowing/ that POV-Ray relies on it?
> 
> (I really don't care whether the package manager will uninstall 
> /swiftly/ or /slowly/, I care /what/ it uninstalls :-))

I understood your point.  Hand-compiled and installed povray or any 
other is of no concern to the package manager.  Thus, it'll uninstall 
libpng without caring if hand-compiled povray uses it or not.  It 
doesn't even know hand-compiled povray exists.  Nor should it.

In any case, povray 3.6 is featured as part of the Ubuntu multiverse 
repositories... :)

Post a reply to this message

clipka wrote:
> Darren New schrieb:
>>
>> I.e., it's handled by the package manager, not by install scripts and 
>> so on, so if you compile and install from source, it's not going to 
>> bump the use count on your libraries.
> 
> That's what I wanted to know - thanks.
> 
> So, Windows is actually a lot better at this... /theoretically/.

I wouldn't say that. It's just that the installer for WIndows comes with the 
program. If I compile something from scratch on Windows and it uses some 
DLL, I'm not going to be able to ensure that DLL doesn't get deleted out of 
the system either.

It's still the "package manager" part of Windows handling it. It's just that 
Windows installers talk to the package manager as they run.  (And indeed, 
the whole "MSI" bit is making software more into Linux-style packages.)

I think the real difference is that there are relatively few DLLs that are 
shared amongst multiple programs from multiple companies but not part of the 
system. I.e., most programs that need graphics stuff either puts libpng.dll 
into the application's directory or it uses the graphics libraries that 
already come with Windows. Linux apps tend to have a lot more references to 
"random" underlying libraries that aren't officially part of "Linux" as 
such.  Windows uses "components" for the bits that are shared, and those are 
in the registry and thus tracked the way they're supposed to be. The places 
where you have lots of common functionality (e.g., Office), you have a 
"common files" directory, and your installer is set up to deal with the 
stuff in there appropriately. (I.e., there's a lot of help from Windows 
installers for shared but not universal functionality, in part because the 
writers of Windows also make a lot of money selling stuff with a lot of 
shared functionality like Office and MSSQL and such.)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

nemesis wrote:
> I understood your point.  Hand-compiled and installed povray or any 
> other is of no concern to the package manager.  Thus, it'll uninstall 
> libpng without caring if hand-compiled povray uses it or not.  It 
> doesn't even know hand-compiled povray exists.  Nor should it.

"It'll break your code, *and* it *should*!"  Ah, the mindset you can get 
away with when writing non-commercial software. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New wrote:

> if you compile and install from source, it's not going to bump 
> the use count on your libraries.

Excellent fun. Compile something from source, and the package manager 
doesn't know you have it, and tries to install it again.

Weirdly, most software you compile from scratch has an uncanny ability 
to figure out what libraries are installed, no matter whether you're 
using RPM or DEB or EMERGE or...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> I had that.
>>
>> Then I discovered that it can't delete the IE web cache. (Due to some 
>> kind of weirdness with it being system and hidden or something like 
>> that.)
> 
> Well, you do have to turn that off. "attrib -h -s junkdir /s"

Yeah, I think I tried that too. Basically there was something or other 
"magical" about that folder. Windows Explorer could delete it, but from 
the DOS box is was unclear whether it existed, couldn't quite be 
deleted, etc. I don't know if it was the attributes or the desktop.ini 
file or just a magic path hard-coded into the system or what... Tcl 
killed it without difficulty though. Haskell too. (All the more amusing, 
since Haskell is running under a Unix emulator...)

>> Even built a little Tk GUI for it, so you can see how much longer it's 
>> going to take. (Deleting 0.8GB of web cache takes a while...)
> 
> You can do this with "disk cleanup" tho.

Not programatically. And not on a roaming profiles folder on the server.

> Damn, you need a new job.

Really?! o_O

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> Darren New wrote:
> 
>> if you compile and install from source, it's not going to bump the use 
>> count on your libraries.
> 
> Excellent fun. Compile something from source, and the package manager 
> doesn't know you have it, and tries to install it again.

Or you get to make up a package file by hand.

The worst I ever dealth with was a package that needed a very specific 
version of Boost, and since Linux doesn't do the whole "side by side" thing 
very well,

> Weirdly, most software you compile from scratch has an uncanny ability 
> to figure out what libraries are installed, no matter whether you're 
> using RPM or DEB or EMERGE or...

It's not that uncanny. It tries to compile the code, and if the compiler 
returns error messages, it knows why.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> Weirdly, most software you compile from scratch has an uncanny ability 
> to figure out what libraries are installed, no matter whether you're 
> using RPM or DEB or EMERGE or...

  Most libraries are installed in a directory which the compiler directly
checks when you tell it to link that library in. Thus to check whether the
library is in the system it's enough to try and compile something which
tries to link that library and see if it succeeds.

  Moreover, all libraries are installed in the same few semi-standard system
directories in all popular Unix-based operating systems, so even if the
compiler is not used to check for the existence of the library, it's just a
matter of looking for them in those established directories.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v8 wrote:
>> You can do this with "disk cleanup" tho.
> Not programatically. And not on a roaming profiles folder on the server.

True. Not without COM, and not if the profiles aren't logged in.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> nemesis wrote:
> > I understood your point.  Hand-compiled and installed povray or any 
> > other is of no concern to the package manager.  Thus, it'll uninstall 
> > libpng without caring if hand-compiled povray uses it or not.  It 
> > doesn't even know hand-compiled povray exists.  Nor should it.

> "It'll break your code, *and* it *should*!"  Ah, the mindset you can get 
> away with when writing non-commercial software. :-)

  What's the package manager going to do? Scan the entire system for
executables which might be using that library? Sure, it could do that,
if you want to wait.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   What's the package manager going to do? Scan the entire system for
> executables which might be using that library? Sure, it could do that,
> if you want to wait.

Even that wouldn't necessarily work. Note I didn't say there was an easy fix 
for the problem. I was mocking the attitude that since there isn't an *easy* 
fix, then it *should* break.  I.e., that the attitude is "this should be 
broken" rather than "this is regrettably broken."

But sure, if you uninstall stuff and it leaves libraries around, I can 
imagine a button you could push that says "Scan all the executables right 
now and tell me what libraries are installed that no executable references." 
Along with "tell me the last time someone loaded this library."  Then you 
could clean things up that stopped being used when you deleted some package 
six months ago.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New schrieb:

>> So, Windows is actually a lot better at this... /theoretically/.
> 
> I wouldn't say that. It's just that the installer for WIndows comes with 
> the program. If I compile something from scratch on Windows and it uses 
> some DLL, I'm not going to be able to ensure that DLL doesn't get 
> deleted out of the system either.

Yes, but I *can* roll my own installer to do it.

And it's standardized. It's not like I'd need to make an installer for 
Debian, another for Ubuntu, yet another for what-have-you-not...

Post a reply to this message

Orchid XP v8 schrieb:
> 
> Weirdly, most software you compile from scratch has an uncanny ability 
> to figure out what libraries are installed, no matter whether you're 
> using RPM or DEB or EMERGE or...

Have you ever had a look how that actually works?

Just look at the "configure" script for POV-Ray for an example.

That script actually goes ahead and generates source code for tiny test 
programs, and checks if they compile, link and run. For instance, if the 
script manages to compile and run a program that tries to call 
png_access_version_number(), it knows that libpng is there - and also 
what version number it is.

Of course the script first verifies that the shell is compatible with 
the command syntax used in the script, goes on to find out what compiler 
to use, and so on...

Post a reply to this message

clipka wrote:
> Yes, but I *can* roll my own installer to do it.

And you can in Debian too, at least. It's just annoying to have to do it, 
but that's what you get when you are compiling source. Basically, you make 
up a fake package description and say "here, I just installed this."

> And it's standardized. It's not like I'd need to make an installer for 
> Debian, another for Ubuntu, yet another for what-have-you-not...

Nah. One for XP, one for Vista, one for Win7... ;-)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message