You have a point, but on the other hand Rails' lock_version & exception method isn't exactly all that "AWESOME" compared to what the Paradox people are expecting, and compared to some of the better schemes in these comments.
My greater point was to convey my experience that 80% of the time someone asks for Record Locking, it's a low priority feature.
The delay in Vista and below seems to be mostly perceptual. Click start menu, something steals focus or something, and you can't do anything for a couple seconds. Maybe they fixed this simply with smarter window management.
It is just you. My Pentium 90 took something like 20-30 seconds to boot to the DOS prompt. Anecdotal, true, but it's nice to remind yourself that even booting into DOS was by no means instantaneous
Yeah, I have a P-133 where the "memory count" effect (complete with whirring noises) takes at least a minute to get through the 128MB of RAM.:/ Plus there's two SCSI cards in the machine.
Actually, I don't blame them. The first instinct of people coming from a client-server background is to introduce to some form of record locking. Since this isn't "in the box" with web app frameworks, it makes sense to push back on the feature until you have user feedback or other analysis that it's actually required. Otherwise you are spending valuable time coding/debugging a feature that will rarely ever be used.
I still don't understand how IE could be made less secure.
No matter what browser, "Install a plugin to view this website" is a very bad user practice to encourage. Users will never know the difference between "Google Chrome Frame" and "Super Malware Frame".
I wonder how much out-cry there was when Apple introduced the dock bar or whatever it's called.
Yes, the MacOS 9 types went onto the warpath (because using a tiny menu is obviously the best way to switch applications), but they got over it rather quickly. On the other hand, the Dock had certain functional problems that really weren't addressed until Expose and Stacks in later versions of the OS.
Yeah, I don't think anyone would deny that at least part of the motivation for the ribbon was marketing reasons.
Previously, MS-Office was gaining a reputation of stagnation, despite adding new features, it still looked like a warmed-over version of Office 95, and that was likely making upgrade sales that much more difficult.
(FWIW, after getting used to it, I generally like the ribbon, as it more greatly exposes certain features I use. For the digital typewriter crowd, I can see why it might be derided compared to the old toolbar.)
>IE still has a very enterprise-oriented development cycle and not the bleeding edge feature explosion we see in most open source browsers.
This Google plugin seems to be a very "enterprisey" feature because it allows system admins to roll out new standard-compliant webapps while not breaking the old IE-dependent ones, all while not confusing users by requiring them to use two different browsers.
Since (a) the plugin has to be installed, and (b) it has to be turned on with a metatag, it's not especially useful for public sites.
Oh, it's really not worth arguing. The claims of 'Team OS/2' were obnoxious back in the day, and they've just become more and more exaggerated as the years have gone by.
I suppose some people need their alternate history myths of a imaginary non-Microsoft world.
Possibly because according to the news, Microsoft has far more problems with patent trolls and their ilk than they do with Linux infringing on their intellectual property.
I can see how it makes sense to ally with the "good guys" (including the the biggest patent assholes aka IBM) to create a broad patent pool for mutual self-defense. This also benefits the OSS community because its only a matter of time until a patent troll goes after Firefox or OpenOffice instead of Microsoft.
The problem with 'file' is that it's system-dependent. If I create a new file type ("application/x-intlharvester"), there's no way I can transfer that across a random *nix system without losing the type info... unless I also use a file extension.
So while extensions are not really the Unix way, Unix doesn't give you any other way either.
I suppose xattrs are part of some specficiation, however the server software ecosystem doesn't seem to use them; you generally can't "round-trip" a file from a unix system and preserve the metadata.
I think that a lot of Unix users these days have a DOS or Windows background, though, so people tend to expect filenames to include extensions. Personally I'd like to see Linux move toward a scheme of file type identification based on xattrs, but it would be a long time before such a scheme would catch on...
Hmm. Some *nix things like *.c and *.o files go way back, however this might still reflect a DOS influence.
There certainly are times that having a visible file type is useful, and times when the old Mac "secret metadata" approach is a pain in the butt. I don't think it's a clear win either way even ignoring Windows.
but still not by the under-the-hood UN*X running any of them; to UN*X, it's just an indiscriminate part of the filename
Let's be clear - under-the-hood, *nix does not have any standardized way of tracking file types. Unlike MacOS/OSX, there's no type metadata stored with the file.
However, there are many *nix applications which use file extensions. Apache, for example, uses extensions to map to MIME types. Is this because the authors of Apache were enamored with CP/M? Or because there's no other practical way to handle it in standard unix?
While I enjoyed Ars' review, that comparison between BeOS and SL was extremely superficial, and IMO you shouldn't draw any conclusions from it; especially about something specific like application responsiveness.
(I mean, you can almost hear the author thinking "Threads?!? Um, didn't Be have threads?". It would have been a lot more interesting had he compared GCD to Java or Win32.)
My uncle spent the next year crowing about how, due to the AT&T breakup, AT&T was going to make a killing in the systems business due to Unix and their vaunted engineering capability.
AT&T sucked at marketing.
The problem went far deeper than just marketing. AT&T was entering an established market for UNIX workstations, and they ended up competing directly with their own customers. The resulting "UNIX wars" ended up stinking up the whole market.
And I had an old Olivetti AT&T PC - it seemed to be a solid XT clone. I expect the issue there was just the typical crappy margins in the PC hardware biz.
The flip side of that is that Bell Labs was essentially great propaganda for maintaining AT&T's regulated monopoly. AT&T heavily advertised their Bell Labs inventions, the implicit subtext being that if they were broken up, we would never get picture-phones or whatever other wonderful devices.
Sure, but then it's quarantined to the specific user.
Untrue! Anyone in the admin group (including the default user) can overwrite anything in the global/Applications directory with no authentication required. That's how "drag to install" works in the first place!
Given all the misinformation about OS X security being spread in this thread, I can see why Apple felt they had to add a malware checker.
(And sorry I don't have a source onhand, but you can google "Open safe files" or whatever the option is and read about how Safari automagically runs DMG installers)
Right, it's really not a technical kludge. I just found it ironic someone was complaining about the slow 32-bit transition in a circumstance where MS is effectively forcing people to go to 64-bit.
Dunno. While no platform is 100% secure, design does count for a lot. There are a lot of "proof of concept" hacks out there for the Mac, but very, very, very few "in the wild" 'sploits floating around, especially self-replicating ones like viruses and worms.
Well, there's apparently enough of them "in the wild" that Snow Leopard beta testers have discovered an unannounced anti-malware feature. Why not try to nip this in the bud?
I wouldn't put too much faith in "drag to install", because most malware doesn't actually need system privledges.
Also, reportedly websites have figured out how to make Safari automatically download this trojan and then launch the installer program. Users still need to enter their password, but having the dialog automatically popup makes the social engineering step that much easier.
Slashdot Mirror
You have a point, but on the other hand Rails' lock_version & exception method isn't exactly all that "AWESOME" compared to what the Paradox people are expecting, and compared to some of the better schemes in these comments.
My greater point was to convey my experience that 80% of the time someone asks for Record Locking, it's a low priority feature.
The delay in Vista and below seems to be mostly perceptual. Click start menu, something steals focus or something, and you can't do anything for a couple seconds. Maybe they fixed this simply with smarter window management.
It is just you. My Pentium 90 took something like 20-30 seconds to boot to the DOS prompt. Anecdotal, true, but it's nice to remind yourself that even booting into DOS was by no means instantaneous
Yeah, I have a P-133 where the "memory count" effect (complete with whirring noises) takes at least a minute to get through the 128MB of RAM. :/ Plus there's two SCSI cards in the machine.
Yeah, this is one of those posts I wish there was an edit button for :P Anyway, the UI isn't really in the box, just the more trivial database stuff.
Actually, I don't blame them. The first instinct of people coming from a client-server background is to introduce to some form of record locking. Since this isn't "in the box" with web app frameworks, it makes sense to push back on the feature until you have user feedback or other analysis that it's actually required. Otherwise you are spending valuable time coding/debugging a feature that will rarely ever be used.
This is not a risk we would recommend our friends and families take
Mom (yelling down into basement): This website says I need to install the Framey Goggle Control to see it? What do I do?
Slashdot using son: (mutters something about javascript benchmarks) (spends the next day cleaning spyware off mom's computer)
I still don't understand how IE could be made less secure.
No matter what browser, "Install a plugin to view this website" is a very bad user practice to encourage. Users will never know the difference between "Google Chrome Frame" and "Super Malware Frame".
I wonder how much out-cry there was when Apple introduced the dock bar or whatever it's called.
Yes, the MacOS 9 types went onto the warpath (because using a tiny menu is obviously the best way to switch applications), but they got over it rather quickly. On the other hand, the Dock had certain functional problems that really weren't addressed until Expose and Stacks in later versions of the OS.
Yeah, I don't think anyone would deny that at least part of the motivation for the ribbon was marketing reasons.
Previously, MS-Office was gaining a reputation of stagnation, despite adding new features, it still looked like a warmed-over version of Office 95, and that was likely making upgrade sales that much more difficult.
(FWIW, after getting used to it, I generally like the ribbon, as it more greatly exposes certain features I use. For the digital typewriter crowd, I can see why it might be derided compared to the old toolbar.)
>IE still has a very enterprise-oriented development cycle and not the bleeding edge feature explosion we see in most open source browsers.
This Google plugin seems to be a very "enterprisey" feature because it allows system admins to roll out new standard-compliant webapps while not breaking the old IE-dependent ones, all while not confusing users by requiring them to use two different browsers.
Since (a) the plugin has to be installed, and (b) it has to be turned on with a metatag, it's not especially useful for public sites.
Oh, it's really not worth arguing. The claims of 'Team OS/2' were obnoxious back in the day, and they've just become more and more exaggerated as the years have gone by.
I suppose some people need their alternate history myths of a imaginary non-Microsoft world.
This sort of corporate identity creation and branding has a significant impact on the way the public views a company,
Good point! Have you ever heard of a Lotus shop where the end users don't spit bile at IBM? ;)
Eventually you tie yourself in knots on issues like this and then realize it is all arbitrary
Yep. (People lower your thresholds to read the above post.)
Possibly because according to the news, Microsoft has far more problems with patent trolls and their ilk than they do with Linux infringing on their intellectual property.
I can see how it makes sense to ally with the "good guys" (including the the biggest patent assholes aka IBM) to create a broad patent pool for mutual self-defense. This also benefits the OSS community because its only a matter of time until a patent troll goes after Firefox or OpenOffice instead of Microsoft.
The problem with 'file' is that it's system-dependent. If I create a new file type ("application/x-intlharvester"), there's no way I can transfer that across a random *nix system without losing the type info ... unless I also use a file extension.
So while extensions are not really the Unix way, Unix doesn't give you any other way either.
I suppose xattrs are part of some specficiation, however the server software ecosystem doesn't seem to use them; you generally can't "round-trip" a file from a unix system and preserve the metadata.
I think that a lot of Unix users these days have a DOS or Windows background, though, so people tend to expect filenames to include extensions. Personally I'd like to see Linux move toward a scheme of file type identification based on xattrs, but it would be a long time before such a scheme would catch on...
Hmm. Some *nix things like *.c and *.o files go way back, however this might still reflect a DOS influence.
There certainly are times that having a visible file type is useful, and times when the old Mac "secret metadata" approach is a pain in the butt. I don't think it's a clear win either way even ignoring Windows.
but still not by the under-the-hood UN*X running any of them; to UN*X, it's just an indiscriminate part of the filename
Let's be clear - under-the-hood, *nix does not have any standardized way of tracking file types. Unlike MacOS/OSX, there's no type metadata stored with the file.
However, there are many *nix applications which use file extensions. Apache, for example, uses extensions to map to MIME types. Is this because the authors of Apache were enamored with CP/M? Or because there's no other practical way to handle it in standard unix?
While I enjoyed Ars' review, that comparison between BeOS and SL was extremely superficial, and IMO you shouldn't draw any conclusions from it; especially about something specific like application responsiveness.
(I mean, you can almost hear the author thinking "Threads?!? Um, didn't Be have threads?". It would have been a lot more interesting had he compared GCD to Java or Win32.)
My uncle spent the next year crowing about how, due to the AT&T breakup, AT&T was going to make a killing in the systems business due to Unix and their vaunted engineering capability.
AT&T sucked at marketing.
The problem went far deeper than just marketing. AT&T was entering an established market for UNIX workstations, and they ended up competing directly with their own customers. The resulting "UNIX wars" ended up stinking up the whole market.
And I had an old Olivetti AT&T PC - it seemed to be a solid XT clone. I expect the issue there was just the typical crappy margins in the PC hardware biz.
The flip side of that is that Bell Labs was essentially great propaganda for maintaining AT&T's regulated monopoly. AT&T heavily advertised their Bell Labs inventions, the implicit subtext being that if they were broken up, we would never get picture-phones or whatever other wonderful devices.
Sure, but then it's quarantined to the specific user.
Untrue! Anyone in the admin group (including the default user) can overwrite anything in the global /Applications directory with no authentication required. That's how "drag to install" works in the first place!
Given all the misinformation about OS X security being spread in this thread, I can see why Apple felt they had to add a malware checker.
(And sorry I don't have a source onhand, but you can google "Open safe files" or whatever the option is and read about how Safari automagically runs DMG installers)
You must be running as an admin user.
The default user is an admin user, so in most cases this does mean any random app can trojan iTunes.
Just because it's unix doesn't mean the permissions are as tight as your linux box.
Right, it's really not a technical kludge. I just found it ironic someone was complaining about the slow 32-bit transition in a circumstance where MS is effectively forcing people to go to 64-bit.
Dunno. While no platform is 100% secure, design does count for a lot. There are a lot of "proof of concept" hacks out there for the Mac, but very, very, very few "in the wild" 'sploits floating around, especially self-replicating ones like viruses and worms.
Well, there's apparently enough of them "in the wild" that Snow Leopard beta testers have discovered an unannounced anti-malware feature. Why not try to nip this in the bud?
I wouldn't put too much faith in "drag to install", because most malware doesn't actually need system privledges.
Also, reportedly websites have figured out how to make Safari automatically download this trojan and then launch the installer program. Users still need to enter their password, but having the dialog automatically popup makes the social engineering step that much easier.