First of all, "resort to?" You can fly from Seattle to Philadephia in 5 hours, and we have to "resort to" that speed? The fact that only two generations ago, the majority of people spent their entire lives never leaving their own state, and now virtually everybody on Earth has visited a different continent? How about a little teeny bit of appreciation for the modern age, huh?
"Resort to" my ass, you should be forced to drive a team of horses to work for the next week as punishment.
But if you want a list:
1) Fuel consumption. Supersonic aircraft suck down the gas at an alarming rate, leading to...
2) Crappy economic performance. A typical Concorde sucked down something like one and a half times the fuel of a typical 747 on the same route. Meanwhile, the 747 is carrying 300 passengers while the Concorde is struggling to cram 100 in. It would be hard to find a less economical option than supersonic flight. (IIRC, even with the stupid-high ticket prices, the Concorde business was operated at a loss.)
3) Sonic booms, leading to...
4) Being banned over many, many states and municipalities. There's a reason the Concorde pretty much only crossed oceans, there's nobody on the ocean to bother with your noise.
There's also issues of pilot training, safety features, pollution, etc. The runway strike that took down that Concorde in France would probably have been survivable by almost any other aircraft at that airport. You build high performance, super-precision machines and they get delicate. And that thick black smoke that comes out the back-end of the Concorde wasn't made of sunshine and butterflies. But reasons 1 and 2 are more than enough for airlines.
The A-380 and 777 are good buys because they have the high passenger capacity and much lower fuel consumption when compared to the 747, due to only feeding two engines instead of four. Even a supersonic built with everything we've learned from military jets and everything we've learned from Concorde wouldn't even remotely come close.
Those American MD-80s seem to be flying just fine despite "acid rain" and "airborne sand". Of all the explanations of things that can take down aircraft, you picked the two most ridiculous by a large margin.
How about fatigue? That one is really hard to identify in aging planes, has taken down several flights in the past, and use of new materials can lead to entirely different fatigue problems.
That said, I'd trust Boeing with my life over any other company out there.
It's kind of funny now remembering how Boeing were crowing over the A380 problems,
[citation needed]
I actually remember a few statements from Boeing officials acknowledging how difficult producing a new model of airliner is, after Airbus announced A-380 delays. Boeing got some contracts, but I hardly believe they were "crowing" over the delays. There is such a thing as good-natured competition, and Boeing and Airbus definitely have it.
I agree that this case is stupid, but there are a lot of people making a lot of money blogging in this day and age, so it's very well possible that her blog is pulling in enough advertising income to be taxable. (Given the subject matter of the blog, I doubt it. But I can't be sure.)
Try it with HP. It took more than an hour, and something like 4-5 reboots, to get a working computer on my HP tablet. But, and here's the problem, *all* of that delay was due to HP crapware installed on it.
I grabbed the Vista Home Premium DVD that came with my Dell desktop (say what you want about Dell, but at least they give you the *actual* OS disk and not a disk loaded with crapware), installed it on the tablet and booted it again. Less than 2 minutes. In fact, the entire OS install was quicker than just booting HP's pre-installed image.
I've learned my lesson: Never buy from HP. I'll stick with Dell; my Dell had maybe 3 pieces of crapware, all easily-removed, and they gave me an actual OS disk. HP, I paid an extra $20 for the disk (they suckered me) and it turns out it's a disk full of crapware. I don't get how HP customers stand for this, they should revolt with the way they're being treated.
The Xbox, Xbox 360 and Zune are all pretty damned good products.
What's your exact complaint about these systems? Even if you hate the Xbox and Zune, are you seriously saying that the Xbox 360 is a bad game console?
I've always thought that Microsoft Hardware generally comes out much better than their software products, I think due to the increased competition in the hardware area. Microsoft knows they can't rest on their laurels and let Sony invent an online gaming system, so they come up with Xbox Live and blow them (and Nintendo) out of the water.
This depends entirely on the market an application is meant for. The vast majority of Windows software isn't aimed at corporate users with Active Directory setups, so why should the people who write it spend time and effort supporting group policies if none of their customers will ever use them?
If you're not following the OS recommendations, and doing stuff not recommended by the OS maker, for instance:
Why not keep things simple and put it in the same directory as the application instead?
Your application *will* break when a future version of the OS comes out. I'm not saying "may", I'm saying "will." If you actually tried to write configuration information in the same directory as the application, your program is broken in Vista. (And for all multi-user computers in NT4, Windows 2000, Windows XP.)
Manifests go there because they never change. At least not until the application is patched or upgraded, which requires admin permissions anyway. Configuration information could potentially change daily.
Quote: "So for Windows 95, Microsoft advised its supporting manufacturers that applications that qualify for the Windows 95 logo should disavow any use of.INI files, in favor of the Registry instead."
That quote obviously means information that previously went in.ini files should now go in the Registry instead. That is the only sane way that sentence can be interpreted. You were implying that the recommendation was that *all* application-specific data should go into the registry.
2) Locks only apply while a key is open, and Microsoft's programming guidelines say they shouldn't be left open for long periods to minimise the possibility of corruption occurring. So it's actually the software that MS would define as being correctly written which will have problems with multiple instances overwriting each others' data.
Yes and no. Another difference is that the registry is finer-grained... with XML/INI/whatever other format you use, the lock extends to the entire file, so if one instance has it locked, another instance is out of luck. With the registry, the instance can lock only what it needs at the moment, and the other instance can still access everything else.
You are either being deliberately obtuse, or you really don't know why your reply was stupid. I hope for your sake that the former is true.
I'm trying to figure out why one file would be more or less prone to being corrupted than another file. I'm not being obtuse, I'm trying to figure out exactly what your argument against the registry is... it's a file, so it can be corrupted? Well... ok. So's everything else, what's your point?
How long does a batch file take to run? If you can give a general answer that doesn't boil down to "it depends what it's doing", then this is yet another one of your utterly meaningless answers.
It takes a fraction of a second to do the type of tasks we're arguing about. But that's not the point.
The point is that if you do it with a batch file, you can only make the change at login. If you do it via group policy, the change will be updated in 60-120 minutes. If a user never logs out, the batch file never runs and the change is never made. Using group policy and the registry doesn't have that problem.
I only log out my work computer on weekends, most nights I just lock it and leave.
What I disagree with is the idea that every value any application ever stores should be put in the same central repository as critical system settings that can render a system unbootable if they're changed.
Wow, an actual point. Except that it only applies for software run as administrator, other software doesn't have permissions to stomp on the Local Machine registry entries. In a corporate environment, that's "good enough", but at home it's a problem since a lot of home users always run as administrator. Microsoft's customers are corporations.
Hence the fact that so much application-specific data is stored in the Registry as undocumented groups of numbers with meaningful names such as "Hrrlh99_07014". The people who wrote that software were obviously thinking "Hey, this private stuff may well be used to set group policies in a corporate network, so we'll support that by using names and data formats that don't make sense to anyone else for our Registry entries, and give further assistance by working hard to ensure that we don't let customers know anything about what it's used for and how it's laid out".
If software makers don't document their registry keys, how is that Microsoft's fault? Look, Microsoft provides the framework, they can't police every single program to make sure that every single program is using the framework exactly as Microsoft planned it to be used-- and if they tried, imagine the cry of agony from the Linux crowd here at Slashdot.
In addition to all that, there's also the point that the.ini file can easily be undocumented also, so the registry isn't any worse-off than the alternative in this case.
This is a non-argument and has nothing to do with the benefits of the registry.
I'm talking about _any_ information applications store during installation, updating, or between sessions that's not meant to be read or modified by either products from other vendors, or end users.
Well, first of all, configuration information is meant to be "read or modified" by products from other vendors and end users. The product from other vendors being tools like group policies, and the end users being people who select Tools->Options.
In fact, by your definition, the AppData directory is exactly where you should put that data, since it's data the that (by your own definition) isn't meant to be modified by other vendors or end users. But that's not what normal people think of when they hear the word "configuration". The AppData directory is even nicely designed so that you can separate information that should follow the user (i.e. browser bookmarks) from data that should stay on a single computer (i.e. browser cache.)
You obviously didn't read the paragraph you're replying to, because that particular structure was not part of Windows/NT 4.X or Windows-95 when MS required local data to be stored in the Registry for Windows logo compliance.
First of all, I'm pretty sure Microsoft never required local data to be stored in the registry. The registry is, and always has been, for configuration only. Are you seriously suggesting that IE4 stored (or should have stored) the browser cache in the registry? That's ridiculous.
Secondly, that structure was not in place for Windows 95, although if you asked for the "Application Support" directory in Windows 95, Windows would return some location. (Not sure exactly where... somewhere in/Windows probably.) It was, however, in place for Windows NT.
They gain the ability to prevent non-technical people from cloning installed applications by the simple expedient of copying directory structures to media or across a network.
I'm pretty sure they could have done that before. At least in Windows 95, where you could barf.dlls in whatever random directories you wanted and simply link to them... a naive copy of the applications would fail to find the libraries and not start. Plus, Mac OS didn't have anything remotely equivalent to the registry until OS X came out, and Mac software developers never seemed to have a problem making copy protection work. (And OS X doesn't use it's registry-type database for configuration information-- it stores it in XML files instead.)
If Microsoft don't care what apps people use, then why do they have schemes like Windows Genuine Advantage and Office Genuine Advantage?
Ok; fine. I correct my statement to read "Microsoft doesn't care what apps people use, other than to ensure they paid for Microsoft apps that ar
Even in high school, we have a civics teacher who taught us a lot about the world with Civilization (the original board game the computer game is based on, although he had the computer game available also.) And when I left high school, I spent a summer with a group playing games like Diplomacy, Axis and Allies, Shogun, etc. They're obviously not for everybody, but you learn a lot about how the real world works by playing Diplomacy. Especially when you get stabbed in the back by all the other players, and die in a single turn.:)
What's the problem? 300 people connect to the BBC and stream Benny Hill. Those 300 streams take X amount of bandwidth, once for every subscriber, and 300 times for the BBC.
Each subscriber pays for his little tube, and the BBC pays for it's tube big enough to carry 300 Benny Hill streams.
but the fact that I and many, many other developers don't think that a centralised global repository is an appropriate place for storing persistent information which is only relevant to the application that wrote it, or other applications by the same vendor.
Well, part of the point is that it is relevant for corporate networks using active directory and group policies. There's no reason a system administrator shouldn't be able to tell all copies of [your app] on the network to default to saving to a network drive by default, for example... with the registry, group policies like that are easy and automatic and real-time, with.ini files it would involve sending a nasty.bat file to every computer and having it do whatever hackish edits to the.ini file that might be required.
If you want [your app] to support all the features of Windows, the registry is not only better, but necessary.
As I said in my last post, this is solely due to the fact that Microsoft decided to deprecate using files to store local information. They pretty much forced professional developers to use the Registry for this by making it a requirement for any applications that wanted to use the Windows-95 and / or Windows/NT logos, and their reasons for this were political and commercial rather than technical:
You're not talking about local information (like web cache), you're talking about configuration information. There already is a place for local information that isn't configuration: [user]/Local Settings/Application Data.
And the point above about remote administration is a technical reason for using the registry instead of.ini files.
1) The Registry makes people use installers and uninstallers instead of simply moving or deleting directories like they did with Windows 3.X.
a) Most applications used installers, from my experience, before the registry came about. b) Why is this a "political" reason? What does Microsoft get out of this? Microsoft didn't even make an installer until long after the registry came about, and I'm pretty sure their installer has always been free/almost free anyway.
2) MS can easily find out precisely what's on customers' machines.
They couldn't before by scanning the filesystem? Assuming you're paranoid enough to think Microsoft actually cares about what apps you're using. This point has nothing to do with the registry.
3) It helps lock applications into Windows by adding to the amount of Windows-specific code in them.
Ok, here you might have a valid point, if it weren't so mind-numbingly simple to abstract this away.
If the above isn't true, and Microsoft's reasons really were due to the inherent technical superiority of the Registry, then please explain how Microsoft and others have managed to write APIs for reading and writing XML (a file-based format) that have none of the limitations Chen claims as reasons for the Registry being better.
I'm not familiar enough with XML to answer that question. But I don't see how XML could possibly solve the concurrency problem-- XML files are basically just text, and have to be fully loaded and parsed by each program using them, so how do you prevent one instance from stomping over another instance's settings when it writes the XML file back out?
Plus, you still can't use group policy to restrict information in XML files, at least not in real-time.
What's really happening here is that the main feature the registry supports, group policy, you simply don't like or decree is unimportant, and therefore you just keep bringing up the same old excuses without considering that, hey, Microsoft has millions of installations on active directories with group policy!
Even worse, you probably have a customer swearing at you right now because he can't use group policy to disable your product's "annoy your coworkers" setting.
Look, if you want to make programs that run on Microsoft's OS, just follow Microsoft's rules. It'll make your work easier, it'll make Microsoft happy, and it'll make your customers happy. It's simple.
I do agree that it's harder than it should be to export registry entries for a specific application, but I'm also sick of the constant whining about how horrible and terrible the registry is. As Raymond Chen's post shows, it wasn't some random malicious implementation designed to make your life worse, it was a solution that was better in almost every way to the existing solution.
I might be sticking my foot in it, but remote desktop lets one control a remote computer via your own. That is what VNC does.
XDMCP lets you run a session hosted by a server on your own pc as if the operating system was installed on your own. The big difference between XDMCP and VNC (and Windows remote desktop as I understand it) is that with VNC the user on the remote pc needs to be logged in, and you use their programs whereas with XDMCP you can have multiple users using the same pc simultaneously and independantly from each other. A thin client network, if you will.
Look, if you know this, you are a Linux geek. Just FYI.
Secondly, you can configure Windows that way using Terminal Server, but it requires a server version of Windows and it wouldn't be something you'd expect a home user to do. So Windows does have that feature, but it's not designed for home users.
That said we do not have a dhcp host here, there might be the problem. Thanks I will be looking into it.
Then just type the IP into the Network control panel, the same way you would with OS X or Linux. I don't get how you could know XDMCP and not be able to enter an IP address into the network control panel. Also, who doesn't have DHCP (not on purpose)?
A question - do you know what XDMCP is? I am unsure from that statement if you know or not, or if the issue is my assumption.
But let us explore XDMCP for a bit. It is a way to use linux from another computer - for instance you have an office full of old P111 boxes and you buy one powerful computer to host newer software for them. Sounds complicated huh?
Well in Linux, all you do (and I am using Gnome as an example) is you go to system>administration>login_window and enable remote login.
Then you boot using a minimal linux install from a remote machine - heck you can just do a default linux install if you want - and select "remote login" from the login screen. You will be presented with the login screen of the server, username+password and PRESTO you are working via XDMCP! THAT is how easy linux is. Now try and do something like that with Windows.
Windows XP comes with Windows Remote Desktop, which can do exactly that, just as easily. So... not much of an argument there.
Well in a previous post in this thread I pointed out that I do not use MACOS often - but we have several XP boxes in the house - and getting them to use our broadband connection is a nightmare - heck networking is harder than with mu Ubuntu boxes.
Look, if you plug an ethernet cable into a Windows computer, and there's a DHCP server on the other end, it'll be on the network. Period, done. Same with OS X. I don't know what kind of crazy "nightmare" you had performing this simple operation.
Uh, what OS doesn't do that? Exactly, my point exactly. Linux makes things easy.
Well, so did Windows 95 and so did Mac OS 7. All that tells us is that Linux does the same thing other OSes have done for a dozen years.
Nothing stops me from doing scripting on Windows - except paying tons of cash to get the programs to do it in the first place. But I am not that into scripting languages.
In fact the only scripting language on Windows I think might not be free is VBA... then again, maybe it's free too, I'm not sure.
Hokay - Copy and Paste howto for the Linux NOOB. Right-Click, select copy. Open target folder, right-click, select paste. That is it for files and folders.
For text, highlight text/picture, right-click, select copy. Open target document/folder. Right-click, select paste. HEY PRESTO!
That's great. Now try copying some spreadsheet cells and pasting them into a bitmap graphics program. Or copying a few frames of a movie and embedding it into a presentation. Try dragging some text from a text editor and onto the desktop. Maybe Ubuntu has greatly improved in this area from before, but it used to have nothing close to *universal* copy&paste support among *all* applications. If I get some free time this week, I'll try putting the newest Ubuntu in a VM and see if I still had the problems I did before.
And seriously, you use right-click to select copy and paste and you're calling me a newb? Learn the keyboard shortcuts.:P
Try out QT3 Designer, by Trolltech - if you want a gui scripting language. Just a heads-up.
I'll have to look into this some more. I'd be surprised if it had the features of AppleScript, considering the general lack of coding standards and consistent APIs on the Linux platform.
My laptop does sleep mode just fine thanks, right outta the box - YMMV of course.
It didn't work on my G3 iBook. My mileage varied. Again, the difference is that sleep mode works on all laptops that Windows supports and all laptops that Apple supports, the very fact that Ubuntu's sleep mode doesn't work on all the hardware it (otherwise) supports means they need to get the basics down.
I am guessing you are really nitpicking - when last did you use a late-mark Desktop Linux Distro? Really, one moment you complain about the "Shiny 3d effects" that Linux has added, and the
stop that stupid behavior (return to farking ini files in the app directory instead of the incredibly stupid registry) and stop installing 65,000 random dll's in the system directories.
11 reasons why the registry is better than.ini files:
* 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!
* INI file security is not granular enough. Since it's just a file, any permissions you set are at the file level, not the key level. You can't say, "Anybody can modify this section, but that section can be modified only by administrators." This wasn't an issue in 16-bit Windows since 16-bit Windows didn't do security.
* 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:
Thread 1 Thread 2
Read INI file
Read INI file
Write INI file + X
Write INI file + Y
Notice that thread 2's update to the INI file accidentally deleted the change made by thread 1. This wasn't a problem in 16-bit Windows since 16-bit Windows was co-operatively multi-tasked. As long as you didn't yield the CPU between the read and the write, you were safe because nobody else could run until you yielded.
* INI files can suffer a denial of service. A program can open an INI file in exclusive mode and lock out everybody else. This is bad if the INI file was being used to hold security information, since it prevents anybody from seeing what those security settings are. This was also a problem in 16-bit Windows, but since there was no security in 16-bit Windows, a program that wanted to launch a denial of service attack on an INI file could just delete it!
* INI files contain only strings. If you wanted to store binary data, you had to encode it somehow as a string.
* Parsing an INI file is comparatively slow. Each time you read or write a value in an INI file, the file has to be loaded into memory and parsed. If you write three strings to an INI file, that INI file got loaded and parsed three times and got written out to disk three times. In 16-bit Windows, three consecutive INI file operations would result in only one parse and one write, because the operating system was co-operatively multi-tasked. When you accessed an INI file, it was parsed into memory and cached. The cache was flushed when you finally yielded CPU to another process.
* Many programs open INI files and read them directly. This means that the INI file format is locked and cannot be extended. Even if you wanted to add security to INI files, you can't. What's more, many programs that parsed INI files were buggy, so in practice you couldn't store a string longer than about 70 characters in an INI file or you'd cause some other program to crash.
* INI files are limited to 32KB in size.
* The default location for INI files was the Windows directory! This definitely was bad for Windows NT since only administrators have write permission there.
* INI files contain o
2. I am not an average user - but I am not a hardcore Linux pro either.
a) I started somewhere - I used to be an average user way back when. No one is born a pro.
b) My mom is using linux via an XDMCP client on my dad's XP box - and loving it.
You know what "XDMCP" is, and apparently just assume that we also do, that makes you a "hardcore Linux pro" in my book.
Let us go to Linux - you get pre-installed Linux boxes - fine for the "average user" - even easier to use. Plug into the network and you are online instantly, as a for instance.
Uh, what OS doesn't do that? How long has it been since you've used Windows or a Macintosh? (Actually, *all* versions of DOS-less Windows have done that.)
I just wrote my first bash program this week, check it out - the source code is on my blog. It is a horrible mish-mash of commands and stuff to do something really badly - but it is there, and it is mine.
No way that I would have grown to the point of even attempting something like that as a Windows user.
Wait, slow down a bit here.
You're arguing that since Linux *requires* people to do all kinds of nasty shit just to get it working at all, it makes you a better person because you can write BASH scripts? Is that accurate?
1) Most people, 99.9999% of people, don't measure their self-worth by knowing scripting languages. I build web-apps for a living, and I don't care... imagine how little normal people care.
2) If you do care about knowing scripting languages, what's stopping you from doing it on Windows? 2000 and XP have "whatever-you-call-CMD.exe-scripting", and yes it sucks, but it's there and it works. Windows Vista has Monad, which is significantly better. All Office versions have VBA, you can knock yourself out with that. Of course you can download Python, Ruby, Perl, etc... in short, what the hell does your choice of OS have to do with learning a scripting language? Connect some dots, please, I'm confused.
There is a perception that Linux is hard/unfriendly/a nightmare - and detractors cling to this with all they have because in reality that is all they have criticism wise.
Linux is better than it used to be, but usability-wise it's still pretty bad. Basics that other operating systems have had solved for ages (drag&drop and copy&paste of more than just text) remain unsolved in Linux. Many configuration tools in Linux really, really suck compared to the equivalent tools in OS X or Windows. Linux, ironically, is quick to add "shiny" features like 3D-accelerated desktops, but really slow to add "old standby" features like a GUI scripting language (You know, like the one Mac OS has had since version 7.0), or a sound subsystem that works 100% of the time with 100% of applications, or the ability to paste spreadsheet cells into a bitmap paint program and have it work all the time. Or laptops that can go into sleep mode.
And don't even get me started on accessibility features, or input modes. Try putting Ubuntu on a tablet PC and see how you like it! Apple has better tablet input features, and Apple doesn't even make a damned tablet. And hell, open source programs on Windows usually somehow manage to break the tablet features that every other Windows program makes use of just fine, God knows how.
The one thing that detractors of Linus tend to overlook is the underlying philosophy behind it. I was able to write my little script because the community wanted me to write it. My success as a user/contributer is important to them.
What does that have to do with usability? I don't want to write BASH scripts. I don't want to write any scripts to use my computer. And I'm much geekier than 95% of the population.
Your original comment, however, leaves me to think you are either lying for dramatic effect, or you popped in a disk, tried something out of the ordinary, and base all your assumptions on one wacky experience.
It is strange that our location in the galaxy led to a slight imbalance in the amount of gravitationally polarized light striking chunks of rock and metal floating in a cosmic dance 4 billion years before I was born...
That's great for you, but what about the rest of us?!
The people who care about encryption are not the same set of people who care about usability. Normally I'd say your best bet is to petition some company that's known for usability to add encryption support to their products, but given the Apple experience it looks like that might be pretty useless.:)
Well, yes. The real point is that Microsoft fixes problems for those people, and Apple doesn't. Therefore, Microsoft OSes typically have much better backwards-compatibility than Apple OSes.
The real lesson learned (hopefully!) if you're making any kind of programmer-facing interface, whether it be an API or an internet protocol definition, is never, ever, assume the programmer reading the spec: 1) Actually cares about implementing it correctly, as opposed to implementing it "so it works most of the time." 2) Isn't malicious.
I'm not talking about the basics, even GeOS supported those.
I'm talking about things like the integrated spell-checker, Services, drag&drop, AppleScript GUI scripting, etc. X11 on some other platform may have those features, but it definitely doesn't in OS X.
There's this thing called "usability" that Apple customers are kind of a fan of. X11 (at least on OS X) don't got it... not even remotely close to the usability of native apps. About half of OS X's usability features simply do not work in X11, and another quarter are crippled in some way.
What a lot of science fiction (and fantasy) fans miss is that, while the David Lynch movie may have left out and/or changed pieces of the book, that doesn't make it a bad movie-- it just makes it a bad adaptation.
Guess what, Disney's Hunchback of Notre Dame is a horrible adaptation of the Hugo novel, and yet it's still a pretty damned good movie. It's not that hard a concept to get, and I don't understand what a certain type of fan just simply doesn't get that those are two separate things.
(That said, you can be bad at both. For instance, the "American Godzilla" was both a terrible adaptation of the original Godzilla story, and at the same time a horrendously terrible movie. Go figure.)
Slashdot Mirror
First of all, "resort to?" You can fly from Seattle to Philadephia in 5 hours, and we have to "resort to" that speed? The fact that only two generations ago, the majority of people spent their entire lives never leaving their own state, and now virtually everybody on Earth has visited a different continent? How about a little teeny bit of appreciation for the modern age, huh?
"Resort to" my ass, you should be forced to drive a team of horses to work for the next week as punishment.
But if you want a list:
1) Fuel consumption. Supersonic aircraft suck down the gas at an alarming rate, leading to...
2) Crappy economic performance. A typical Concorde sucked down something like one and a half times the fuel of a typical 747 on the same route. Meanwhile, the 747 is carrying 300 passengers while the Concorde is struggling to cram 100 in. It would be hard to find a less economical option than supersonic flight. (IIRC, even with the stupid-high ticket prices, the Concorde business was operated at a loss.)
3) Sonic booms, leading to...
4) Being banned over many, many states and municipalities. There's a reason the Concorde pretty much only crossed oceans, there's nobody on the ocean to bother with your noise.
There's also issues of pilot training, safety features, pollution, etc. The runway strike that took down that Concorde in France would probably have been survivable by almost any other aircraft at that airport. You build high performance, super-precision machines and they get delicate. And that thick black smoke that comes out the back-end of the Concorde wasn't made of sunshine and butterflies. But reasons 1 and 2 are more than enough for airlines.
The A-380 and 777 are good buys because they have the high passenger capacity and much lower fuel consumption when compared to the 747, due to only feeding two engines instead of four. Even a supersonic built with everything we've learned from military jets and everything we've learned from Concorde wouldn't even remotely come close.
I understand the joke but, to be fair, it was the guy's name. http://en.wikipedia.org/wiki/William_Edward_Boeing
The biggest problem is the the US Government should have blocked the Boeing / Mc Donald Douglas merger.
They just couldn't compete with the free Big Macs and fries during every DC-9 flight! They had to take action!!
Those American MD-80s seem to be flying just fine despite "acid rain" and "airborne sand". Of all the explanations of things that can take down aircraft, you picked the two most ridiculous by a large margin.
How about fatigue? That one is really hard to identify in aging planes, has taken down several flights in the past, and use of new materials can lead to entirely different fatigue problems.
That said, I'd trust Boeing with my life over any other company out there.
It's kind of funny now remembering how Boeing were crowing over the A380 problems,
[citation needed]
I actually remember a few statements from Boeing officials acknowledging how difficult producing a new model of airliner is, after Airbus announced A-380 delays. Boeing got some contracts, but I hardly believe they were "crowing" over the delays. There is such a thing as good-natured competition, and Boeing and Airbus definitely have it.
I agree that this case is stupid, but there are a lot of people making a lot of money blogging in this day and age, so it's very well possible that her blog is pulling in enough advertising income to be taxable. (Given the subject matter of the blog, I doubt it. But I can't be sure.)
Try it with HP. It took more than an hour, and something like 4-5 reboots, to get a working computer on my HP tablet. But, and here's the problem, *all* of that delay was due to HP crapware installed on it.
I grabbed the Vista Home Premium DVD that came with my Dell desktop (say what you want about Dell, but at least they give you the *actual* OS disk and not a disk loaded with crapware), installed it on the tablet and booted it again. Less than 2 minutes. In fact, the entire OS install was quicker than just booting HP's pre-installed image.
I've learned my lesson: Never buy from HP. I'll stick with Dell; my Dell had maybe 3 pieces of crapware, all easily-removed, and they gave me an actual OS disk. HP, I paid an extra $20 for the disk (they suckered me) and it turns out it's a disk full of crapware. I don't get how HP customers stand for this, they should revolt with the way they're being treated.
The Xbox, Xbox 360 and Zune are all pretty damned good products.
What's your exact complaint about these systems? Even if you hate the Xbox and Zune, are you seriously saying that the Xbox 360 is a bad game console?
I've always thought that Microsoft Hardware generally comes out much better than their software products, I think due to the increased competition in the hardware area. Microsoft knows they can't rest on their laurels and let Sony invent an online gaming system, so they come up with Xbox Live and blow them (and Nintendo) out of the water.
If you're not following the OS recommendations, and doing stuff not recommended by the OS maker, for instance:
Your application *will* break when a future version of the OS comes out. I'm not saying "may", I'm saying "will." If you actually tried to write configuration information in the same directory as the application, your program is broken in Vista. (And for all multi-user computers in NT4, Windows 2000, Windows XP.)
.INI files, in favor of the Registry instead."
.ini files should now go in the Registry instead. That is the only sane way that sentence can be interpreted. You were implying that the recommendation was that *all* application-specific data should go into the registry.
Manifests go there because they never change. At least not until the application is patched or upgraded, which requires admin permissions anyway. Configuration information could potentially change daily.
Quote: "So for Windows 95, Microsoft advised its supporting manufacturers that applications that qualify for the Windows 95 logo should disavow any use of
That quote obviously means information that previously went in
2) Locks only apply while a key is open, and Microsoft's programming guidelines say they shouldn't be left open for long periods to minimise the possibility of corruption occurring. So it's actually the software that MS would define as being correctly written which will have problems with multiple instances overwriting each others' data.
Yes and no. Another difference is that the registry is finer-grained... with XML/INI/whatever other format you use, the lock extends to the entire file, so if one instance has it locked, another instance is out of luck. With the registry, the instance can lock only what it needs at the moment, and the other instance can still access everything else.
You are either being deliberately obtuse, or you really don't know why your reply was stupid. I hope for your sake that the former is true.
I'm trying to figure out why one file would be more or less prone to being corrupted than another file. I'm not being obtuse, I'm trying to figure out exactly what your argument against the registry is... it's a file, so it can be corrupted? Well... ok. So's everything else, what's your point?
How long does a batch file take to run? If you can give a general answer that doesn't boil down to "it depends what it's doing", then this is yet another one of your utterly meaningless answers.
It takes a fraction of a second to do the type of tasks we're arguing about. But that's not the point.
The point is that if you do it with a batch file, you can only make the change at login. If you do it via group policy, the change will be updated in 60-120 minutes. If a user never logs out, the batch file never runs and the change is never made. Using group policy and the registry doesn't have that problem.
I only log out my work computer on weekends, most nights I just lock it and leave.
What I disagree with is the idea that every value any application ever stores should be put in the same central repository as critical system settings that can render a system unbootable if they're changed.
Wow, an actual point. Except that it only applies for software run as administrator, other software doesn't have permissions to stomp on the Local Machine registry entries. In a corporate environment, that's "good enough", but at home it's a problem since a lot of home users always run as administrator. Microsoft's customers are corporations.
Hence the fact that so much application-specific data is stored in the Registry as undocumented groups of numbers with meaningful names such as "Hrrlh99_07014". The people who wrote that software were obviously thinking "Hey, this private stuff may well be used to set group policies in a corporate network, so we'll support that by using names and data formats that don't make sense to anyone else for our Registry entries, and give further assistance by working hard to ensure that we don't let customers know anything about what it's used for and how it's laid out".
.ini file can easily be undocumented also, so the registry isn't any worse-off than the alternative in this case.
/Windows probably.) It was, however, in place for Windows NT.
.dlls in whatever random directories you wanted and simply link to them... a naive copy of the applications would fail to find the libraries and not start. Plus, Mac OS didn't have anything remotely equivalent to the registry until OS X came out, and Mac software developers never seemed to have a problem making copy protection work. (And OS X doesn't use it's registry-type database for configuration information-- it stores it in XML files instead.)
If software makers don't document their registry keys, how is that Microsoft's fault? Look, Microsoft provides the framework, they can't police every single program to make sure that every single program is using the framework exactly as Microsoft planned it to be used-- and if they tried, imagine the cry of agony from the Linux crowd here at Slashdot.
In addition to all that, there's also the point that the
This is a non-argument and has nothing to do with the benefits of the registry.
I'm talking about _any_ information applications store during installation, updating, or between sessions that's not meant to be read or modified by either products from other vendors, or end users.
Well, first of all, configuration information is meant to be "read or modified" by products from other vendors and end users. The product from other vendors being tools like group policies, and the end users being people who select Tools->Options.
In fact, by your definition, the AppData directory is exactly where you should put that data, since it's data the that (by your own definition) isn't meant to be modified by other vendors or end users. But that's not what normal people think of when they hear the word "configuration". The AppData directory is even nicely designed so that you can separate information that should follow the user (i.e. browser bookmarks) from data that should stay on a single computer (i.e. browser cache.)
You obviously didn't read the paragraph you're replying to, because that particular structure was not part of Windows/NT 4.X or Windows-95 when MS required local data to be stored in the Registry for Windows logo compliance.
First of all, I'm pretty sure Microsoft never required local data to be stored in the registry. The registry is, and always has been, for configuration only. Are you seriously suggesting that IE4 stored (or should have stored) the browser cache in the registry? That's ridiculous.
Secondly, that structure was not in place for Windows 95, although if you asked for the "Application Support" directory in Windows 95, Windows would return some location. (Not sure exactly where... somewhere in
They gain the ability to prevent non-technical people from cloning installed applications by the simple expedient of copying directory structures to media or across a network.
I'm pretty sure they could have done that before. At least in Windows 95, where you could barf
If Microsoft don't care what apps people use, then why do they have schemes like Windows Genuine Advantage and Office Genuine Advantage?
Ok; fine. I correct my statement to read "Microsoft doesn't care what apps people use, other than to ensure they paid for Microsoft apps that ar
Even in high school, we have a civics teacher who taught us a lot about the world with Civilization (the original board game the computer game is based on, although he had the computer game available also.) And when I left high school, I spent a summer with a group playing games like Diplomacy, Axis and Allies, Shogun, etc. They're obviously not for everybody, but you learn a lot about how the real world works by playing Diplomacy. Especially when you get stabbed in the back by all the other players, and die in a single turn. :)
What's the problem? 300 people connect to the BBC and stream Benny Hill. Those 300 streams take X amount of bandwidth, once for every subscriber, and 300 times for the BBC.
Each subscriber pays for his little tube, and the BBC pays for it's tube big enough to carry 300 Benny Hill streams.
So what's the problem?
That 300 people are watching Benny Hill?
but the fact that I and many, many other developers don't think that a centralised global repository is an appropriate place for storing persistent information which is only relevant to the application that wrote it, or other applications by the same vendor.
.ini files it would involve sending a nasty .bat file to every computer and having it do whatever hackish edits to the .ini file that might be required.
.ini files.
Well, part of the point is that it is relevant for corporate networks using active directory and group policies. There's no reason a system administrator shouldn't be able to tell all copies of [your app] on the network to default to saving to a network drive by default, for example... with the registry, group policies like that are easy and automatic and real-time, with
If you want [your app] to support all the features of Windows, the registry is not only better, but necessary.
As I said in my last post, this is solely due to the fact that Microsoft decided to deprecate using files to store local information. They pretty much forced professional developers to use the Registry for this by making it a requirement for any applications that wanted to use the Windows-95 and / or Windows/NT logos, and their reasons for this were political and commercial rather than technical:
You're not talking about local information (like web cache), you're talking about configuration information. There already is a place for local information that isn't configuration: [user]/Local Settings/Application Data.
And the point above about remote administration is a technical reason for using the registry instead of
1) The Registry makes people use installers and uninstallers instead of simply moving or deleting directories like they did with Windows 3.X.
a) Most applications used installers, from my experience, before the registry came about.
b) Why is this a "political" reason? What does Microsoft get out of this? Microsoft didn't even make an installer until long after the registry came about, and I'm pretty sure their installer has always been free/almost free anyway.
2) MS can easily find out precisely what's on customers' machines.
They couldn't before by scanning the filesystem? Assuming you're paranoid enough to think Microsoft actually cares about what apps you're using. This point has nothing to do with the registry.
3) It helps lock applications into Windows by adding to the amount of Windows-specific code in them.
Ok, here you might have a valid point, if it weren't so mind-numbingly simple to abstract this away.
If the above isn't true, and Microsoft's reasons really were due to the inherent technical superiority of the Registry, then please explain how Microsoft and others have managed to write APIs for reading and writing XML (a file-based format) that have none of the limitations Chen claims as reasons for the Registry being better.
I'm not familiar enough with XML to answer that question. But I don't see how XML could possibly solve the concurrency problem-- XML files are basically just text, and have to be fully loaded and parsed by each program using them, so how do you prevent one instance from stomping over another instance's settings when it writes the XML file back out?
Plus, you still can't use group policy to restrict information in XML files, at least not in real-time.
What's really happening here is that the main feature the registry supports, group policy, you simply don't like or decree is unimportant, and therefore you just keep bringing up the same old excuses without considering that, hey, Microsoft has millions of installations on active directories with group policy!
Even worse, you probably have a customer swearing at you right now because he can't use group policy to disable your product's "annoy your coworkers" setting.
Look, if you want to make programs that run on Microsoft's OS, just follow Microsoft's rules. It'll make your work easier, it'll make Microsoft happy, and it'll make your customers happy. It's simple.
I do agree that it's harder than it should be to export registry entries for a specific application, but I'm also sick of the constant whining about how horrible and terrible the registry is. As Raymond Chen's post shows, it wasn't some random malicious implementation designed to make your life worse, it was a solution that was better in almost every way to the existing solution.
No no. XDMCP is a lot different, than remote desktop - remote desktop is more like VNC
http://en.wikipedia.org/wiki/Xdmcp
for XDMCP.
I might be sticking my foot in it, but remote desktop lets one control a remote computer via your own. That is what VNC does.
XDMCP lets you run a session hosted by a server on your own pc as if the operating system was installed on your own. The big difference between XDMCP and VNC (and Windows remote desktop as I understand it) is that with VNC the user on the remote pc needs to be logged in, and you use their programs whereas with XDMCP you can have multiple users using the same pc simultaneously and independantly from each other. A thin client network, if you will.
Look, if you know this, you are a Linux geek. Just FYI.
Secondly, you can configure Windows that way using Terminal Server, but it requires a server version of Windows and it wouldn't be something you'd expect a home user to do. So Windows does have that feature, but it's not designed for home users.
That said we do not have a dhcp host here, there might be the problem. Thanks I will be looking into it.
Then just type the IP into the Network control panel, the same way you would with OS X or Linux. I don't get how you could know XDMCP and not be able to enter an IP address into the network control panel. Also, who doesn't have DHCP (not on purpose)?
A question - do you know what XDMCP is? I am unsure from that statement if you know or not, or if the issue is my assumption.
:P
But let us explore XDMCP for a bit. It is a way to use linux from another computer - for instance you have an office full of old P111 boxes and you buy one powerful computer to host newer software for them. Sounds complicated huh?
Well in Linux, all you do (and I am using Gnome as an example) is you go to system>administration>login_window and enable remote login.
Then you boot using a minimal linux install from a remote machine - heck you can just do a default linux install if you want - and select "remote login" from the login screen. You will be presented with the login screen of the server, username+password and PRESTO you are working via XDMCP! THAT is how easy linux is. Now try and do something like that with Windows.
Windows XP comes with Windows Remote Desktop, which can do exactly that, just as easily. So... not much of an argument there.
Well in a previous post in this thread I pointed out that I do not use MACOS often - but we have several XP boxes in the house - and getting them to use our broadband connection is a nightmare - heck networking is harder than with mu Ubuntu boxes.
Look, if you plug an ethernet cable into a Windows computer, and there's a DHCP server on the other end, it'll be on the network. Period, done. Same with OS X. I don't know what kind of crazy "nightmare" you had performing this simple operation.
Uh, what OS doesn't do that?
Exactly, my point exactly. Linux makes things easy.
Well, so did Windows 95 and so did Mac OS 7. All that tells us is that Linux does the same thing other OSes have done for a dozen years.
Nothing stops me from doing scripting on Windows - except paying tons of cash to get the programs to do it in the first place. But I am not that into scripting languages.
Uh, CMD... free. Monad... free. Python... free. Ruby... free. PHP... free. Perl... free.
In fact the only scripting language on Windows I think might not be free is VBA... then again, maybe it's free too, I'm not sure.
Hokay - Copy and Paste howto for the Linux NOOB. Right-Click, select copy. Open target folder, right-click, select paste. That is it for files and folders.
For text, highlight text/picture, right-click, select copy. Open target document/folder. Right-click, select paste. HEY PRESTO!
That's great. Now try copying some spreadsheet cells and pasting them into a bitmap graphics program. Or copying a few frames of a movie and embedding it into a presentation. Try dragging some text from a text editor and onto the desktop. Maybe Ubuntu has greatly improved in this area from before, but it used to have nothing close to *universal* copy&paste support among *all* applications. If I get some free time this week, I'll try putting the newest Ubuntu in a VM and see if I still had the problems I did before.
And seriously, you use right-click to select copy and paste and you're calling me a newb? Learn the keyboard shortcuts.
Try out QT3 Designer, by Trolltech - if you want a gui scripting language. Just a heads-up.
I'll have to look into this some more. I'd be surprised if it had the features of AppleScript, considering the general lack of coding standards and consistent APIs on the Linux platform.
My laptop does sleep mode just fine thanks, right outta the box - YMMV of course.
It didn't work on my G3 iBook. My mileage varied. Again, the difference is that sleep mode works on all laptops that Windows supports and all laptops that Apple supports, the very fact that Ubuntu's sleep mode doesn't work on all the hardware it (otherwise) supports means they need to get the basics down.
I am guessing you are really nitpicking - when last did you use a late-mark Desktop Linux Distro? Really, one moment you complain about the "Shiny 3d effects" that Linux has added, and the
11 reasons why the registry is better than
http://blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx
2. I am not an average user - but I am not a hardcore Linux pro either.
a) I started somewhere - I used to be an average user way back when. No one is born a pro.
b) My mom is using linux via an XDMCP client on my dad's XP box - and loving it.
You know what "XDMCP" is, and apparently just assume that we also do, that makes you a "hardcore Linux pro" in my book.
Let us go to Linux - you get pre-installed Linux boxes - fine for the "average user" - even easier to use. Plug into the network and you are online instantly, as a for instance.
Uh, what OS doesn't do that? How long has it been since you've used Windows or a Macintosh? (Actually, *all* versions of DOS-less Windows have done that.)
I just wrote my first bash program this week, check it out - the source code is on my blog. It is a horrible mish-mash of commands and stuff to do something really badly - but it is there, and it is mine.
No way that I would have grown to the point of even attempting something like that as a Windows user.
Wait, slow down a bit here.
You're arguing that since Linux *requires* people to do all kinds of nasty shit just to get it working at all, it makes you a better person because you can write BASH scripts? Is that accurate?
1) Most people, 99.9999% of people, don't measure their self-worth by knowing scripting languages. I build web-apps for a living, and I don't care... imagine how little normal people care.
2) If you do care about knowing scripting languages, what's stopping you from doing it on Windows? 2000 and XP have "whatever-you-call-CMD.exe-scripting", and yes it sucks, but it's there and it works. Windows Vista has Monad, which is significantly better. All Office versions have VBA, you can knock yourself out with that. Of course you can download Python, Ruby, Perl, etc... in short, what the hell does your choice of OS have to do with learning a scripting language? Connect some dots, please, I'm confused.
There is a perception that Linux is hard/unfriendly/a nightmare - and detractors cling to this with all they have because in reality that is all they have criticism wise.
Linux is better than it used to be, but usability-wise it's still pretty bad. Basics that other operating systems have had solved for ages (drag&drop and copy&paste of more than just text) remain unsolved in Linux. Many configuration tools in Linux really, really suck compared to the equivalent tools in OS X or Windows. Linux, ironically, is quick to add "shiny" features like 3D-accelerated desktops, but really slow to add "old standby" features like a GUI scripting language (You know, like the one Mac OS has had since version 7.0), or a sound subsystem that works 100% of the time with 100% of applications, or the ability to paste spreadsheet cells into a bitmap paint program and have it work all the time. Or laptops that can go into sleep mode.
And don't even get me started on accessibility features, or input modes. Try putting Ubuntu on a tablet PC and see how you like it! Apple has better tablet input features, and Apple doesn't even make a damned tablet. And hell, open source programs on Windows usually somehow manage to break the tablet features that every other Windows program makes use of just fine, God knows how.
The one thing that detractors of Linus tend to overlook is the underlying philosophy behind it. I was able to write my little script because the community wanted me to write it. My success as a user/contributer is important to them.
What does that have to do with usability? I don't want to write BASH scripts. I don't want to write any scripts to use my computer. And I'm much geekier than 95% of the population.
Your original comment, however, leaves me to think you are either lying for dramatic effect, or you popped in a disk, tried something out of the ordinary, and base all your assumptions on one wacky experience.
Most of getting to use Linux is gettin
It is strange that our location in the galaxy led to a slight imbalance in the amount of gravitationally polarized light striking chunks of rock and metal floating in a cosmic dance 4 billion years before I was born...
That's great for you, but what about the rest of us?!
The people who care about encryption are not the same set of people who care about usability. Normally I'd say your best bet is to petition some company that's known for usability to add encryption support to their products, but given the Apple experience it looks like that might be pretty useless. :)
Look at this example, too:
http://rgov.org/college-media-advisers-08
Well, yes. The real point is that Microsoft fixes problems for those people, and Apple doesn't. Therefore, Microsoft OSes typically have much better backwards-compatibility than Apple OSes.
The real lesson learned (hopefully!) if you're making any kind of programmer-facing interface, whether it be an API or an internet protocol definition, is never, ever, assume the programmer reading the spec:
1) Actually cares about implementing it correctly, as opposed to implementing it "so it works most of the time."
2) Isn't malicious.
I'm not talking about the basics, even GeOS supported those.
I'm talking about things like the integrated spell-checker, Services, drag&drop, AppleScript GUI scripting, etc. X11 on some other platform may have those features, but it definitely doesn't in OS X.
There's this thing called "usability" that Apple customers are kind of a fan of. X11 (at least on OS X) don't got it... not even remotely close to the usability of native apps. About half of OS X's usability features simply do not work in X11, and another quarter are crippled in some way.
So, no, porting to X11 is not a good move.
What a lot of science fiction (and fantasy) fans miss is that, while the David Lynch movie may have left out and/or changed pieces of the book, that doesn't make it a bad movie-- it just makes it a bad adaptation.
Guess what, Disney's Hunchback of Notre Dame is a horrible adaptation of the Hugo novel, and yet it's still a pretty damned good movie. It's not that hard a concept to get, and I don't understand what a certain type of fan just simply doesn't get that those are two separate things.
(That said, you can be bad at both. For instance, the "American Godzilla" was both a terrible adaptation of the original Godzilla story, and at the same time a horrendously terrible movie. Go figure.)