Re: Drag it to the trash...

"GreyCloud" <mist@xxxxxxxxxxx> wrote in message
news:NpWdnXA6sruPG8_ZRVn-ig@xxxxxxxxxxxxxx
Daniel Johnson wrote:
Even if an admin is willing to do that, finding roaming
profiles is not possible, so he can only get the ones that
do not roam.

There might be a piece of software utility out there to help in finding
and administering these "roaming profiles" for windows.
Not exactly what I'd expect tho. Other systems don't have that problem.

I don't think such software exists. Other systems don't do roaming
profiles like this; your home directory may be remote, but if remote
it stays remote: a local copy is not made.

[snip]
That's like DOS's AUTOEXEC.BAT!

Which Gates copied from DEC.

This concept has a really long history. I don't know who
came up with these session initialization scripts, but it's
still a bad idea for an end-user system.

And history shows that Bill did do some dumpster diving in Bellevue when
he was a lad. Of course the DEC DCL is quite a bit more advanced and
comprehensive than dos was.

He could have found this diving in many different dumpsters.

The DEC system hardwired some names to the kernel. These are
SYS$LOGIN.COM, SYS$STARTUP.COM, SYS$LOGICALNAMES,
and a few more that can't make it thru to the top.

The kernel seems a very strange place to put this, really.

Hard drives are somewhat prewired by name to an extent, like DMA0: or
DMA1:, MUA0: etc. But then the user can just poke into his own
sys$login.com file as alias : $ DMA0: == Bert. Then when he needs to
make a sub directory, all he has to do is use CREATE/DIR
[Bert:mydirectory].

This is interesting, but a little clumsy next to mount-points, I think.

There are a lot of things one can do, but if it goes too far it can get
confusing with too many aliases. Even the DCL commands dictionary can be
customized for the end user by deleting most of the commands you don't
want them to have access to or by renaming some commands that fit the
users needs. And its all in text form.

That's not terribly special; most shells support some sort of
aliasing.

These sorts of files are not "plain text"; they are *programs*
(written in DCL I should think) and expecting installers to modify them
is a bit much. Expecting ordinary users to do so is out of the question.

No, just plain text files. You have to realize that the VMS file system
is ISAM by default if you need to access things in a sorted order.

Yes, I know about RMS. They did not store these files in
such a form; had they done so, it would not have worked since
the program the script encodes would have executed out of order.

But all one has to do from a terminal is type in EDIT SYS$LOGIN and the
file appears onscreen. A normal text editor. No installation program at
all.

This confronts the user with a small program in a scripting language,
and expects him to edit it. It's completely infeasable for typical
end-users.

When the sysadmin loads a new large commercial program onto a vms system,
the so called installer is basically just a script that has been given
priviledges to create files and directories, make changes to the system
logical tables, and creating new aliases. But these are all text files.

That they are text files is not the point; if this installer tries to edit
SYS$LOGIN, it is editing a script and it must understand the logic
of the script to do so. This is not possible in general, and so the
installation can't be done reliably.

[snip]
This is really sort of archaic. It's a lot of complexity for no real
benefit; you only need 2 levels in hardware and you can do everything
else in software, where you can at least fix the bugs.

It still qualifies for the higher levels of certs than any UNIX system can
attain.

That's because of the software. VMS has a very nice security
architecture. But you do not need more than 2 levels of access
in hardware to do all that.

VMS is really for those companies that need hard security at the system
level and yet the company must also add physical security to attain an A
level.

Yes, that's the way it works. There's a reason why Bill & Co ripped
of VMS, not Unix. :D

Most of my sysadmin techniques relied on programming a dedicated
terminals function keys to do different tasks... by logging in and
pushing the correct (1) function key.

That is pretty poor UI by modern standards, of course.

From a terminal it allows the user to customize things to their own needs,
not hardwired by someone else that thinks that is what you need.
Each installation is going to be different.

That is, of course, a tech-support problem. Yet users do desire
it; one wants to strike a balance here.

Still, users generally do *not* like customizability if it comes
at the expense of good UI to start with. They want something
friendly that they can then customize.

[snip]
This is *not* true. Databases are very corruption-resistant
because of the journalling techniques they use.

Well then, is the registry journalled and is XP a journaling file system?

Yes to both.

However, VFAT is not journaled. The default filesystem on XP
is NTFS, but you might chose to use VFAT (say, for Mac OS X
compatibility). If you do this, it is not very reliable and anything
built on it wil also be unreliable- registry included.

I know that Linux 2.6 using ResierFS is journaling. So is VMS.
As well as Tiger.

Yes. NTFS has had journalling in since day one. Mac OS X
was actually quite late to this game.

Even non-database-like binary files are more robust than text
files as a rule. Text files are more complex so that they may be
made human-readable: they support comments and
non-significant whitespace. They must tolerate ASCII,
UTF-8, UTF-16, and gawd knows what other encodings.

Uh, that is what text files are... straight ASCII.

Text files may be encoded in many ways. You may think
they are simple and trivial, because to the user they seem
transpaent, but it's not so.

That is why XML files start off with that <?...> header. If
you know the first characters of the file are <?, you can
autodetect the encoding.

Worse, human-readable files are almost always seen as
human-writable first. The text file can easily be *structurally*
corrupted by a careless user. And even careful users make
mistakes sometimes.

From that point of view, yes, but not being able to be corrupted without
human interference. I'm thinking along the lines of having a file open
and then the power goes out.

It is possible to do (small) text files in such a way as to protect
them from this- you write your changes into a new copy first,
flush them, and then swap the new and old files. This last operation
is protected by the filesystem journal, and so you are safe.

But you can do that with binary files, and with binary files it's
possible to implement transactions. You need to design your
format properly, but there's no mystery to it.

If your files are *large*, then of course text files won't scale
for this and other reasons, and you have to go binary. But
for preferences, text will do.

(For the object registrations- which is really the raison d'etre for
the registry in the first place- it won't. There are a lot of them!)

A text file won't corrupt. I've never seen one yet that did it.

I certainly have. For instance, one client broke his IIS web.config
file. It was an XML file, and he accidentally typed a single space
at the start- right before the <?. This defeated encoding detector,
and the file could no longer be read.

With the registry, he could not have done that.

Text files usually have *lots* of things of this sort you can
break.

I've seen IBM ISAM files get easily corrupted from a power failure.

Well, presumably that database does not support transactions,
and IBM keeps it around for compatibility.

Had they been text files, they would also have been corrupted in
the same way- they are surely too big to do the 'rewrite and swap'
trick.

[snip]
No. This is the great weakness of the design. This is why
you sometimes really do need to rebuild a Windows system
from scratch.

Sounds like an opportunity for a programmer to make one.
Would be very helpful for those that have to work with windows.

Yes, but how do you implement it?

If it can be done, it would be nice for MS to include it as
a standard feature!

[snip- text vs binary again]
Except that prefs are individual and go with the app.
There isn't a central registry that gets involved.

Prefs files do not go with the app: they go in your
~/Library/Preferences directory. They aren't all
kept in one file, but this does not make any difference
since they *are* all in the same directory.

Everything technically is in one directory... the hard drive. If it fails
everything goes.

Very true.

Consider this: you could 'split out' the registry into
the filesystem, so that each key is a directory and
the values could be stored in a file. Perhaps a plist-like
file even. :D

The registry APIs could be rewritten to access these
direcetories. This would simplify the implementation
since a large part of what the registry does is already
done by the filesystem.

But simplicity is all you'd gain. Both systems boil down to
a block of bytes in the end, and both must explicitly
implement a lot of stuff- including journaling for safety-
on top of that.

The registry is done in a small number of larger files
because this is much more space efficient, even on
NTFS. On VFAT, with its gigantic clusters, the
wasted space of the approach I've outlined would
be monumental.

[snip]
Yes.

Ok. I went thru that learning visual C++ a long time ago about
serialization of files.
Not sure I like the approach tho.

Well, you wouldn't be much of a MS-basher if you
*did* like it, now would you?

[snip]
I wonder. But maybe you do. In any case, it can't. It can
regenerate prefs like the Mac does, but the bulk of the
registry is not prefs.

I know. Things like the title bar for IE modified by AT&T.
Try and hunt down all of their modifications. A true PITA.

This kind of thing really requires an uninstaller to do.

(But of course, then you are depending on AT&T to provide
one. What are the chances?)

[snip]
It can happen, but presumably MS works a little harder to make
Windows Media Player solid on Windows.

Caches do differ from prefs in one respect: caches are about
making a program *fast*, so there is a temptation to omit validation
if it would be expensive. After all, caches are private files of
the app, no-one should be editing them. So nothing can go wrong,
right? :D

Like all things, according to Murphys' law, it will happen.
The cure at least is easy.

The cure is the same on Windows. The registry is not suitable
for caches; it is not fast enough and cannot hold large enough
data volumes.

You should put them in your local temp directory. This way
the disk cleanup tool can, in theory, delete them for you.

I say "in theory" because it does not appear to actually
do this for per-user temp files, even for the user who
runs the tool. But, you know, *in principle* it could
work... :(

[snip]
Java was first released in 1996. It's still on the young
side, as languages go.

I thought it was derived from a project called OAK?
Back in the late 80s?

It's roots go much father back than that. In my opinion,
the only really *original* languages were Fortran, Lisp,
and COBOL. :D

However, if we 'date' languages in this way they are all
about 50 years old now. :D

[snip]
That was when things really were stagnating.

No, that was when real graphics took off at an affordable price.

Well, depending on what you mean by "real graphics".

The Amiga had advanced (for the time) graphics hardware
but hardly any software to drive it; programs that wanted to
use it had to access the hardware directly.

This meant that when the next-generation Amiga came out,
Commodore had to support the old modes and behaviors
so the old software would work. It also meant that that old
software could not take advantage of the new hardware
at all.

Had they been able to run *Apple's* OS on their
box, they might have done better. Apple had made
the *real* breakthrough: their platform was done entirely
in software, which proved far more flexible.

But Apple didn't have the advanced graphics hardware.

Also had multitasking and a linear address space vs the 8088.

Neither of these was in any way an innovation. *Segments*
were the innovation, but not all innovation is good. :D

[snip- agreement]

There were still good ideas then: the Amiga's graphics
architecture, the Macs GUI. But they stayed bottled up
on niche platforms.

But that's what made it interesting. I don't want everything standardized
on one platform. That just breeds monopolization
and more stagnation.

Hmm.

You seem to be using 'stagnation' differently than I would.

I wonder what you mean by it.

I see the '80s as a period of stagnation because clever
new technologies were 'blocked' by compatibility
concerns. The great new inventions got bottled up,
because to use them you had to sacrifice all your
existing hardware and software.

Remember that Commodore is dead, and they
died shortly after the *C64* become unviable.
The Amiga.. didn't matter.

They clever hardware was great, but it could not
overcome the burden of incompatibility.

[snip]
I do not wish to exagerate MS's own innovation: but they have
been an enabler for innovation. Their software makes each hardware
and software component independent, thereby making it possible for
other vendors to produce innovative products without having
to build 'a new o/s and hardware'.

But I see this as just a new level of stagnation. IOW, everything is now
made to the MS standard and leaves out any possibility of real innovation.

I do not know what you mean by "real innovation"; but
I wonder if you should call your "new level of stagnation"
something else... like say "progress". :D

It is true that there is not much room for innovation at the
core OS level; the NT kernel is pretty much like the
VMS one, and there are powerful forces that make it
very, very hard to anyone, even Microsoft, to change it
in any large way.

Without Windows, there would be no WinModems or WinPrinters;
there would have been no 3D revolution in gaming. No 3d-sound
cards.

I don't believe that. I don't like WinModems. They don't work with UNIX.
Better left in hardware.

They work just as well as "real" modems but are cheaper;
they are possible *because* the relevant part of the market
has written of Unix.

You lose one thing but gain another. It's a tradeoff.

3D revolution in Gaming? I think the Amiga got started there first.

The Amiga did not have 3d graphics; it had
accelerated 2d graphics.

But the Amiga did have something; yet very
few users ever saw it, because it was totally
incompatible with everything else. Not just with
commodity PCs: it was incompatible even with
Commodores top seller, the redoubtable
Commodore 64.

This happened because Commodore had nothing
like Windows.

Only Apple did, at first- and Apple could have changed
the industry, but they chose* to stay bottled up on their
expensive, propriety hardware.

This left the field open for someone else to do what
needed to be done, and that someone was Bill.

Plus the fact that the dedicated graphics chips allowed for true 3D
screens that I've yet to see in any of todays games.

What do you mean?

Amiga also had stereo sound and I'd believe that if the CEO hadn't
screwed up, that they'd be the first with 3D sound.

Maybe; but had they done so they'd still have been blocked
by compatibility. The fancy new hardware would have to
be able to emulate the old, making it more expensive. The
old software would not take advantage of it, making it no
more desirable (at first) than the cheaper old stuff. The
new software, if any, would not work on the old hardware
(so developers would be reluctant to write it at all).

To actually *deliver* on these innovations, you need
something to break this deadlock. Windows does that.

Even simple things like high-resolution, high-color screens are extremely
difficult without this technology.

Whose technology? Sure isn't from M$.

Sure is: GDI16 was the tehnology that made this possible
on the PC.

(On the Mac it was Color QuickDraw)

Remember it was their software, not the hardware that drove their market.
Hi-Res screens were available long before M$ got into the fray.

But without the software, there were very serious
obstacles to their adoption. Why pay for a high-res
screen if you can only drive it at 320x200 in a
compatibility mode?

I doubt we'd even have scroll wheels.

They had track balls back in the late 60s on expensive systems. The idea
isn't innovative by a long shot.

Scroll wheels are not trackballs, but you can argue whether
its a "real innovation" I s'pose; I don't find much value in that
dispute.

The thing is, without Windows, how do you implement
such a thing so that it actually works? Here emulating
the old hardware isn't the big problem, it's getting apps
to implement scroll wheel support. An OS like Windows
can do that globally.



.

Relevant Pages

  • Re: Drag it to the trash...
    ... There might be a piece of software utility out there to help in finding and administering these "roaming profiles" for windows. ... every registry key that your software installs. ... hardware actually makes the sys admins job a whole lot easier. ... I do not wish to exagerate MS's own innovation: ...
    (comp.sys.mac.advocacy)
  • Re: Error 7023
    ... This helps a PC to map devices using IRQ ... HAL (Hardware Abstraction Layer) driver appropriate for the type ... So some of your issues are most definitely related to McAfee. ... The kind of errors you report can be the result of Registry ...
    (microsoft.public.windowsxp.general)
  • Re: Error 7023
    ... This helps a PC to map devices using IRQ ... HAL (Hardware Abstraction Layer) driver appropriate for the type ... So some of your issues are most definitely related to McAfee. ... The kind of errors you report can be the result of Registry Cleaning. ...
    (microsoft.public.windowsxp.general)
  • Re: Atheists: Americas most distrusted minority
    ... Sun would have controlled hardware and software too. ... resolution on licensing and packaging issues for Java on Linux. ... You don't like Windows. ... Unfortunately, it prevents innovation from going anywhere, by making it ...
    (rec.arts.sf.tv.babylon5.moderated)
  • Re: Error 7023
    ... HAL (Hardware Abstraction Layer) driver appropriate for the type ... So some of your issues are most definitely related to McAfee. ... The kind of errors you report can be the result of Registry Cleaning. ... Component: System Event Log ...
    (microsoft.public.windowsxp.general)