To view parent comment, click here.
To read all comments associated with this story, please click here.
Trying to fix the post:
C. Only Windows cannot recover from a minor configuration corruption that in other OS could have been fixed by editing a test configuration file (or better yet, taking a working copy from another Linux machine.)
Now this one is just silly. You even provided a counter-example yourself:
G. Use the XP’s system restore to revert to semi-working copy of XP.
no need to edit some clusterfuck text file.
And yet it didn't work.
While I could get the machine to stop BSODing on me, after the restore Windows update (or actually the BITS service) stopped working; Windows A/V and F/W support stopped working; etc, etc.
If anything, System restore failed miserably.
Only in Windows, I have no way to back-port my work (or other people work) in-order to prevent needless upgrades. (Like the upgrade to 2K3)
I don't know what your problem with NT service security is, but 99% of the time it is a case of PEBKAC (Problem Exists Between Keyboard And Chair). You are probably tyring to fit NT's security model into the UNIX peanut gallery mold. Take some time to read about and understand the way NT's security API works before you jump into coding. I you follow this blog for any length of time (http://blogs.msdn.com/oldnewthing/) you would be amazed at the insane lengths that they go to to keep Windows backwards compatible.
"You are probably tyring to fit NT's security model into the UNIX peanut gallery mold"?
I've been developing software for Windows (and OS/2) long before I even touched any type of Unix/Linux machine.
Most of my code was ported from Windows to Linux/Unix and not the other way around.
Just to give you a small example: I'm building ACLs in a certain order; while it worked just fine under Windows NT and 2K it sent XP does the blue screen lane. Not an immediate crash mind you, a long, slow, kernel corruption that happened only on SMP machines.
Even if I'm an idiot, how come I managed to drop XP like a hot-potato from a simple user-land service?
I assume that you have the programming experience to back your unfounded claims? (Beyond using google?)
Oh.
Next time I see an "I call bullshit", will the best last time I spend time reading your posts.






Member since:
2005-07-06
A. Only in Windows applications install themselves and are allowed to modify OS files. (For instance, a Fedora RPM cannot modify a file that belongs to another RPM, not can it change the OS settings).
I call BULLSHIT:
http://www.rpm.org/max-rpm/s1-rpm-inside-scripts.html
First, stop with the "I call Bullshit" act. You /are/ not in the kindergarten. For Christ sake, grow up!
Second,
A. RPM scripts must follow certain guidelines on what they are allowed to do before being accepted to any RPM repository. Mostly, the SPEC file, and the scripts must be visible to the user.
B. All scripts can be disabled with rpm --noscripts. The installation will continue even if you decide not to enable scripts.
B. Only in Windows an application may fail to install itself, taking the OS with it.
I call BULLSHIT:
http://opensource.ca.com/projects/ingres/forum/10/609440555489
A. Grow up. (again).
B. Even you bothered to read your own link before posting it? Let me help you:
Check the solution to the problem:
Try adding -f and --noscripts to the parameters passed to rpm. This should allow removal of the packages from the rpm database. However since this suppresses execution of the uninstall scripts, you'll have to manually remove any files installed for Ingres to do a complete clean uninstall.
As for cleaning the files, just unpack the uninstall script and clean the file yourself. I doubt that I could have done the same with any Windows application, as I cannot view/modify/control the MSI/InstallShield installer.
http://www.nvnews.net/vbulletin/showthread.php?s=8ce4d66f2938149ee9...
Invalid link?
C. Only Windows cannot recover from a minor configuration corruption that in other OS could have been fixed by editing a test configuration file (or better yet, taking a working copy from another Linux machine.)
Now this one is just silly. You even provided a counter-example yourself:
G. Use the XP’s system restore to revert to semi-working copy of XP.
no need to edit some clusterfuck text file.
And yet it didn't work.
While I could get the machine to stop BSODing on me, after the restore Windows update (or actually the BITS service) stopped working; Windows A/V and F/W support stopped working; etc, etc.
If anything, System restore failed miserably.
Only in Windows, I have no way to back-port my work (or other people work) in-order to prevent needless upgrades. (Like the upgrade to 2K3)
I don't know what your problem with NT service security is, but 99% of the time it is a case of PEBKAC (Problem Exists Between Keyboard And Chair). You are probably tyring to fit NT's security model into the UNIX peanut gallery mold. Take some time to read about and understand the way NT's security API works before you jump into coding. I you follow this blog for any length of time (http://blogs.msdn.com/oldnewthing/) you would be amazed at the insane lengths that they go to to keep Windows backwards compatible.
"You are probably tyring to fit NT's security model into the UNIX peanut gallery mold"?
I've been developing software for Windows (and OS/2) long before I even touched any type of Unix/Linux.
Most of my code was ported from Windows to Linux/Unix and not the other way around.
Just to give you a small example: I'm building ACLs in a certain order; while it worked just fine under Windows NT and 2K it sent XP does the blue screen lane. Not an immediate crash mind you, a long, slow, kernel corruption that happened only on SMP machines.
Even if I'm an idiot, how come I managed to drop XP like a hot-potato from a simple user-land service?
I assume that you have the programming experience to back your unfounded claims? (Beyond using google?)
Oh.
Next time I see an "I call bullshit", will the best last time I spend time reading your posts.