Historically, everyone was writing settings to ini files located in \windows\system and this is where people were falling over each other. All Microsoft (And yourself by extension with your arguement) are specifying there is the *location* of application specific files, not what they contain, how they work and how they should be changed and modified.
Agree, but Microsoft could have thought a bit ahead and helped out developers by providing some framework, but then again, aren't devs supposed to know what they're doing? You can invent any kinds of settings format on Linux and store it in/etc/xyz/settings.cfg. While a lot of the settings are of the form X=Y, quite a few of the config files contain macros and other types of textual data.
From my perspective as an admin who has to deal with thousands of users, I think the idea of trying to have to understand the (potentially) 1000s of different methods that the different software vendors would use to store their configuration data to change one flag to change a checkbox for a group of users would be a complete waste of my time. Now potentially, a developer might come up with an easy method for me to interpret all the different formats that other developers use to store their data for a single true / false flag, but I can say that I am glad I am not in that position.
I agree that pushing out registry settings through via GP on a domain vs. logon scripts (or whatever the options are) can't really be compared w.r.t convenience. IMO MS should have separated the system state/settings from the user & app settings in some meaningful way to make the OS more failure-resistant.
Applications run as a user, an application that's poorly (or otherwise) written that runs as that user has the ability to modify (corrupt) any other program that the user is permissioned to access, registry or not it doesn't make any difference.
True, but the app Foo would be far more likely to corrupt %APPDATA%\Publisher Foo\App Foo\settings.xyz than %APPDATA%\Publisher Bar\App Bar\settings.abc as opposed to poorly handling error conditions while using the registry API and corrupting the registry or leaving some registry handle open, causing a leak on shutdown and other badness.
In fact, I'm facing this problem right now. Some retarded app doesn't release a registry handle when its done using it and my registry hive always leaks that handle on shutdown. Unfortunately the process recorded as having allocated the handle is winlogon.exe so the actual culprit is probably a component loaded by winlogon making it all the more hard to track down. Bah..
This doesn't distinguish between bloat and essential settings. Reproduced my original statement again, hope you can at least read bold. Maybe you were concentrating on colons and Ps, whatever they mean.
Yeah, I can be a pedantic asshole too. You neither defined nor differentiated between "bloat" and essential settings. So I took the definition that was the most convenient to me. Or maybe you're a non-technical user and cant define them.
How else do you define "deliberately user-unfriendly"? That is exactly what I have said.
Its not user-unfriendly because *YOU* are not the intended user. The intended USER of the registry was the OS itself. Can't believe I had to spell everything out for you. Anyway you seem to ahve no real coherent point and just want to bitch about the registry, so this is my last reply. Have a good day.
Actually from Wikipedia "Windows registry's primary purpose was to store configuration information for COM-based components". I've only been doing admin since Win NT 3.51, so I only know about it since then, I didn't realise it was in Win 3.1 as well.
OK, if you want to be pedantic, then yeah, 3.1 also shipped with a registry, with a different purpose than W95. (Only the HKEY_CLASSES_ROOT part.) But obviously, that isn't the registry most people refer to.
Ah, but I can be a pedant too.
"The Microsoft Computer Dictionary defines the registry as: A central hierarchical database used in Microsoft Windows 98, Windows CE, Windows NT, and Windows 2000 used to store information that is necessary to configure the system for one or more users, applications and hardware devices."
The whole purpose of HKCU and HKLM in particular \Software was PURPOSEFULLY to have a central location for DIFFERENT software vendors to store settings in a single location as opposed to different vendors trying to use the same ini file names and treading on each other's toes, as well as problems with size limitations etc etc.
Thats the worst rationale ever. The opposite of the registry isn't overwriting INI files or whatever else you're thinking of. It is to call SHGetFolderPath with CSIDL_APPDATA and follow Microsoft's own guide lines.
Citation required. I don't understand how you consider it a cluster fuck. Just because you don't understand it doesn't make it a cluster fuck.
The primary problem I have with the registry is that it can't be locked during modification, and you couldn't set any access restrictions on any of the keys preventing other apps from messing (read corrupting) with it (this is on W95). Then ofcource there is the un-enforced type system. You can write any garbage and the type isn't enforced. E.g. you can write non-null terminated strings using the REG_SZ type, then there is the size bloat of the registry causing slower bootups, etc. There are several problems with the registry. If *only* the OS code was going to use the registry, the would have fixed all the bugs by now as there would be no other dependencies. Ofcource, now, its almost impossible to get rid of it or fix the problems.
With the hundred of thousands of ISVs out there, you suggest to me a better way of managing on a per user and per machine basis of managing configuration settings.
2. Migration? I have yet been unable to do so. Say, when one PC becomes bloated, slow and generally hell, I want to re-install onto another PC/partition. How would I migrate the essential settings but leave behind the bloat?
I found it in a few seconds by going to support.microsoft.com and searching for "migrate windows vista settings" which brought up http://support.microsoft.com/kb/928634 as the first hit.
I guess that was too hard:P
I also feel that this "obfuscation" of complicating the registry is deliberate on the part of Microsoft. Else, what business does a genuine system registry value have, to carry a value like : "7c5f219b67516f24" ? This suggests that user-unfriendliness was the very goal of Microsoft in designing the system.
If you bothered to read what I wrote before hitting reply, you'd know that the registry was an designed to be internal storage for OS settings and not meant to be user editable. At-least that was case initially 18 years ago.
The registry has a (weakish) type system, so quoting some random value as unfriendly is pointless. The registry also supports binary values. You might as well say "011001101110" is user-unfriendly.
Also your argument seems to be "I cant think of any reason why X is the case, therefore it must be because of reason Y". Most people wouldn't bother to reply to such a defective argument.
On the other hand for unixes: even a file like/etc/passwd has quite a user-friendly structure. A user can edit it with some confidence. Its man page is remarkably simpler than the help files describing registry values like "7c5f219b67516f24". Moreover, most such cryptic values are not even described in help files on the system and one typically needs a working internet connection to be able to debug it. Lack of an internet connection might very well be the reason why you are trying to debug it in the first place.
The registry was never mean't to be seen by end-users. Clearly/etc/* files were meant to be user editable as all of them are plain-text. The registry is not plain-text. In fact its a binary blob. There are several trade-offs of w.r.t. binary files and plain-text files. One very basic one is to do with load times. plain-text files require processing before they can be used. Whereas you could just dump a block of memory holding a few C structures containing OS settings to a binary file and just read them back on bootup minimizing CPU time. I imagine 18 years ago CPU time came at a high premium.
Anyway, I personally prefer plain-text files because I'm a nerd. However I'd much rather want my mom double clicking on a.reg file to merge settings into the registry rather than loading/etc/foo.cfg in gedit and potentially screwing things.
Well, they should have kept application configuration information separate from critical OS settings. Having them share the same space was a mistake. Also, since the registry was required to be loaded into memory (atleast partially) on boot, having a bloated registry makes the bootup longer as file parsing becomes slower, etc. Basically MS shot themselves in the foot by not thinking ahead on 'what could possibly go wrong'.
I'm not sure where the redundancy idea comes from in your post. I've seen more than a few Windows systems fucked over by just one or two registry keys doing the wrong thing. The fact that the path to said registry keys is cryptic and over 100 characters long doesn't help.
Well the redundancy comes from the fact that the registry was backed up on every successful boot allowing you to restore it when things got fucked up. I don't see why its automatically "nonsense" because you had some problems that you fail to give specifics for.
Also, Changing 'one or two' keys can and will fuck up Windows. Thats the point. Because it hosts critical OS settings, If you delete specific keys, say for e.g. If you disable a driver that is required for boot, you can hose your system.
But that would be the equivalent of deleting/etc/fstab , mtab or corrupting/boot/grub/grub.cfg.
There's lots of special-purpose search engines and portals that compete very well with Goole/Bing/etcetera by focusing on a specific problem space... an application, a group, a genre...
I don't not agree. My only point was the barrier to entry is the high cost if you want to compete with Google in their core business.
And costing hundreds of millions to compete with Google isn't necessarily a sign of the kind of barrier to entry we're talking about. It would cost hundreds of millions to compete with Linux, but that doesn't mean that Linux has deliberate application lock-in the way Windows does
Well the barrier to entry in my mind is separate from the lock-in part. I agree that for determined users (at the cost of possibly lower quality results) the lock-in from google as a search engine is minimal.
Also Linux as a platform could have vendor lock-in from apps too. Or are you just considering open-source apps on Linux?
Either way if a project goes out of active development, you would have to fund the project yourself by hiring a few devs. While thats doable for a small-ish project.
Imagine for the sake of argument a large project like Linux/Firefox/Openoffice goes out of development. Could an average person really afford the developer cost to keep the project active? Ofcource as it stands thats most likely never to come up anyway, as users could pool in to subsidize the cost to the entire group, but anyway, thats a separate discussion.
Actually the registry was a rather benign concept. It was originally designed to host OS settings in a convenient central location (with redundancy ofcource) to enable easier migration from PC to PC, easier group policy management, etc
Apps ofcource were too lazy to come up with their own damn 'INI files'-equivalent and abused the registry to store their own mess. System "tweaker" and other "cleaner" programs started to fuck with internal windows settings that Microsoft had no plans to expose to the end user causing even more problems. Thus its became this giant cluster-fuck that it is now, primarily because of backwards compatibility and previous strategic mistakes on the part of MS.
They should have kept the registry API hidden and not allowed apps to write their shit all over the place (ofcource 95 was a shitty OS and didn't have ACL like features, therefore forcing MS to have XP run as Admin by default to allow access to the entire object manager namespace for all programs)
This backlog of poor decisions finally caught up with them and they had to 'take a hit' (PR wise) finally with vista and the draconian UAC forcing app vendors to write apps w/o assuming admin privileges. Better late than never I'd say...
Well, search algorithms are less about "algorithms" and more about human psychology. For many search terms the intent of the search is very ambiguous. Because Google has all those data-points that is a kind of virtual lock-in as nobody else can match them.
Looking at it from a business angle, many online businesses are locked-in to google as they own several large ad-networks and you would find it impossible to survive if you switch to other advertising vendors if google increases their prices, etc. To say that there is no lock-in from google is oversimplifying it IMO.
Also, the barrier to entry *is* great. It would costs hundreds of millions of dollars to setup data centers to give any kind of competition to Google.
Other OSs have a similar problem as Windows is such a huge market that many commercial app developers will restrict their products to only windows releases. And users choose (well.. in some cases atleast) the OS with the most apps, and on and on it goes.
Seems to be the same problem in search. Google has millions of data points of search terms co-related with the link that was clicked and all that data has trained their algorithm such that any competing algorithm would find it very hard to catch up.
Well, technically it starts when your computer does. Any browser can create a window as fast as IE if it is already running. The cost of doing it like IE does is a slower boot up time and wasted memory when you are not using it.
I assume you're referring to the fact that one particular DLL (mshtml.dll) was loaded by the Windows UI shell to render HTML help and other things. AFAIK, this isn't true for recent versions of Windows.
In any case, the fact that one DLL is in memory isn't going to change the startup speed by that much. There are many files that IE needs to load and other misc initialization stuff that IE needs to do before it starts up. (e.g. load addons, setup protected mode, phishing filters etc)
FWIW, on my box Chrome starts up quicker than IE8. So its:
"UNIX" the philosophy helped me there, not "UNIX" the opengroup specification.
OK, fair enough.
What I'm trying to put across is that command lines and config files suit some people, and where things go wrong (it's disingenuous to say they never do) I like the level of access I get to the internals on UNIXy systems.
Its true that Windows is nowhere near as customizable (and therefore, more 'debuggable') as several other OSs including Linux.
I would support anyone using Linux if Windows didn't work out for them (no matter whose "fault" it was). I've been using Linux on and off since Slackware 0.9x but have concluded that its not for me. I use Windows like many people here use Linux. I don't run any CPU & I/O hogging anti-virus and other crap and I only use software obtained from white-listed sources (eq. linux repositories). So far its worked out OK for me..
1. Plug monitor into 2nd DVI connector on my GeForce 9800 GX2 card. 2. Done, start working. (lcd monitor is automatically set at native resolution).
You could have a monitor with broken EDID, issue with monitor drivers, display drivers or ofcource you could have encountered a Windows bug. I haven't seen any evidence that something as basic as what you're describing is broken for all the millions of people using windows (as it would be, if it was a flaw in the OS itself).
Feel free to to inform me otherwise.
Apart from Microsoft's own code, a ton of third party code runs on most windows desktops, its quite a leap to extrapolate from your experience to suggest that there is any flaw in the windows multi-monitor support.
Also I fail to see how "UNIX" helped you here? AFAIK the UNIX specification doesn't address multi-monitor issues. You could make an OS that could earn the UNIX branding and have terrible multi-mon support that you couldn't fix without actually modifying code (assuming you had access to the code).
if you buy a bunch of peripherals that require you to put the thing on a table to use, why didn't you just buy a netbook?
Apple themselves are trying to define the market as a device for web/movies/email with a little bit of productivity use thrown in. In that scenario you'd want to make sure that customers can connect k/b / mice easily (well unless you're apple:P)
Also the HDMI out seems pretty logical for a device positioned for presentation use. My general point was these ports make travelling/carrying the device *easier* in many situations.
And besides, in the specific case of the iPad it connects to Bluetooth keyboards and mice, so the ports are just another thing to break or collect schmutz in.
I agree with open ports collecting gunk over time, but we'll have to wait and see if apple allows any generic k/b or mouse to be interfaced with the iPad. Apple's own bluetooth keyboard/mouse? Yes. El cheapo keyboard/mouse? Nobody knows.
Yes, I won't buy the iPad in its current form. Whats your problem with people expressing their opinion? Regardless of whether you do or don't like their products, do you *want* Apple to screw consumers?
Its a typical strategy which many consumer device manufactures use. "Invent" some proprietary way to connect accessories to their device and get a cut for every "apple approved" accessory sold.
Why in the hell do I need 3 fucking USB ports on an underpowered toy?
So that you can connect an external keyboard/mouse? You can step into any generic computer store and buy a cheapo disposable keyboard and work on the device as opposed to being forced to carry apple accessories.
"Hey Apple! Instead of allowing me to connect my existing keyboards, let me pay you extra money so I can only connect apple keyboards!"
What well-adjusted person would connect a fucking tablet to a TV?
To watch movies, photos, online TV (Oh right forgot to mention.. this thing supports flash;) )? You can step into any generic electronic store and get a HDMI cable for your TV.
"Hey Apple! Instead of allowing me to use my existing HDMI cables, let me pay you extra money so I can only use apple approved TV out connectors!"
What is the benefit of running 1080i video on this tiny ass screen?
"Oh no. This device supports high quality video, let me get that other device that doesn't"
A real genius you are. Got the consumer mindset all figured out...
Process Explorer uses public APIs to get all the data. As does Task Manager. Your "proof" isn't very convincing. Anyone can write process explorer. Here, watch.
int main( ) {
DWORD aProcesses[1024], cbNeeded, cProcesses;
unsigned int i;
if ( !EnumProcesses( aProcesses, sizeof(aProcesses), &cbNeeded ) )
return 1;
cProcesses = cbNeeded / sizeof(DWORD);
for ( i = 0; i
Thats pretty much all process exploirer does (ofcource with more robust code). And as far as automatically overwriting itself. This is 100% false. I have had to re-download the new version EVERY single time.
Thats like saying Linux just ripped of Minix/Unix. All your comment shows is that you have little to no clue of what.NET is. The primary way to do innovation is to take existing technologies and build upon it and improve it. Which is why software patents suck ass.
Why can't they just inter-operate and integrate with outside software?
They can. They however don't want to (or need to), because then they lose control over it.
You have no idea what you're talking about. The bug is in the Virtual 8086 mode monitor, not the DOS VM. This exists in most operating systems. Google for/sys/vm86.h
Maybe you already know this and are just wasting my time. Anyway this is the last reply. Goodbye.
You asked for a security problem that resulted from providing backwards compatibility.
Re-read what I was replying to. OP was claiming that Backward compatibility and a zillion features amounted to "disaster". I was challenging that specific claim. There is not a shred of evidence that suggests the bug resulted *because* MS was trying to preserve backwards compatibility.
You have to take into account that operating system code once written & proved to be working is almost never touched unless it serves a specific purpose (fixing bugs, features, etc) and as a result a bug thats introduced in version 1.0 will carry forward to the next version and the next unless there is a need to change that. As it happens, there was no development done on that specific component and thus a bug in the version 1.0 got carried forwarded to Version 6.0. This is *not* because of backwards compatibility. Its because there was no need to modify existing working (well atleast the bug was unknown) code.
Anyway, most of the backwards compat stuff is encapsulated in a shim/wrapper and is only executed when running specific buggy programs (that are in the app. compat. database) that rely on undocumented or buggy behavior of previous operating systems. This does not affect other programs.
Slashdot Mirror
Nevermind that all the software on XP is broken when you're not root.
Thats a curious way to argue against security.
"Hey I can't run all this badly written software on Windows unless I run as root, therefore Windows is insecure !"
Unfortunately, that makes the web unusable for many people. Most people commenting here aren't the kind who get infected by malware.
Historically, everyone was writing settings to ini files located in \windows\system and this is where people were falling over each other. All Microsoft (And yourself by extension with your arguement) are specifying there is the *location* of application specific files, not what they contain, how they work and how they should be changed and modified.
Agree, but Microsoft could have thought a bit ahead and helped out developers by providing some framework, but then again, aren't devs supposed to know what they're doing? You can invent any kinds of settings format on Linux and store it in /etc/xyz/settings.cfg. While a lot of the settings are of the form X=Y, quite a few of the config files contain macros and other types of textual data.
From my perspective as an admin who has to deal with thousands of users, I think the idea of trying to have to understand the (potentially) 1000s of different methods that the different software vendors would use to store their configuration data to change one flag to change a checkbox for a group of users would be a complete waste of my time. Now potentially, a developer might come up with an easy method for me to interpret all the different formats that other developers use to store their data for a single true / false flag, but I can say that I am glad I am not in that position.
I agree that pushing out registry settings through via GP on a domain vs. logon scripts (or whatever the options are) can't really be compared w.r.t convenience. IMO MS should have separated the system state/settings from the user & app settings in some meaningful way to make the OS more failure-resistant.
Applications run as a user, an application that's poorly (or otherwise) written that runs as that user has the ability to modify (corrupt) any other program that the user is permissioned to access, registry or not it doesn't make any difference.
True, but the app Foo would be far more likely to corrupt %APPDATA%\Publisher Foo\App Foo\settings.xyz than %APPDATA%\Publisher Bar\App Bar\settings.abc as opposed to poorly handling error conditions while using the registry API and corrupting the registry or leaving some registry handle open, causing a leak on shutdown and other badness.
In fact, I'm facing this problem right now. Some retarded app doesn't release a registry handle when its done using it and my registry hive always leaks that handle on shutdown. Unfortunately the process recorded as having allocated the handle is winlogon.exe so the actual culprit is probably a component loaded by winlogon making it all the more hard to track down. Bah..
This doesn't distinguish between bloat and essential settings. Reproduced my original statement again, hope you can at least read bold. Maybe you were concentrating on colons and Ps, whatever they mean.
Yeah, I can be a pedantic asshole too. You neither defined nor differentiated between "bloat" and essential settings. So I took the definition that was the most convenient to me. Or maybe you're a non-technical user and cant define them.
How else do you define "deliberately user-unfriendly"? That is exactly what I have said.
Its not user-unfriendly because *YOU* are not the intended user. The intended USER of the registry was the OS itself. Can't believe I had to spell everything out for you. Anyway you seem to ahve no real coherent point and just want to bitch about the registry, so this is my last reply. Have a good day.
Actually from Wikipedia "Windows registry's primary purpose was to store configuration information for COM-based components". I've only been doing admin since Win NT 3.51, so I only know about it since then, I didn't realise it was in Win 3.1 as well.
OK, if you want to be pedantic, then yeah, 3.1 also shipped with a registry, with a different purpose than W95. (Only the HKEY_CLASSES_ROOT part.) But obviously, that isn't the registry most people refer to.
Ah, but I can be a pedant too.
"The Microsoft Computer Dictionary defines the registry as: A central hierarchical database used in Microsoft Windows 98, Windows CE, Windows NT, and Windows 2000 used to store information that is necessary to configure the system for one or more users, applications and hardware devices."
http://support.microsoft.com/kb/256986
The whole purpose of HKCU and HKLM in particular \Software was PURPOSEFULLY to have a central location for DIFFERENT software vendors to store settings in a single location as opposed to different vendors trying to use the same ini file names and treading on each other's toes, as well as problems with size limitations etc etc.
Thats the worst rationale ever. The opposite of the registry isn't overwriting INI files or whatever else you're thinking of. It is to call SHGetFolderPath with CSIDL_APPDATA and follow Microsoft's own guide lines.
http://msdn.microsoft.com/en-us/library/ms995853.aspx#w2kcli_req42
Citation required. I don't understand how you consider it a cluster fuck. Just because you don't understand it doesn't make it a cluster fuck.
The primary problem I have with the registry is that it can't be locked during modification, and you couldn't set any access restrictions on any of the keys preventing other apps from messing (read corrupting) with it (this is on W95). Then ofcource there is the un-enforced type system. You can write any garbage and the type isn't enforced. E.g. you can write non-null terminated strings using the REG_SZ type, then there is the size bloat of the registry causing slower bootups, etc. There are several problems with the registry. If *only* the OS code was going to use the registry, the would have fixed all the bugs by now as there would be no other dependencies. Ofcource, now, its almost impossible to get rid of it or fix the problems.
With the hundred of thousands of ISVs out there, you suggest to me a better way of managing on a per user and per machine basis of managing configuration settings.
Already linked .. :
http://msdn.microsoft.com/en-us/library/ms995853.aspx#w2kcli_req42
2. Migration? I have yet been unable to do so. Say, when one PC becomes bloated, slow and generally hell, I want to re-install onto another PC/partition. How would I migrate the essential settings but leave behind the bloat?
I found it in a few seconds by going to support.microsoft.com and searching for "migrate windows vista settings" which brought up http://support.microsoft.com/kb/928634 as the first hit.
I guess that was too hard :P
I also feel that this "obfuscation" of complicating the registry is deliberate on the part of Microsoft. Else, what business does a genuine system registry value have, to carry a value like : "7c5f219b67516f24" ? This suggests that user-unfriendliness was the very goal of Microsoft in designing the system.
If you bothered to read what I wrote before hitting reply, you'd know that the registry was an designed to be internal storage for OS settings and not meant to be user editable. At-least that was case initially 18 years ago.
The registry has a (weakish) type system, so quoting some random value as unfriendly is pointless. The registry also supports binary values. You might as well say "011001101110" is user-unfriendly.
Also your argument seems to be "I cant think of any reason why X is the case, therefore it must be because of reason Y". Most people wouldn't bother to reply to such a defective argument.
On the other hand for unixes: even a file like /etc/passwd has quite a user-friendly structure. A user can edit it with some confidence. Its man page is remarkably simpler than the help files describing registry values like "7c5f219b67516f24". Moreover, most such cryptic values are not even described in help files on the system and one typically needs a working internet connection to be able to debug it. Lack of an internet connection might very well be the reason why you are trying to debug it in the first place.
The registry was never mean't to be seen by end-users. Clearly /etc/* files were meant to be user editable as all of them are plain-text. The registry is not plain-text. In fact its a binary blob. There are several trade-offs of w.r.t. binary files and plain-text files. One very basic one is to do with load times. plain-text files require processing before they can be used. Whereas you could just dump a block of memory holding a few C structures containing OS settings to a binary file and just read them back on bootup minimizing CPU time. I imagine 18 years ago CPU time came at a high premium.
Anyway, I personally prefer plain-text files because I'm a nerd. However I'd much rather want my mom double clicking on a .reg file to merge settings into the registry rather than loading /etc/foo.cfg in gedit and potentially screwing things.
Well, they should have kept application configuration information separate from critical OS settings. Having them share the same space was a mistake. Also, since the registry was required to be loaded into memory (atleast partially) on boot, having a bloated registry makes the bootup longer as file parsing becomes slower, etc. Basically MS shot themselves in the foot by not thinking ahead on 'what could possibly go wrong'.
I'm not sure where the redundancy idea comes from in your post. I've seen more than a few Windows systems fucked over by just one or two registry keys doing the wrong thing. The fact that the path to said registry keys is cryptic and over 100 characters long doesn't help.
Well the redundancy comes from the fact that the registry was backed up on every successful boot allowing you to restore it when things got fucked up. I don't see why its automatically "nonsense" because you had some problems that you fail to give specifics for.
http://en.wikipedia.org/wiki/Windows_Registry#Backups_and_recovery
Also, Changing 'one or two' keys can and will fuck up Windows. Thats the point. Because it hosts critical OS settings, If you delete specific keys, say for e.g. If you disable a driver that is required for boot, you can hose your system.
But that would be the equivalent of deleting /etc/fstab , mtab or corrupting /boot/grub/grub.cfg.
There's lots of special-purpose search engines and portals that compete very well with Goole/Bing/etcetera by focusing on a specific problem space... an application, a group, a genre...
I don't not agree. My only point was the barrier to entry is the high cost if you want to compete with Google in their core business.
And costing hundreds of millions to compete with Google isn't necessarily a sign of the kind of barrier to entry we're talking about. It would cost hundreds of millions to compete with Linux, but that doesn't mean that Linux has deliberate application lock-in the way Windows does
Well the barrier to entry in my mind is separate from the lock-in part. I agree that for determined users (at the cost of possibly lower quality results) the lock-in from google as a search engine is minimal.
Also Linux as a platform could have vendor lock-in from apps too. Or are you just considering open-source apps on Linux?
Either way if a project goes out of active development, you would have to fund the project yourself by hiring a few devs. While thats doable for a small-ish project.
Imagine for the sake of argument a large project like Linux/Firefox/Openoffice goes out of development. Could an average person really afford the developer cost to keep the project active? Ofcource as it stands thats most likely never to come up anyway, as users could pool in to subsidize the cost to the entire group, but anyway, thats a separate discussion.
Actually the registry was a rather benign concept. It was originally designed to host OS settings in a convenient central location (with redundancy ofcource) to enable easier migration from PC to PC, easier group policy management, etc
Apps ofcource were too lazy to come up with their own damn 'INI files'-equivalent and abused the registry to store their own mess. System "tweaker" and other "cleaner" programs started to fuck with internal windows settings that Microsoft had no plans to expose to the end user causing even more problems. Thus its became this giant cluster-fuck that it is now, primarily because of backwards compatibility and previous strategic mistakes on the part of MS.
They should have kept the registry API hidden and not allowed apps to write their shit all over the place (ofcource 95 was a shitty OS and didn't have ACL like features, therefore forcing MS to have XP run as Admin by default to allow access to the entire object manager namespace for all programs)
This backlog of poor decisions finally caught up with them and they had to 'take a hit' (PR wise) finally with vista and the draconian UAC forcing app vendors to write apps w/o assuming admin privileges. Better late than never I'd say...
Well, search algorithms are less about "algorithms" and more about human psychology. For many search terms the intent of the search is very ambiguous. Because Google has all those data-points that is a kind of virtual lock-in as nobody else can match them.
Looking at it from a business angle, many online businesses are locked-in to google as they own several large ad-networks and you would find it impossible to survive if you switch to other advertising vendors if google increases their prices, etc. To say that there is no lock-in from google is oversimplifying it IMO.
Also, the barrier to entry *is* great. It would costs hundreds of millions of dollars to setup data centers to give any kind of competition to Google.
Besides that being your opinion entirely, I don't see where I claim anything to the contrary for you to bring it up.
Other OSs have a similar problem as Windows is such a huge market that many commercial app developers will restrict their products to only windows releases. And users choose (well.. in some cases atleast) the OS with the most apps, and on and on it goes.
Seems to be the same problem in search. Google has millions of data points of search terms co-related with the link that was clicked and all that data has trained their algorithm such that any competing algorithm would find it very hard to catch up.
Well, technically it starts when your computer does. Any browser can create a window as fast as IE if it is already running. The cost of doing it like IE does is a slower boot up time and wasted memory when you are not using it.
I assume you're referring to the fact that one particular DLL (mshtml.dll) was loaded by the Windows UI shell to render HTML help and other things. AFAIK, this isn't true for recent versions of Windows.
In any case, the fact that one DLL is in memory isn't going to change the startup speed by that much. There are many files that IE needs to load and other misc initialization stuff that IE needs to do before it starts up. (e.g. load addons, setup protected mode, phishing filters etc)
FWIW, on my box Chrome starts up quicker than IE8. So its:
1. Chrome
2. IE8
3. Opera
4. FF
"UNIX" the philosophy helped me there, not "UNIX" the opengroup specification.
OK, fair enough.
What I'm trying to put across is that command lines and config files suit some people, and where things go wrong (it's disingenuous to say they never do) I like the level of access I get to the internals on UNIXy systems.
Its true that Windows is nowhere near as customizable (and therefore, more 'debuggable') as several other OSs including Linux.
I would support anyone using Linux if Windows didn't work out for them (no matter whose "fault" it was). I've been using Linux on and off since Slackware 0.9x but have concluded that its not for me. I use Windows like many people here use Linux. I don't run any CPU & I/O hogging anti-virus and other crap and I only use software obtained from white-listed sources (eq. linux repositories). So far its worked out OK for me..
This is my experience on Windows (vista and 7).
1. Plug monitor into 2nd DVI connector on my GeForce 9800 GX2 card.
2. Done, start working. (lcd monitor is automatically set at native resolution).
You could have a monitor with broken EDID, issue with monitor drivers, display drivers or ofcource you could have encountered a Windows bug. I haven't seen any evidence that something as basic as what you're describing is broken for all the millions of people using windows (as it would be, if it was a flaw in the OS itself).
Feel free to to inform me otherwise.
Apart from Microsoft's own code, a ton of third party code runs on most windows desktops, its quite a leap to extrapolate from your experience to suggest that there is any flaw in the windows multi-monitor support.
Also I fail to see how "UNIX" helped you here? AFAIK the UNIX specification doesn't address multi-monitor issues. You could make an OS that could earn the UNIX branding and have terrible multi-mon support that you couldn't fix without actually modifying code (assuming you had access to the code).
if you buy a bunch of peripherals that require you to put the thing on a table to use, why didn't you just buy a netbook?
Apple themselves are trying to define the market as a device for web/movies/email with a little bit of productivity use thrown in. In that scenario you'd want to make sure that customers can connect k/b / mice easily (well unless you're apple :P)
Also the HDMI out seems pretty logical for a device positioned for presentation use. My general point was these ports make travelling/carrying the device *easier* in many situations.
And besides, in the specific case of the iPad it connects to Bluetooth keyboards and mice, so the ports are just another thing to break or collect schmutz in.
I agree with open ports collecting gunk over time, but we'll have to wait and see if apple allows any generic k/b or mouse to be interfaced with the iPad. Apple's own bluetooth keyboard/mouse? Yes. El cheapo keyboard/mouse? Nobody knows.
From http://www.apple.com/ipad/design/ :
"And because iPad has built-in Bluetooth wireless technology, it works with the Apple Wireless Keyboard, too."
To the best of my knowledge Apple isn't forcing anyone to Buy their products.
Nice strawman. Nobody claimed or asserted that they were.
Your opinion is flawed.
Heh. http://en.wikipedia.org/wiki/Opinion
Might want to read up on what it means.
-
Seems you have no point and just want to rant. Anyway, not wasting my time anymore. Goodbye.
Yes, I won't buy the iPad in its current form. Whats your problem with people expressing their opinion? Regardless of whether you do or don't like their products, do you *want* Apple to screw consumers?
Its a typical strategy which many consumer device manufactures use. "Invent" some proprietary way to connect accessories to their device and get a cut for every "apple approved" accessory sold.
Why in the hell do I need 3 fucking USB ports on an underpowered toy?
So that you can connect an external keyboard/mouse? You can step into any generic computer store and buy a cheapo disposable keyboard and work on the device as opposed to being forced to carry apple accessories.
"Hey Apple! Instead of allowing me to connect my existing keyboards, let me pay you extra money so I can only connect apple keyboards!"
What well-adjusted person would connect a fucking tablet to a TV?
To watch movies, photos, online TV (Oh right forgot to mention.. this thing supports flash ;) )? You can step into any generic electronic store and get a HDMI cable for your TV.
"Hey Apple! Instead of allowing me to use my existing HDMI cables, let me pay you extra money so I can only use apple approved TV out connectors!"
What is the benefit of running 1080i video on this tiny ass screen?
"Oh no. This device supports high quality video, let me get that other device that doesn't"
A real genius you are. Got the consumer mindset all figured out...
bah.. ofcource. The damn tags screwed me over. http://pastebin.com/m622979a6
Does anyone else thing its sad that a technical site has bugs preventing people from pasting code in comments?
Process Explorer uses public APIs to get all the data. As does Task Manager. Your "proof" isn't very convincing. Anyone can write process explorer. Here, watch.
#include
#include
#include
void PrintMemoryInfo( DWORD processID )
{
HANDLE hProcess;
PROCESS_MEMORY_COUNTERS_EX pmc;
printf( "\nProcess ID: %u\n", processID );
hProcess = OpenProcess( PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, processID );
if (NULL == hProcess) return;
ZeroMemory(&pmc,sizeof(pmc));
if ( GetProcessMemoryInfo( hProcess, (PROCESS_MEMORY_COUNTERS*)&pmc, sizeof(pmc)) )
{
printf( "\tPageFaultCount: 0x%08X\n", pmc.PageFaultCount );
printf( "\tPeakWorkingSetSize: 0x%08X\n", pmc.PeakWorkingSetSize );
printf( "\tWorkingSetSize: 0x%08X\n", pmc.WorkingSetSize );
printf( "\tQuotaPeakPagedPoolUsage: 0x%08X\n", pmc.QuotaPeakPagedPoolUsage );
printf( "\tQuotaPagedPoolUsage: 0x%08X\n", pmc.QuotaPagedPoolUsage );
printf( "\tQuotaPeakNonPagedPoolUsage: 0x%08X\n", pmc.QuotaPeakNonPagedPoolUsage );
printf( "\tQuotaNonPagedPoolUsage: 0x%08X\n", pmc.QuotaNonPagedPoolUsage );
printf( "\tPagefileUsage: 0x%08X\n", pmc.PagefileUsage );
printf( "\tPeakPagefileUsage: 0x%08X\n", pmc.PeakPagefileUsage );
printf( "\tPrivateUsage: 0x%08X\n", pmc.PrivateUsage );
}
CloseHandle( hProcess );
}
int main( )
{
DWORD aProcesses[1024], cbNeeded, cProcesses;
unsigned int i;
if ( !EnumProcesses( aProcesses, sizeof(aProcesses), &cbNeeded ) )
return 1;
cProcesses = cbNeeded / sizeof(DWORD);
for ( i = 0; i
Thats pretty much all process exploirer does (ofcource with more robust code). And as far as automatically overwriting itself. This is 100% false. I have had to re-download the new version EVERY single time.
even .NET is ripping off Java
Thats like saying Linux just ripped of Minix/Unix. All your comment shows is that you have little to no clue of what .NET is. The primary way to do innovation is to take existing technologies and build upon it and improve it. Which is why software patents suck ass.
Why can't they just inter-operate and integrate with outside software?
They can. They however don't want to (or need to), because then they lose control over it.
You have no idea what you're talking about. The bug is in the Virtual 8086 mode monitor, not the DOS VM. This exists in most operating systems. Google for /sys/vm86.h
Maybe you already know this and are just wasting my time. Anyway this is the last reply. Goodbye.
You asked for a security problem that resulted from providing backwards compatibility.
Re-read what I was replying to. OP was claiming that Backward compatibility and a zillion features amounted to "disaster". I was challenging that specific claim. There is not a shred of evidence that suggests the bug resulted *because* MS was trying to preserve backwards compatibility.
You have to take into account that operating system code once written & proved to be working is almost never touched unless it serves a specific purpose (fixing bugs, features, etc) and as a result a bug thats introduced in version 1.0 will carry forward to the next version and the next unless there is a need to change that. As it happens, there was no development done on that specific component and thus a bug in the version 1.0 got carried forwarded to Version 6.0. This is *not* because of backwards compatibility. Its because there was no need to modify existing working (well atleast the bug was unknown) code.
Anyway, most of the backwards compat stuff is encapsulated in a shim/wrapper and is only executed when running specific buggy programs (that are in the app. compat. database) that rely on undocumented or buggy behavior of previous operating systems. This does not affect other programs.
You should go into politics.
You should go back to school :P