On Wed, 14 Feb 2007 17:43:50 GMT, "Mr. I.M. Puss" <warpkat@yomama.net>
>Saucy Lemon wrote:
>> And Linux, otherwise known as a quagmire of widely scattered and
>> terribly inconsistent config files, is decidely neither user nor
>> hardware friendly.
All of the PC stuff (and I think this applies to Mac to some extent
too) is deeply-rooted in past decisions. It's like looking at the old
Mississippi and wondering why it takes a particular meandering turn
when it would be more efficient to go straight, and the answer goes
back to the first trickle of rain as the earth cooled.
Linux, and UNIX before it, feels like a system written by coders for
coders (much as could be said for the C language). There are all
these disparate tools with ad-hoc names and parameter sets that will
drive you mad if you come into these things "cold" in 2007.
The rawest side of the DOS era was similar, mind. Fire up a few
DOS-era archivers and compare their syntax for consistency :-)
That's why, looking back, Linux may feel like a confusing grab-bag of
loose bits. The hardware story's different; that is more a matter of
whether the Linux development resources can keep up with hardware
evolution; the answer seems to be "barely". I don't see that as a
"fault" of Linux in that the same resources could do better; it's just
life as a minority platform. At least you don't have "Apple Tax".
>I seem to recall my laptop crashing (Windows XP) one fine day while I
>was working on a document - because the registry got corrupt.
Registry hives don't just "get corrupt" for no reason, even as far
back as Win95. Like the swap file, the hives have always been quite
well-defended against anything that tries to open them as files.
Hardware issues run below that level of abstraction, and thus
invalidate it. It's meaningless to speak of blocked access to files
when the process of addressing raw sectors as parts of files is
deranged. Your mileage sounds more like a hardware error that crashed
the system and took out the registry, probably at the same time.
>Couldn't recover except to reinstall the system
It might have been possible to recover by using a fallback registry
copy, either via Windows' own backup systems, or your own...
Win95xx: One copy (.DA0) made at boot, so add your own
Win98/SE/ME: last 5 copies as RB*.CAB files
XP: copies within Restore Point snapshot data, dependent on SR
Vista: Dunno yet... ask me next month :-)
>even from a System Restore
Well, SR is not what I'd have tried first. I'd have:
- verified hardware (MemTest86, HD Tune from Bart CDR boot)
- verified or repaired file system (NTFS tools are weak here, alas)
- formally excluded malware, also via Bart CDR boot
- extracted spare hives from SR points, again via Bart
- swap these into place and test via RunScanner for crashes
- when working, try Safe Cmd boot, etc.
See...
http://cquirke.blogspot.com/2006/07/...-safeboot.html
...on a similar sort of quest.
>The config files in Linux are separate for one reason: The system
>itself won't crash unless you do something stupid to the kernel - it's
>separate - and it doesn't need to be bothered by the likes of Symantec
>or McAfee. Come to think of it, Linux doesn't need anti-virus
....yet...
>but that's yet another thread...
Yup. Let's keep it that way, for now.
>X is separate. KDE is separate. Gnome is separate. Other utilities
>like SSH are separate. If any of those crash, it's simply a matter of
>fixing the problem for the component, which often does not take forever
>nor would it require a 'reinstallation' of the OS.
That's the design intent, yes - but bad design (and I have a hunch you
will wave the same example as I would) can screw that up.
Windows once did separate the GUI from the kernel; it was called
Windows 3.yuk + DOS :-)
The reason we don't fondly remember that as a success story, is
because the cut-line between the two was drawn in the wrong place.
In *NIX, the kernel has all the memory and process management needed
to handle modern realities, whereas X is just the GUI shell driver.
In DOS/Win3.yuk, the logic needed to properly manage modern apps as
multitasking processes and protected memory allocations was built into
Windows, making the link between this and the kernel far kludgier.
>IE - it's so tightly integrated into the OS that even a simple toolbar
>takes it down and botches the rest of the system (read: ad popups).
Generally, I haven't seen popups do that. The problem with popups is
that the web site has been given the power to automate the OS, and
that IMO is a very bad call, made worse by the ability to pop up
dialog boxes that are not obviously from the Internet in appearance,
so that fake "system" dialogs can be launched from web sites.
But I agree; I dislike the design that ytakes an unbounded (i.e.
extensible) rich edge-facing exploit surface, and welds it deep down
in the kernel. I'd far rather have Firefox out there, at arms-length
from the core, so it can be amputated or replaced as needed.
>You Windows guys seem to think having all of your eggs in one basket is
>the coolest thing since sliced bread - until the basket drops. Then
>you're crying and whining like babies about losing documents and other
>important files as a result.
Actually no; some of us draw pretty much the same conclusions as you
do, and push for the same sort of changes. The "whiners", as you call
them, are a different type of user that you have yet to see on Linux;
folks with no interest in computers who just want to "do stuff".
>Compare that to the convenience of booting up with a Linux LiveCD (which
>I've used to recover files from Windows systems) because Microsoft
>doesn't offer it - and building one based on Windows is against the
>licensing terms, if I'm not mistaken.
Now there's another issue where many of us feel the same way as you
do, and are trying to kick butt to get things changed.
Until the Vista era, you were right: MS were asleep at the wheel,
denying users the tools to formally manage their own PCs.
It didn't matter in Win9x, because there was always DOS mode to fall
back on as a mOS. Combined with Odi's LFN Tools, you could do most
things that needed to be done from there.
WinME made artificially more difficult, so I just kicked it's ass back
into shape via the third of these DOS mode retrofit strategies...
http://cquirke.mvps.org/9x/me-dos.htm
....while most folks just relied on boot diskettes as their only way
back into systems that had to be formally maintained.
XP could be treated in much the same way, as long as you avoided NTFS;
install a Win98SE DOS mode first, then install XP, and access the DOS
mode via the NTLDR-mediated Boot.ini boot menu.
But a better approach was Bart PE, which gave us for free what MS
refused to give us as paying customers. That's what I currently use.
Bart PE overcomes NTFS, > 137G and registry access barriers, as a
DOS-based solution could not.
Vista is both good news and bad news. The bad news is that there's a
new and ?incompatible NTFS that Bart may trip over, and that the
registry is no longer compatible with RunScanner. The good news is
that MS's licensing sphincter has loosened up on WinPE.
So now everyone can get WinPE 2.0 in various ways.
A stripped-down version is present in every standard Vista DVD, which
now goes beyond XP's Recovery Console non-OS to launch a command
prompt from which other apps can be launched (i.e. now it IS an OS)
You can get the full WinPE 2.0 as part of WAIK, which for technical
reasons has to be downloaded from within BDD 2007. And OEMs still
have access to WinPE the old way, via the OPK.
Installation and setup:
- Bart PE: small free download, one GUI dialog to build CDR
- WinPE: 800M+ WAIK download, loose CLI tools to build CDR
UI when booted:
- BartPE: nu2menu (GUI menu) as native shell, others 3rd-party
- WinPE: cmd.exe CLI prompt as shell, can run others as apps
Plugins for other apps:
- Bart PE: .INF-based with XML UI menu integration
- WinPE: tricky...I haven't figured it yet
Base OSs:
- Bart PE: XP SP2, Server 2003, not Vista
- WinPE: XP, Server 2003, Vista32, Vista64
Patches and network safety:
- Bart PE: baseline SP level only, no firewall
- WinPE: can include up to date patches, fireall present
Bootability:
- Bart PE: CDR or DVDR only, tho otrhers claim better
- WinPE: CDR. DVDR, USB stick
Eject boot disk:
- Bart PE: no, tho some claim to have cracked this limitation
- WinPE: yes, as WinPE runs from RAM disk
Hot-swap USB:
- Bart PE: discovered at boot only; can swap SD cards in reader
- WinPE: yes, can hot-swap flash drives and SD cards
If you look at the above, a strategy suggests itself:
- WinPE as bootable mOS for Vista/XP
- Bart PE as bootable mOS for XP
- Bart also as a "second disk" toolset from WinPE boot
That's the way I'll be going. The last hurdle is the ability to shell
inactive HD installation's registry hives, as the RunScanner plugin
does for Bart PE; without this, Vista can't be as well maintained.
One can also use various Linux "Live CD" as a mOS for XP and perhaps
Vista, but this hasn't been useful in my experience, because:
- I don't have Linux skills
- the Linux CDRs I tried were flaky and prone to locking up
- poor, wobbly, or absent writeable NTFS support
- no ability to shell the inactive registry hives
The ones I tried were a Knoppix-based BitDefender, which never once
completed a scan of all files without crashing or locking up. As I
currently use 8 av scanners and 3 anti-spyware scanners more
effectively from Bart, I haven't been back to see if things improved.
>Given the choice between using Windows and Linux, I'll choose Linux any
>day unless I'm forced to use Windows. The only reason I use Windows on
>my laptop is because Broadcom won't make the WiFi spec available for
>their chipsets - let alone a binary-only driver
Generally, one uses what one knows best how to use. Circumstances
drove me to use Linux before I found Bart, but I bounced off it.
I think there are few folks who learn more than one platform deeply
enough to compare them fairly; I'm sure 99% of what I dislike about
Linux is simply because I don't know or understand Linux well enough
to use it effectively. The impression I come away with, is that
current platforms are more alike (shaped by the same necessities out
of the same resources) than different, once you get past UI how-to.
>So tell me - why is it you think Microsoft decided to make the registry
>so vulnerable to corruption?
I don't think they have.
At the level of abstraction where it is meaningful to speak of "the
registry files", it's really hard to corrupt a registry, as opposed to
integrating settings within it that will stop Windows from working.
If you invalidate the level of abstraction at which it is meaningful
to speak of "files", let alone "registry files", then all bets are
off; nothing MS can do at the OS level can address that.
>--------------- ---- --- -- - - - -
Saws are too hard to use.
Be easier to use!
>--------------- ---- --- -- - - - -
Linear Mode
