Adobe installed an update...
-
@ASheridan said:
-Unix/Linux has supported unicode for a long, long time. Windows was way behind in this regard, which explains the limitation in Windows.
So because not 100% of the points apply to Linux, it's therefore a joke post?
BTW you're wrong on Linux supporting Unicode. The entire reason Unicode is such a mess in Windows is that Microsoft ware super-early-adopters and double-downed on UTF-16 (because it was the best character set that existing at the time) before UTF-8 was invented. The instant UTF-8 was introduced, Microsoft added support for it, but the large amount of legacy APIs and apps using UTF-16 have made things a pain in the ass.
@ASheridan said:
Yeah, because nobody ever locks a file that is being read with the intention of being written to
That changes his point how?
@ASheridan said:
Are you fucking kidding me? I've got tons of .ini files that are bigger than 32KB, the php.ini file is one for a start.
Then it's not really an .ini file. It's a "someone borrowed bits of the .ini file format and just called it an .ini file." Because Raymond is 100% right on this one.
@ASheridan said:
I won't even both with any of the other points, you get the idea.
I get an idea. That idea is, "ASheridan is a dumbass who is always wrong". Is that the idea I was supposed to get?
-
@ASheridan said:
I guess then we're back to the WTF of the 3rd party apps not using that, although I do find it strange that I've not seen one app use this, ever.
If those dumbshits haven't heard of Scheduled Tasks, which has been user-facing in Windows since NT4 (and possibly earlier), then it's way too much to expect them to know about an admittedly obscure API.
The problem is people change, "Apple's shitty programmers can't write software, what the fuck is their problem," into "Windows sucks". I don't get how that happens, but it does-- even in technical communities. It bugs me.
-
@ASheridan said:
The one I linked to is the old one because I wanted to show this existed for a long time. But you know that a 3rd party app uses the current installer system if you try to install/update a 3rd party app while "Windows Update" is already installing something. You will get an error message: "Setup cannot continue because another setup is already running".@bjolling said:
I guess then we're back to the WTF of the 3rd party apps not using that, although I do find it strange that I've not seen one app use this, ever.@ASheridan said:
(I'll bite on the update API when you find a link).
Refer to my previous post. I was editing it and adding links on the fly. duckduckgo even found a helpfile on the API http://www.masmforum.com/winhelp_files/SETUPAPI.HLPObviously this one is deprecated and replaced now, but it's the one I remember from when I added automatic update support to one of my applications. The only manual bit that an application needs to do is check some online repository to check if something has changed and then download the changes and queue them using the Setup API. The application can always decide that a certain change requires that a service needs stopping first so that the Setup API will not require a reboot.
-
@ASheridan said:
"INI files don't support Unicode. Even though there are Unicode functions of the private profile functions, they end up just writing ANSI text to the INI file. (There is a wacked out way you can create a Unicode INI file, but you have to step outside the API in order to do it.) This wasn't an issue in 16-bit Windows since 16-bit Windows didn't support Unicode either!" -Unix/Linux has supported unicode for a long, long time. Windows was way behind in this regard, which explains the limitation in Windows.
In 1994. So Windows has had Unicode support for a long time too.
@ASheridan said:
"Multiple writers to an INI file can result in data loss. Consider two threads that are trying to update an INI file. If they are running simultaneously, you can get this:" - Yeah, because nobody ever locks a file that is being read with the intention of being written to
Convention dictates that you only lock a file when you want to write to it. For INI files, it's bad practise to lock for read only. Raymond even covers this in the point following this one.
@ASheridan said:
"INI files are limited to 32KB in size." - Are you fucking kidding me? I've got tons of .ini files that are bigger than 32KB, the php.ini file is one for a start.
And they use their own INI parser as a result.
-
@blakeyrat said:
So because not 100% of the points apply to Linux, it's therefore a joke post?
No, because it opens with this fucking line you retard: "Welcome, Slashdot readers. Remember, this Web site is for entertainment purposes only."@blakeyrat said:
BTW you're wrong on Linux supporting Unicode.
I call bullshit again. Linux has had no problems with Unicode that I've ever come across in the real world, but Windows has them all over the place, such as presuming character encoding and changing it where it thinks best.@blakeyrat said:That changes his point how?
It makes it a non-point.@blakeyrat said:Then it's not really an .ini file. It's a "someone borrowed bits of the .ini file format and just called it an .ini file." Because Raymond is 100% right on this one.
WTF? How does that even make sense? To start with that was one of many files I could have given an example of, and it is an INI file. You can believe all you want in your magic world of ranting, ponies and fish paste, but in the normal world it's an INI file.
-
I haven't needed to restart my Windows machines after upgrading Nvidia drivers for quite a while
-
@blakeyrat said:
Both Flash and Acrobat Reader are available for Linux, but nobody uses the latter.In short: Windows doesn't need restarts; shitty software developers do. Fall to your knees and pray to your God each day that Apple and Adobe aren't writing bullshit for Linux.
-
@blakeyrat said:
@ASheridan said:
Hey retard, read the thread. We were talking about an API that lets 3rd party apps update through Windows, rather than on their own. For someone that whines so much about not being understood and nobody reading your replies, you do a pretty shitty job at reading anything yourselfI guess then we're back to the WTF of the 3rd party apps not using that, although I do find it strange that I've not seen one app use this, ever.
If those dumbshits haven't heard of Scheduled Tasks, which has been user-facing in Windows since NT4 (and possibly earlier), then it's way too much to expect them to know about an admittedly obscure API.
The problem is people change, "Apple's shitty programmers can't write software, what the fuck is their problem," into "Windows sucks". I don't get how that happens, but it does-- even in technical communities. It bugs me.
-
@blakeyrat said:
@boomzilla said:
Wow, is this willful ignorance, trolling, or are you really this stupid?
So you literally believe that the Chrome developers created a WTFy update checker and they just don't actually use it? They use their good seamless one instead?
It's not willful ignorance, it's me trying to figure out WHAT THE FUCK YOU'RE SAYING because I'm (generously) assuming you're not saying something that any moron could see was obviously incorrect in about 27 seconds of using Windows. When you say things so contrary to reality you should be prepared for the "WTF" response.
I think the problem is you don't know what the word "requires" means? Maybe? I'm sticking with aphasia.
Let's start from the beginning (make sure you read slowly and completely). Here's the requirement: "Automatically check for updates and install those updates for the user."
Now, if you're anyone that isn't Microsoft, how can you make this happen? The only way seems to be that you must write some software to call home, look for an update, then download and install the update. Some have the application do this more or less in the background (e.g., chrome, firefox). Others have a scheduled check that runs at certain points (e.g., java). Others don't bother with this at all, or get something wrong, and so users are very likely to end up with old, vulnerable software (e.g., like how Flash used to be...the current update system seems a bit better).
Through some sort of magic, Microsoft has managed to integrate non-Windows Operating System software into the Windows updates mechanism (e.g., Office). How awesome would it be if other software vendors could integrate with Windows update. Then we could have a standard way to keep stuff up to date.
I'll also review the situation in APT-based Linux distros (I think other package managers have similar things, but APT is what I'm familiar with). When I installed my operating system, it was set up with a set of repositories that pointed to the distro's official source for software. Of course, it's a lot more than just the basic OS stuff, and so it's not surprising that all of that other software gets updated just like the OS (similar to MS Office).
BUT! I like to use some software that doesn't come in the distro's repositories. One such program is Google's chrome. To install, I went to their web site and downloaded a Debian package (which is used by APT) and installed it by running it (a similar process to downloading and installing an MSI file). However, as part of the installation, Google's repository was added to the list of repositories that my system checks when it looks for updates. So, the automated check that happens once a day (or whatever I set it to) as well as a manual check (via command line or a GUI application) checks both the official distro repositories as well as Google's repository. And now, from my point of view, I have a single point of contact with respect to software updates.
Oh, one other difference, I suppose, goes back to your point about Windows telling you that you need to restart. On Windows, the chrome update happens in the background, whenever you close and restart your browser. You may never know that you're using and old and possibly vulnerable application. But my updater lets me know that there's an update available, so I'm aware of this. Which as you already pointed out, is a useful bit of knowledge.
So, obviously, Windows doesn't require that programs write their own updaters. But that just means that users cannot have any automatic way of checking and installing updates, if the various third parties do not continually reinvent the wheels in ever new and WTF-y ways.
-
@bjolling said:
The one I linked to is the old one because I wanted to show this existed for a long time. But you know that a 3rd party app uses the current installer system if you try to install/update a 3rd party app while "Windows Update" is already installing something. You will get an error message: "Setup cannot continue because another setup is already running".
Thats the update mechanism itself, but what about how that gets initiated? Does Windows check for app updates, or is that left to the app?
-
@bjolling said:
@bjolling said:
Google seems very unhelpful atm to help me find back the API I used back in the NT days. I suppose that the relevant documentation on MSDN has been taken down. I'll post a link if I come across it.
duckduckgo.com has no trouble finding something. It was called the Windows NT Setup API. Which was being replaced with the "New Windows Installer" as it's called in this article
Yes, MSI is a fine thing, but how does it check for updates when they are available?
-
@RaceProUK said:
Convention dictates that you only lock a file when you want to write to it. For INI files, it's bad practise to lock for read only. Raymond even covers this in the point following this one.
which is why I specifically said about reading a file with the intention to write to it. @RaceProUK said:And they use their own INI parser as a result.
Where is this 32KB limit coming from? Is there only one true INI parser and all others are false? The INI format doesn't impose any limit at all.
-
@ASheridan said:
No, because it opens with this fucking line you retard: "Welcome, Slashdot readers. Remember,
this Web site is
for entertainment purposes only."Yeah he does that when one of his articles is linked to from Slashdot because of retards like you who come and spam-up his comments with stupid shit. What he's means is he's not an official Microsoft spokesman. That doesn't mean the post is inaccurate or wrong; you can independently verify every point he makes. Well, you would be able to if you had normal cognitive function.
@ASheridan said:
I call bullshit again. Linux has had no problems with Unicode that I've ever come across in the real world, but Windows has them all over the place, such as presuming character encoding and changing it where it thinks best.
I didn't say Windows had great Unicode support; I said it had Unicode support before Linux did. In fact, if you actually read what I typed, which I'm now repeating in the probable-futile hope you read it this time around, I specifically said the REASON Unicode support in Windows is a bit wonky is because they were super-early adopters of it. Linux said on its ass and waited for Microsoft to iron out the kinks then swooped in and did a better (?) implementation.
Remember the context... .ini files were deprecated in 1994. In 1994, Linux was 3 years old. It could barely fucking draw a window. (If it could at all.) I think your memory is a bit rosy-colored there buddy.
@ASheridan said:
It makes it a non-point.
No it doesn't. A programmer CAN write an application in such a way that it's a non-point. But it CAN write an application in such a way that it is. The word he used was "can". Do you understand what "can" means? Do you need some remedial Sesame Street?
@ASheridan said:
WTF? How does that even make sense?
The .ini format is a documented and specified format created by Microsoft in long ages past. If you don't follow the specs, it's not an .ini file. It's just a text file that happens to look an awful lot like an .ini file.
BTW, if you read Raymond points, one of his points specifically is about this: since INI looks "easy", nobody read the fucking specification and everybody implemented the parser slightly, slightly different from everybody else, to the point where nobody's .ini file parser could read anybody else's INI file. This was a big reason everybody sane moved away from that file format in 1994, leaving only the kind of dumbfucks who write PHP to wallow around in it.
@ASheridan said:
To start with that was one of many files I could have given an example of, and it is an INI file
No it's not. It resembles an INI file, and it has a .ini file extension, but unless it follows the specified file format, it's not an .ini file.
But that's good! Because the alternative is that it's a BROKEN .ini file that can't possibly be parsed by a normal INI file parser. And that looks even worse for the PHP developers. So you should rejoice in their incompetence!
-
@RaceProUK said:
I found a reference to the limit, which appears to be some weird-ass Windows-specific limit. So tell me again, why can't an INI file be greater than 32KB?@ASheridan said:
"INI files are limited to 32KB in size." - Are you fucking kidding me? I've got tons of .ini files that are bigger than 32KB, the php.ini file is one for a start.
And they use their own INI parser as a result.
-
@blakeyrat said:
Windows Automatic Updates doesn't use WSUS. To state the obvious you seemed to have somehow missed.
Maybe I'm mixing up WSUS and Windows Automatic Updates. I would correct myself, but seeing you flip out, even when I was agreeing with you, is much more entertaining. Please, carry on.
@blakeyrat said:
If you're not reviewing the updates, why the holy shit in demon fucking hell are you using WSUS?
I'm not using WSUS. I'm using Windows Automatic Updates, which is also known as WSUS. I don't know why you would use WSUS outside a corporate, managed network. Just use WSUS like I do. I'm pretty sure it comes on by default.
As an aside: Skype was installed through Windows Update (aka: [url="http://en.wikipedia.org/wiki/Windows_Server_Update_Services"]WSUS[/url]), not Windows Server Update Server (aka: [url="http://en.wikipedia.org/wiki/Windows_Update"]WU[/url]) to my home computer.
-
@blakeyrat said:
If those dumbshits haven't heard of Scheduled Tasks, which has been user-facing in Windows since NT4 (and possibly earlier), then it's way too much to expect them to know about an admittedly obscure API.
So what's the task that you'd schedule? Now, I agree that the best you can do on Windows is to set up a task to call your updater. I'm just pointing out why that sucks.
-
@ASheridan said:
Where is this 32KB limit coming from? Is there only one true INI parser and all others are false? The INI format doesn't impose any limit at all.
Have you read it?
I'm trying to find a copy, but since it's been deprecated so long apparently Microsoft never bothered posting it to their website. (Or it's indexed really weird in search engines...)
-
Okay, fine. Except for one point, I'll address everything in your link point-by-point. Note, however, that Linux distributions do not use .INI files. That will become important here shortly.
- INI files can't do Unicode: This is the one point I can't address. I've not had a situation where I needed to deal with a config file in Unicode. Others should be able to address this.
- INI security is not granular enough: Many daemons are set up so their configuration can be broken down into separate configuration files. You give permission to the files for those users that need to be able to change them. The other files of the config remain read-only.
- Multiple writers can overwrite INI files: That's fucking stupid. You use file locking as needed. Grab an exclusive lock and the other thread can't write to it.
- INI files can suffer a DoS . . . this is bad if the file is holding security information: Technically possible, I've yet to see it, if you've got a program misbehaving that badly you've got other issues.
- INI files can only contain strings; binary data needs to be encoded: for short amounts of binary data, encoding is not a big deal. Powerful systems that they are these days, the difference in processing is miniscule. My known_hosts files for SSH encodes the key for a known system, so what? If there's that much binary data to be stored, it should be stored in a separate file anyway.
- Parsing an INI file is comparatively slow: Not today.
- Many programs open the INI file and read them directly so the format cannot be extended: . . . why??? System settings are under /proc these days. There's no reason a program I'm running should be looking directly into the configuration files, save for the program itself. And since Linux distributions do not use .INI files you can have them in any format you need.
- INI files are limited to 32 KB: Nope. Again, Linux distributions do not use .INI files so they have no such restriction.
- The default location . . .: is wherever is compiled into the program. But typically this is somewhere in the /etc directory. For a locally installed app, it can be in /usr/local/appname/etc.
- INI files can't be hierarchical: Perhaps true under Windows, but you can do what you want with config files under Linux. They're not .INI files.
- Central administration is difficult: Using Debian for a moment, you can set up your own repository and have the enterprise download updated packages from there. Package any configuration files you need distributed into a package.
- INI files can't do Unicode: This is the one point I can't address. I've not had a situation where I needed to deal with a config file in Unicode. Others should be able to address this.
-
@boomzilla said:
So what's the task that you'd schedule? Now, I agree that the best you can do on Windows is to set up a task to call your updater. I'm just pointing out why that sucks.
So what does Linux do? Magical fairy dust allows it to check for updates without using a schedule of some sort, or using a background process of some sort?
Maybe it sucks, but what's better? We don't have magical fairy dust here in the Windows world.
-
@blakeyrat said:
The .ini format is a documented and specified format created by Microsoft in long ages past. If you don't follow the specs, it's not an .ini file. It's just a text file that happens to look an awful lot like an .ini file.
Yeah, because Microsoft are really fucking good at documenting their formats and keeping to them. I'm still yet to see any fucking evidence of there being a limit on the file other than Windows had problems with reading a text file that size all in one go.
-
@ASheridan said:
I found a reference to the limit, which appears to be some weird-ass Windows-specific limit. So tell me again, why can't an INI file be greater than 32KB?
THE ENTIRE FUCKING FORMAT was created by Microsoft for use in Windows 1, 2, and 3. THAT IS WHY THE FORMAT EXISTS. It's not a weird-ass "Windows-specific limit", it's DEFINED IN THE FILE FORMAT. THAT IS THE WHOLE POINT OF THE FORMAT.
Jesus fuck does nobody have ANY sense of history in the computer industry at all?
-
@blakeyrat said:
A programmer CAN write an application in such a way that it's a non-point. But it CAN write an application in such a way that it is.
Windows CAN be written to be a good OS. But it's not.
-
@Lorne Kates said:
I'm not using WSUS. I'm using Windows Automatic Updates, which is also known as WSUS. I don't know why you would use WSUS outside a corporate, managed network. Just use WSUS like I do. I'm pretty sure it comes on by default.
As an aside: Skype was installed through Windows Update (aka: WSUS), not Windows Server Update Server (aka: WU) to my home computer.
Now you're just typing gibberish to piss me off.
-
@blakeyrat said:
THE ENTIRE FUCKING FORMAT was created by Microsoft for use in Windows 1, 2, and 3. THAT IS WHY THE FORMAT EXISTS. It's not a weird-ass "Windows-specific limit", it's DEFINED IN THE FILE FORMAT. THAT IS THE WHOLE POINT OF THE FORMAT.
Look, if you're going to argue that the .INI format is a specific format, then your whole argument disappears because Linux distributions do not use .INI files. Linux distributions do not use a Microsoft Windows-based format. Linux distributions use text-based configuration files, but harping on the .INI format means your argument has completely disappeared.
So you're either talking specifically about the .INI format, which means you have no argument with Linux, or we're talking about text-based configuration files in general, in which case every single point has been rebutted.
Either way, you lose.
-
@blakeyrat said:
@boomzilla said:
So what's the task that you'd schedule? Now, I agree that the best you can do on Windows is to set up a task to call your updater. I'm just pointing out why that sucks.
So what does Linux do? Magical fairy dust allows it to check for updates without using a schedule of some sort, or using a background process of some sort?Maybe it sucks, but what's better? We don't have magical fairy dust here in the Windows world.
I'm trying to follow you here, but now you seem to be denying the existence of Windows Updates (or whatever Lorne wants it to be called). Have you really never used Windows?
-
@nonpartisan said:
INI security is not granular enough: Many daemons are set up so their configuration can be broken down into separate configuration files. You give permission to the files for those users that need to be able to change them. The other files of the config remain read-only.
Many but not all. This is something the OS should do, you shouldn't have to rely on developers to provide it. (Especially since developers are shit.)
@nonpartisan said:
Multiple writers can overwrite INI files: That's fucking stupid. You use file locking as needed. Grab an exclusive lock and the other thread can't write to it.
Again: this is something the OS should do.
@nonpartisan said:
INI files can suffer a DoS . . . this is bad if the file is holding security information: Technically possible, I've yet to see it, if you've got a program misbehaving that badly you've got other issues.
So you admit it's a problem but since you've "yet to see it" you don't think it needs fixing.
@nonpartisan said:
INI files can only contain strings; binary data needs to be encoded: for short amounts of binary data, encoding is not a big deal. Powerful systems that they are these days, the difference in processing is miniscule. My known_hosts files for SSH encodes the key for a known system, so what? If there's that much binary data to be stored, it should be stored in a separate file anyway.
Well the Linux world already fellates text data and tries to pretend any other type of data simple doesn't exist. So I wouldn't expect you to understand. But in an ideal world, yes, the configuration data would be able to store images, sounds, whatever. I don't see how there could be any real debate over this.
BTW, this is another "I admit it's a problem but somehow I don't think it needs fixing".
@nonpartisan said:
Parsing an INI file is comparatively slow: Not today.
Remember the context of the post. The move from INI to the Registry was done on 386 and 486-class machines with 4 MB of RAM.
If you're going to argue that the Registry isn't ideal for 2012, well, maybe that's a point and we should move on to something better. But that's not what the post is about. And moving backwards into text-based configuration files would NOT be a forward move.
@nonpartisan said:
Many programs open the INI file and read them directly so the format cannot be extended: . . . why??? System settings are under /proc these days. There's no reason a program I'm running should be looking directly into the configuration files, save for the program itself. And since Linux distributions do not use .INI files you can have them in any format you need.
Linux doesn't have this problem because it has no set format for settings. This is one of the many reasons Linux sucks. (You can't write a general tool that does what Group Policy does, because it can't parse settings files in a consistent manner.)
So you're argument is fine as long as you don't want any Linux OS to ever been centrally-manageable. But a lot of companies do. Which is why they all moved to Windows. The fact that Linux users still don't see it as a valuable feature, after Microsoft (and to a lesser extent, Novell) made billions of dollars providing it, is just ludicrous and insane.
@nonpartisan said:
Central administration is difficult: Using Debian for a moment, you can set up your own repository and have the enterprise download updated packages from there. Package any configuration files you need distributed into a package.
And then how do you prevent users from changing configuration? Read-only permissions? Now what if you want to let the user change their homepage, but no security settings, in the browser? How do you do that in Linux? Is it even possible?
@nonpartisan said:
Now, will do you a point-by-point rebuttal of this? I've had machines screwed up enough where I just had to rebuild them. With a Linux-based distribution, I've got better than a fighting chance to be able to find the errant setting and fix it.
I'm not going to debate it because in a lot of ways the Registry does suck. The problem is if you replace it, and hey it's been 20 years almost maybe it's time to do that, you have to replace it with something better, and people saying text-based configuration files are that thing are totally missing the point.
As long as he's just talking about the Registry's flaws and not suggesting people use text-based configuration instead (and a cursory examination leads me to believe that's what's there), I really have no problem with the post.
-
@boomzilla said:
I'm trying to follow you here, but now you seem to be denying the existence of Windows Updates (or whatever Lorne wants it to be called). Have you really never used Windows?
Windows Update runs on a schedule. Which is (according to you) something that "sucks".
-
@nonpartisan said:
Now, will do you a point-by-point rebuttal of this?
<handwavey bollocks about how nothing but Windows should be reading/writing the registry at that level>? Will that do ya? ;)
-
@nonpartisan said:
Look, if you're going to argue that the .INI format is a specific format, then your whole argument disappears because Linux distributions do not use .INI files.
Hey ASheridan made (and defended) the claim that PHP used the INI format. I've been doing nothing in this thread but trying to convince him it does not. So don't yell at me, yell at him.
@nonpartisan said:
or we're talking about text-based configuration files in general, in which case every single point has been rebutted.
Not rebutted well, though. Saying "we understand there are problems but don't bother to fix them" is not endearing me to the Linux community, it just reinforces my belief that they're lazy fucks who don't give a shit about software correctness if it means even an iota of more work for them.
-
@ASheridan said:
@RaceProUK said:
I found a reference to the limit, which appears to be some weird-ass Windows-specific limit. So tell me again, why can't an INI file be greater than 32KB?@ASheridan said:
"INI files are limited to 32KB in size." - Are you fucking kidding me? I've got tons of .ini files that are bigger than 32KB, the php.ini file is one for a start.
And they use their own INI parser as a result.
That would be the limit of [url=http://msdn.microsoft.com/en-us/library/ms724353%28VS.85%29.aspx]Microsoft's INI Parser[/url], which most likely uses a 16-bit signed integer as a counter somewhere.
As blakey has already pointed out (oh my lord, I'm agreeing with blakey?!) INI has been deprecated for 17 years now (since the release of Windows 95) and predates Windows NT.
Mentioning Windows NT is important, because WinNT uses UCS-2 (Windows 2000 and earlier) or UTF-16 (Windows XP and later) for its various character resources... and is also why .NET strings are stored as UTF-16 internally.
-
@Lorne Kates said:
I'm not using WSUS. I'm using Windows Automatic Updates, which is also known as WSUS. I don't know why you would use WSUS outside a corporate, managed network. Just use WSUS like I do. I'm pretty sure it comes on by default.
As an aside: Skype was installed through Windows Update (aka: WSUS), not Windows Server Update Server (aka: WU) to my home computer.
I'm just going to assume you're totally insane from your statements here.
-
@blakeyrat said:
@boomzilla said:
I'm trying to follow you here, but now you seem to be denying the existence of Windows Updates (or whatever Lorne wants it to be called). Have you really never used Windows?
Windows Update runs on a schedule. Which is (according to you) something that "sucks".
It sucks in a few ways, none of which have anything to do with running it on a schedule. The suckage we're currently talking about is how Windows Updates cannot seemingly help the user with updating non-MS software, and forces us to put up with the suckage of Adobe's and other bespoke software updaters.
Not that I expect you to admit that you understand this point. Your ignorance has actually moved on from being annoying to being funny now. Because you're either really stupid or just trying to look like you are.
-
@blakeyrat said:
@ASheridan said:
Re-read my post. I said I didn't need to.
Yes I know you said that, but I don't believe you're enough of a loser to actually examine every single shared library for every single process running on your computer for every single update, I think you're simply going by the package manager telling you "whelp! You don't have to update! Lookie that!" instead of actually not having to update. You haven't demonstrated otherwise.
@ASheridan said:
Well, not gonna bite; it's an intentionally joke page
No it's not. Why would you think so? Every point he makes is valid.
A lot of the points he makes are actually kind of silly, and a lot of the other ones are specific to INI files, which, as has been pointed out, are not the only way to use a flatfile for configuration.
And what's the deal with wanting to update from multiple threads anyway? That's just ridiculous. Configuration updates should only happen as a result of user actions (the user changing configuration settings) and the UI can only run on one thread anyway. So if you're trying to do that at all, you're doing it wrong.
My biggest gripe with the Registry is--to borrow another bit of Raymond Chen's wisdom--that it's a classic case of using global state to manage a local problem. Every application has its own configuration settings. They belong to that program and not to anything else, so why in the world does anyone think it's a good idea to lump all configuration together into one big file? Or to even have a One True Standardized Configuration Format at all, for that matter? The only point of standardization is interoperability, and that really doesn't apply here. You shouldn't have to be able to easily access some other program's configuration settings for your program to work right. (Unless you're creating highly specialized tools for customizing or extending that program, of course, in which case you've got to figure out/have access too all of their other file formats anyway, so what's the difference?)
With all the damage that registry corruption can cause, where one misbehaving program can screw things up for everyone, why did anyone ever think that putting all your eggs in one basket was a good idea?
-
@Mason Wheeler said:
and the UI can only run on one thread anyway.
That's not true in Windows.
You also have to consider different processes could want to use the same INI file. Nothing stops me from starting up 37 copies of the same app in Windows. And each of those copies have their own UI threads. (Well, unless that app has gone out of its way to say "no, only one at a time please.")
Edit: it's also not true that configuration changes would only happen due to user intervention. What about an app that wants to store, "hey I tried to contact this fileserver but it was down at this time" in its configuration? I mean arguably you'd say put that in the AppData folder, but it's a small enough tidbit of data to go in the configuration too.
@Mason Wheeler said:
They belong to that program and not to anything else, so why in the world does anyone think it's a good idea to lump all configuration together into one big file?
At the time, remember the historical context, it was done to save memory. Maybe now that isn't the best way of doing it. I notice that GConf, which someone linked to, does not do that.
@Mason Wheeler said:
The only point of standardization is interoperability, and that really doesn't apply here.
Oh hell yes it does.
@Mason Wheeler said:
You shouldn't have to be able to easily access some other program's configuration settings for your program to work right.
Not for "your program to work right", I don't even know what that means. But you (you meaning "the system administrator") should sure as fuck have extremely fine-grained control over the settings for every application your users run, and Windows Registry provides that.
@Mason Wheeler said:
With all the damage that registry corruption can cause, where one misbehaving program can screw things up for everyone, why did anyone ever think that putting all your eggs in one basket was a good idea?
When's the last time you saw a corrupted Registry? People keep bringing this up as if it's something that happens often. That was solved in fucking Windows 2000. Is this the same kind of Linux reality distortion field that also thinks that Windows bluescreens several times a day?
-
@blakeyrat said:
also thinks that Windows bluescreens several times a day
Mine does, but I think that has more to do with my desktop having a blue background image...
-
@boomzilla said:
The suckage we're currently talking about is how Windows Updates cannot seemingly help the user with updating non-MS software
Didn't we discuss this before? The funny thing is that of course the capacity to do this exist as WUA can automate the whole thing if only you could add non MS repositories and updates to the search list... :/ I guess for them is more troublesome than worthy
@C-Octothorpe said:my desktop having a blue background image...
*Buddies :)
-
@blakeyrat said:
@Mason Wheeler said:
and the UI can only run on one thread anyway.
That's not true in Windows.
You also have to consider different processes could want to use the same INI file. Nothing stops me from starting up 37 copies of the same app in Windows. And each of those copies have their own UI threads. (Well, unless that app has gone out of its way to say "no, only one at a time please.")
Either way, even if the computer is a multitasking system, the *user* is still single-threaded, and is not capable of changing things in two instances of a program at the same time. (And if the program can't open its config file, write changes, and close it again faster than the user can task-switch, it's got bigger problems to worry about.)
Edit: it's also not true that configuration changes would only happen due to user intervention. What about an app that wants to store, "hey I tried to contact this fileserver but it was down at this time" in its configuration? I mean arguably you'd say put that in the AppData folder, but it's a small enough tidbit of data to go in the configuration too.
Yeah, it's small, but it's not configuration information. Why should you put that in a config file?
@Mason Wheeler said:
They belong to that program and not to anything else, so why in the world does anyone think it's a good idea to lump all configuration together into one big file?
At the time, remember the historical context, it was done to save memory.
I'm well aware of the historical context. The Registry was originally created in the very early days to solve an actual global problem: to provide a centralized registry of COM servers. It wasn't until Windows 95 that they mutated it into the current "global store everything here repository" monstrosity. And by the time Windows 95 came around, Moore's Law had iterated enough times that systems with tens of megabytes of ram, backed by virtual memory on hard discs that were beginning to break the gigabyte barrier IIRC. It was the dawn of the golden age when memory stopped being a scarce resource.
And all that aside, how is that even relevant? Maybe I'm missing something, but how exactly does putting all your system's eggs in one (very big) basket reduce memory usage better than having one (small) configuration file per program?
@Mason Wheeler said:
The only point of standardization is interoperability, and that really doesn't apply here.
Oh hell yes it does.
How? Why? With what?
@Mason Wheeler said:
You shouldn't have to be able to easily access some other program's configuration settings for your program to work right.
Not for "your program to work right", I don't even know what that means. But you (you meaning "the system administrator") should sure as fuck have extremely fine-grained control over the settings for every application your users run, and Windows Registry provides that.
If you say so...
@Mason Wheeler said:
With all the damage that registry corruption can cause, where one misbehaving program can screw things up for everyone, why did anyone ever think that putting all your eggs in one basket was a good idea?
When's the last time you saw a corrupted Registry? People keep bringing this up as if it's something that happens often. That was solved in fucking Windows 2000. Is this the same kind of Linux reality distortion field that also thinks that Windows bluescreens several times a day?
Solved in Windows 2000? Are you trying to troll me, or are you seriously just that ignorant? Do you have any idea how many WinXP systems I had to rebuild for friends and family members due to the Registry getting b0rked beyond repair? Sure, it's gotten a bit better recently, but it still happens in Vista and Win7, to the point where systems become unable to boot without reinstalling the OS. I've seen it and had to deal with it, so don't even try to tell me it no longer happens as of Windows 2000.
The point is that the "all your eggs in one basket" system of the Registry is a nightmare, and an obvious nightmare at that. What could possibly have led Microsoft to create a global system with a single point of failure like that, and then encourage everybody to integrate with it as tightly as possible?!?
-
@Mason Wheeler said:
My biggest gripe with the Registry is--to borrow another bit of Raymond Chen's wisdom--that it's a classic case of using global state to manage a local problem. Every application has its own configuration settings. They belong to that program and not to anything else, so why in the world does anyone think it's a good idea to lump all configuration together into one big file?
Because its not store in a single file. the HKEY_USER_* keys are stored in per-user files, and each key as its own ACL. It only looks like its stored in a single file becuase regedit presents the registry as a tree with a single root. Its easier to ask code monkeys to use the Registry API than having them actually pay attention to OS conventions that get ignored.
-
@serguey123 said:
@boomzilla said:
The suckage we're currently talking about is how Windows Updates cannot seemingly help the user with updating non-MS software
Didn't we discuss this before? The funny thing is that of course the capacity to do this exist as WUA can automate the whole thing if only you could add non MS repositories and updates to the search list... :/ I guess for them is more troublesome than worthyYes, we have, and I totally agree with you. How many more times will this be discussed before blakeyrat figures it out? Or maybe his focus on INI files signals his surrender on this front?
It's that "more troublesome than worthy" that I have a hard time understanding on their part. It's in everyone's (except those who profit from malware, of course) interest to make it easier to make sure your software is all updated. But I'm sure blakeyrat has seen statistics showing that not having a reliable software update mechanism is a net positive for usability.
-
@ubersoldat said:
Is this a consecuence of the Windows Registry?
It's generally an indication that the update includes a file that is somehwere in the Windows directory, or is locked because it's in use. Or, at least, that the update installer believes this.
Mostly, this sort of nonsense is Microsoft's fault, not Adobe's.
It is better than it used to be.
-
@MiffTheFox said:
The problem with APT or any Linux package manager is that you're limited to whatever whims a particular distro has about what software to put on there.
Well, if you don't want to add third party sources, yes, you are restricted to the distro.
-
@Mason Wheeler said:
(And if the program can't open its config file, write changes, and close it again faster than the user can task-switch, it's got bigger problems to worry about.)
Context context context.
Yes NOW it's not a problem. NOW is not when the Registry was designed. The Registry was designed in 1991-ish.
@Mason Wheeler said:
Yeah, it's small, but it's not configuration information. Why should you put that in a config file?
I already said it was arguable, what do you want from me?
@Mason Wheeler said:
I'm well aware of the historical context.
Then why'd you post that first snippet?
@Mason Wheeler said:
It was the dawn of the golden age when memory stopped being a scarce resource.
The dawn yes. But it still frequently was asked to run programs off floppy disks. Your memory is rosy-colored.
@Mason Wheeler said:
Maybe I'm missing something, but how exactly does putting all your system's eggs in one (very big) basket reduce memory usage better than having one (small) configuration file per program?
I dunno, I didn't build the thing.
@Mason Wheeler said:
If you say so...
This is exactly what I'm talking about. Why do Linux users insist that central management of networks is a useless feature, despite ALL EVIDENCE TO THE CONTRARY? Despite the companies that existed to provide EXACTLY AND ONLY THAT? Despite Microsoft's continued success year-over-year? IT'S INSANE! LITERALLY INSANE!
@Mason Wheeler said:
Do you have any idea how many WinXP systems I had to rebuild for friends and family members due to the Registry getting b0rked beyond repair?
Zero? I'd believe Windows ME, but I won't believe XP. Cater your lies to your audience.
@Mason Wheeler said:
I've seen it and had to deal with it, so don't even try to tell me it no longer happens as of Windows 2000.
You've seen it in Vista and Windows 7.
@Mason Wheeler said:
The point is that the "all your eggs in one basket" system of the Registry is a nightmare, and an obvious nightmare at that.
Yes, it's time that design decision were re-examined. I've said this like 3 times now.
@Mason Wheeler said:
What could possibly have led Microsoft to create a global system with a single point of failure like that, and then encourage everybody to integrate with it as tightly as possible?!?
The benefits outweighed the problems.
-
@serguey123 said:
@C-Octothorpe said:
I have this one - found it mildly amusing at the time:my desktop having a blue background image...
*Buddies :)
-
@boomzilla said:
It's that "more troublesome than worthy" that I have a hard time understanding on their part. It's in everyone's (except those who profit from malware, of course) interest to make it easier to make sure your software is all updated. But I'm sure blakeyrat has seen statistics showing that not having a reliable software update mechanism is a net positive for usability.
I don't disagree with anything you just said. Stop saying that I do.
-
@blakeyrat said:
@boomzilla said:
It's that "more troublesome than worthy" that I have a hard time understanding on their part. It's in everyone's (except those who profit from malware, of course) interest to make it easier to make sure your software is all updated. But I'm sure blakeyrat has seen statistics showing that not having a reliable software update mechanism is a net positive for usability.
I don't disagree with anything you just said. Stop saying that I do.I will if you will
Wait, are you just agreeing with the bit that you quoted, or also about the shortcomings of Windows as relates to third party software? I just don't want to assume one thing and allow you the plausible deniability later that you never agreed that Windows doesn't have the ability to manage non-MS software updates.
-
@blakeyrat said:
@Mason Wheeler said:
Do you have any idea how many WinXP systems I had to rebuild for friends and family members due to the Registry getting b0rked beyond repair?
Zero? I'd believe Windows ME, but I won't believe XP. Cater your lies to your audience.
I've definitely had to help friends and family recover from corrupt registries on Windows XP, on at least seven separate instances; and it's happened to me a couple times, usually following a power failure.
Luckily there is a "last known good configuration" that has been recoverable maybe 80% of those times, but other times file system corruption made even that worthless.
-
@powerlord said:
@Lorne Kates said:
I'm not using WSUS. I'm using Windows Automatic Updates, which is also known as WSUS. I don't know why you would use WSUS outside a corporate, managed network. Just use WSUS like I do. I'm pretty sure it comes on by default.
As an aside: Skype was installed through Windows Update (aka: WSUS), not Windows Server Update Server (aka: WU) to my home computer.
I'm just going to assume you're totally insane from your statements here.
It took you this long?
(Though I still stand by my original point: Microsoft force installing Skype on home PC via Windows Update is a bad idea for everyone. It's bad PR for Microsoft. Users with violated trust will shut off automatic Windows Update, thus its bad for them due to lowered security. Skype gets a bad reputation for being malware. No one wins).
-
@blakeyrat said:
@nonpartisan said:
INI files can suffer a DoS . . . this is bad if the file is holding security information: Technically possible, I've yet to see it, if you've got a program misbehaving that badly you've got other issues.
So you admit it's a problem but since you've "yet to see it" you don't think it needs fixing.
There are easily thousands of ways a program can cause mischief once it's on the other side of the airtight hatchway.
-
@Lorne Kates said:
(Though I still stand by my original point: Microsoft force installing Skype on home PC via Windows Update is a bad idea for everyone. It's bad PR for Microsoft. Users with violated trust will shut off automatic Windows Update, thus its bad for them due to lowered security. Skype gets a bad reputation for being malware. No one wins).
But users don't get it. That's the point you're still not getting.
Maybe the 0.00001% of users who do retarded things or have retarded network administrators got it. But "users" as a generalization were not affected in the slightest.
-
@blakeyrat said:
@Mason Wheeler said:
(And if the program can't open its config file, write changes, and close it again faster than the user can task-switch, it's got bigger problems to worry about.)
Context context context.
Yes NOW it's not a problem. NOW is not when the Registry was designed. The Registry was designed in 1991-ish.
And in 1991-ish, you didn't run 37 copies of the same program. (Live by the context, die by the context.)
@Mason Wheeler said:
It was the dawn of the golden age when memory stopped being a scarce resource.
The dawn yes. But it still frequently was asked to run programs off floppy disks. Your memory is rosy-colored.
Perhaps, but what I remember is that I stopped running programs off floppy discs back in the 286 era. Floppies were for installing stuff onto the hard drive, or for transporting files from one computer to another, but certainly not for running programs when you had a hard disc available! That's just crazy talk, even way back then.
@Mason Wheeler said:
If you say so...
This is exactly what I'm talking about. Why do Linux users insist that central management of networks is a useless feature, despite ALL EVIDENCE TO THE CONTRARY? Despite the companies that existed to provide EXACTLY AND ONLY THAT? Despite Microsoft's continued success year-over-year? IT'S INSANE! LITERALLY INSANE!
I wouldn't know. Like I said, I'm not a Linux user. That doesn't mean I can't call Microsoft out on bad design decisions when they make them. And what does the Registry have to do with "central management of networks" anyway? Because that's something else I'm not: a network administrator. So right now you're saying a bunch of ranty stuff that makes no sense and feels completely out of context.
@Mason Wheeler said:
Do you have any idea how many WinXP systems I had to rebuild for friends and family members due to the Registry getting b0rked beyond repair?
Zero? I'd believe Windows ME, but I won't believe XP. Cater your lies to your audience.
None so blind as those who will not see. But if you won't believe me, maybe you'll believe Google?
@Mason Wheeler said:
I've seen it and had to deal with it, so don't even try to tell me it no longer happens as of Windows 2000.
You've seen it in Vista and Windows 7.
Yes. And in XP.
@Mason Wheeler said:
What could possibly have led Microsoft to create a global system with a single point of failure like that, and then encourage everybody to integrate with it as tightly as possible?!?
The benefits outweighed the problems.
Maybe if you're a network administrator. Maybe. Again, I wouldn't know. I'm not a network administrator. And furthermore, the vast majority of users are not network administrators. And the vast majority of programs that get installed on Windows systems have nothing to do with network administration. So if you're going to try to justify something that screws things up for everything, you'll need a better explanation than "it makes network administration easier" if you want to be taken seriously.
