 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/21/2011 8:13 PM, Darren New wrote:
> Patrick Elliott wrote:
>> Yeah. All well in theory, but a lot of stuff is downloads, others are
>> from discs that I may not know the location of,
>
> Sure. I'm just saying that when I install crap, one of the install steps
> is "store this on the "S:\Software" drive along with a text file saying
> any particular pain I had in installing it." It's advice for next time,
> not this time. :-)
>
>> How hard would it have really been to track which changes a specific
>> application made to the registry, then let you "migrate" the damn
>> things by processing out the registry data for it.
>
> The problem with third-party apps is ensuring they only write to the
> areas they're supposed to write to. It would be pretty trivial if you
> could count on apps only storing stuff in the parts of the file system
> and registry where they're supposed to.
>
Well, that is true, but they built this mess, and then didn't even
consider that an audit log of some sort might be *vaguely* helpful. Just
saying...
--
void main () {
If Schrödingers_cat is alive or version > 98 {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott wrote:
> Well, that is true, but they built this mess, and then didn't even
> consider that an audit log of some sort might be *vaguely* helpful. Just
> saying...
There *is* an audit log. However, given all possible third-party apps,
saying "just move the registry entries" doesn't work. If you go from
\documents and settings\... to \users\... all your registry entries will be
wrong.
--
Darren New, San Diego CA, USA (PST)
"How did he die?" "He got shot in the hand."
"That was fatal?"
"He was holding a live grenade at the time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23-2-2011 4:16, Patrick Elliott wrote:
> On 2/22/2011 1:04 AM, andrel wrote:
>>> In my experience finding
>>> *anything* that isn't from the US is like throwing a dart, blindfolded,
>>> while someone moves the dart board, in another room, and trying to bank
>>> the shot off a door that is swinging open and closed. You might get
>>> lucky, or you might find that everything from the direction you are
>>> facing, to the position of the door, to the fact that the guy holding
>>> the board set it down to take a lunch break, all conspire to refuse
>>> you. ;)
>>
>> Nice hyperbole but I don't think the nationality of the maker has
>> anything to do with how easily you can find it. If it is not from the US
>> the exposure in the US in other media will in general (but not e.g.
>> Harry Potter) be lower and you may not know about it's existence, but it
>> shouldn't influence results too much.
>>
> This was in reference to search in general *not* to searching for
> something from another country. If you don't have the exact search
> right, often what you end up with is a disaster. Had that issue looking
> for books for my mother's Kindle for her. Last name got it, usually, but
> sometimes listed like 495 books. The title, not so much, the first *and*
> last name... don't bet on it always working, if at all. Drives me nuts
> how bad search can be a lot of the time.
>
It is one of those skills, aka black arts.
--
Apparently you can afford your own dictator for less than 10 cents per
citizen per day.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/23/2011 9:50 AM, Darren New wrote:
> Patrick Elliott wrote:
>> Well, that is true, but they built this mess, and then didn't even
>> consider that an audit log of some sort might be *vaguely* helpful.
>> Just saying...
>
> There *is* an audit log. However, given all possible third-party apps,
> saying "just move the registry entries" doesn't work. If you go from
> \documents and settings\... to \users\... all your registry entries will
> be wrong.
>
Hmm. To an extent, yeah. But something that could use the audit log of
what got changed, by who, means you could move files like that and
"point" the directory at the right place, at least in principle. Once in
a while you get something that won't play right, but, in general, this
isn't an issue. What bugs me is that even when you *have* the option to
move such things, three things happen:
1. The pointer gets moved.
2. The files don't (gee.. you would think this *might* cause some sort
of issue, maybe?).
3. Some small number of applications will use their registry entry for
where those where, instead of asking the system where they should be now.
These are fixible. My point is, if you know where the damn files where
supposed to be, according to the assumption of the application, and its
changable, you should be able to have that change go through by doing 2
and 3 properly at the same time, since you know there are files in there
the damn thing wrote, and you *also* know while applications are looking
in their *for* those files (at least in principle).
Yeah, you might break something some place, like an app that looks into
someone else's data, which you put in there, but is now looking in the
wrong place, or some cases where more than one is sharing a common
folder, but in that later case, you should know, from any sort of audit
log, which of those files *it* created, so would need to have moved.
Point is, this monolithic mess pretty much precludes any sort of easy
reinstall of *anything*, since any reinstall you make, unless the thing
being altered is *purely* data, not configuration, or other things you
need to work when moved, you are hosed. Got a MySQL thing on here I
don't even want to contemplate installing to a new machine. Not because
I doubt its hard, just likely to be more complicated than it first
seems, precisely *because* its frakking Windows that the thing is
installed on, and that just really makes things way more interesting
when do this stuff. lol
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott wrote:
> you should know, from any sort of audit
> log, which of those files *it* created, so would need to have moved.
Not really. If a program invokes BITS (or wget) to download files it needs,
it's not going to get audited. If it creates an index file, then later fills
the index with the names of files you created, that's not going to get
copied properly. If you use the SQL server engine to create a database for
your document indexer, is that the SQL server or the document indexer
creating that file?
> Point is, this monolithic mess pretty much precludes any sort of easy
> reinstall of *anything*, since any reinstall you make, unless the thing
> being altered is *purely* data, not configuration, or other things you
> need to work when moved, you are hosed.
You're oversimplifying. And it's certainly not easy to come up with a
standard way of moving such things.
> Got a MySQL thing on here I
> don't even want to contemplate installing to a new machine. Not because
> I doubt its hard, just likely to be more complicated than it first
> seems, precisely *because* its frakking Windows that the thing is
> installed on, and that just really makes things way more interesting
> when do this stuff. lol
Except MySql is originally UNIX code. It's just as hard to move the
installation of something complex in UNIX as is it in Windows. If everyone
follows the rules about where to put things, it's *easier* to move it under
Windows than under UNIX, since there's actually specific places reserved for
various kinds of internal data that come with a program in Windows, while
there's no good standard on (for example) how to name a dot-file in the home
directory or a config file in /etc to define what program it's configuring.
Trust me: Moving a MySql installation actually requires you to know where
all the configuration information for MySql is stored and how on Linux as
well as Windows. :-) If a program goes outside of where it's supposed to be
storing configuration information, it's no easier to find it in Linux than
in Windows. (Altho the Singularity OS from Microsoft is actually making
good strides towards fixing this, since permissions are based not only on
users but on programs as well.)
--
Darren New, San Diego CA, USA (PST)
"How did he die?" "He got shot in the hand."
"That was fatal?"
"He was holding a live grenade at the time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/23/2011 1:57 PM, Darren New wrote:
> Patrick Elliott wrote:
>> you should know, from any sort of audit log, which of those files *it*
>> created, so would need to have moved.
>
> Not really. If a program invokes BITS (or wget) to download files it
> needs, it's not going to get audited. If it creates an index file, then
> later fills the index with the names of files you created, that's not
> going to get copied properly. If you use the SQL server engine to create
> a database for your document indexer, is that the SQL server or the
> document indexer creating that file?
>
Umm.
In the first case, you adjust BITS, or wget, so it logs the audit with
which application asked it to install the stuff, or something. This
isn't impossible, its just lazy, and has been for so long that the
problem has grown out of proportion to any relatively minor issues that
might have cropped up as a result of trying to do it right in the first
place.
In the second case, SQL, since your application should only care how to
talk to, and maybe where, the SQL is not where the documents end up.
But, yeah, it can get complex.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott wrote:
> In the first case, you adjust BITS, or wget, so it logs the audit with
> which application asked it to install the stuff, or something.
If you distinguish "install" from "write files", it's easier, yes. OK, so
firefox downloads and installs Adobe, which includes a plug-in for firefox.
Then you uninstall firefox. What happens? :-)
> In the second case, SQL, since your application should only care how to
> talk to, and maybe where, the SQL is not where the documents end up.
My point is that you wind up having to copy specific records out of a SQL
database when you move the files those records refer to, etc.
Singularity addresses this problem. You have clear distinctions between
executable code and data files and configuration files. You can't install
executable code without it being in a manifest, which gets checked when you
install it to make sure it's compatible with everything else. The
application doesn't get handles to any part of the file system it didn't ask
for in the manifest, so it can't spew config files in odd places. Etc etc
etc. The only problem is you have to throw out all that code you already have.
--
Darren New, San Diego CA, USA (PST)
"How did he die?" "He got shot in the hand."
"That was fatal?"
"He was holding a live grenade at the time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
