Some people say there is no similar market effect. I think there is. Car sound installations. While there is a high-tech market for after market sound systems for your car it is tiny compared to the pre-installed market.
Is it really that similar, though? Perhaps it's different in the USA, but many cars I've seen are assembled away from the factory. Smaller components such as stereos tend to vary a lot depending on the location where the vehicle was assembled -- they're certainly not provided by or branded by the car maker.
I would have thought this was a standard market where smaller car stereo makers could negotiate with the car assemblers to get their product included. Clearly the end customer has less choice (unless they rip it out and change it afterwards), but it's not so much a case of locking out competitors.
This is so I can code an app using this new API and it will run and look good on both KDE and GTK systems.
Having an application that will run nicely in both desktops is appealing in itself, but aren't the respective API's for Gnome and KDE (which are quite different) one of the great incentives for developers? If this new API is going to appeal to lots of (all?) developers, it would need to somehow appeal to both camps, and given their significant fundamental differences in coding styles, that might be difficult.
Personally I don't think that a.xxx domain will be especially useful or beneficial, unless its part of a radical move such as opening up all possible TLD's. I also think it could quite possibly lead to undesirable things such as governments trying to implement legislation around its existance.
That said, what bothers me about this has nothing to do with the fact that it's being blocked -- it's the way that it's being blocked. There's a clear process available to be followed for deciding this, but several governments have decided that they're too important to be dictated to by that process, and are overriding it. It doesn't exactly set a good precedent for representative users of the 'net and the DNS to determine things themselves.
First M$ creates an entire industry focused around fixing holes in their OS. Now they are threatening to fix their own holes and that industry is mad at them?
I find it hard to understand that companies such as Symantec and McAfee apparently haven't had a strategy prepared for this eventuality. If you've built a business on Microsoft's incompetence, then surely you'd have to expect that sooner or later Microsoft's competence would either improve, or Microsoft would go out of business, taking with it any businesses that leech off its existance.
If they truly haven't been prepared for this, they deserve to become obsolete.
Just what the world needs: another techno-crutch that will absolve parents of the annoyance of actual parenting. Let's not talk to kids about the effects of loud noises on their hearing - that's too difficult. Instead, let's be passive-aggressive pricks and preempt their judgment with parental-surrogate crippleware.
I don't see why this is a problem, as long as parents use it sensibly and with the knowledge that it's not failsafe. It's a safety device. Giving parents an ability to control it is even better simply because a lot of children don't yet have the cognitive development, understanding or experience necessary to properly decide what volume level is safe for them.
How is this different from childlocks on car doors, grills in front of fireplaces, bars around children's beds (ie. cots), and a variety of other devices designed to help parents prevent their kids from getting into trouble?
If I was a parent with my own iPod, I'd probably consider setting this simply to cover those situations where the kids might want to borrow it. Sure they can amplify it, but chances are that they won't, and I'd be working on educating them at the same time. It's hardly the same as a parent using a TV as a babysitter and ignoring their child's existance, unless they choose to use it as such.
I'll readily admit that I don't much like Microsoft or their software, but they must be commended upon their due diligence on this one aspect. A lot of software from Windows 3.0 can still run on XP.
This is true for the most part, but personally I've also felt that the problems with maintaining backward compatibility have been a result of Microsoft's decision to produce closed source software, and to encourage other developers and businesses to copy their model. (ie. Hide your source so people can't read it, charge people to install and continue using your software, and don't let anyone use or improve on your code.)
With closed source software applications, any or all of the following are typically necessary when the OS is upgraded:
Pay for any software application upgrades.
Rely on a third party vendor to still exist to create new versions.
Rely on a third party vendor to support software upgrades.
Rely on the OS vendor to support old versions of an un-told number of applications.
In essence, every time Microsoft changes Windows, its customers either have to rely on Windows having backward compatibility, or they have to rely on the vendors of all their software... even if the underlying API changes have been trivial. There's also a single point of failure because if the vendor doesn't fix any problems properly, there's no opportunity for anyone else to do it better.
Compare this with open source software, where even though the OS API's tend to be a little more stable, it's still quite straightforward to upgrade to new versions of software when the API's do change. If the vendor of an OSS product doesn't do it quickly enough, and their product is popular enough, chances are that someone's at least going to produce a patch. There's rarely such a thing as a vendor going out of business and causing major problems, because at someone else is likely to pick it up if enough people use it, or provide an easy-to-implement alternative that'll simply read data from the original app's open formats.
I'm definitely not trying to claim that open source is superior to closed source for everyone, and I doubt Microsoft could have been such a commercially successful company if it'd built itself on open source software. Having said so, though, I think the backward compatibility issues are a direct result of Microsoft promoting closed source software. It's not something that's even a consideration with open source users for the most part, and Windows wouldn't have to be anywhere near as backward compatible if it was easier to adjust and upgrade the applications that run on it.
I don't disagree with you that OpenOffice is great to have, simply because it gives many people a drop-in alternative to Microsoft Office, and I even said as such in my earlier post. As for this:
And no one owns 64bit chips yet, so who cares? I'm talking worldwide, of course. Anyone who currently has a 64 bit chip already has an old 32 bit chip computer and/or the money to get one.
The 64-bit compilation issue was really only intended to be a demonstration of my point, which is that the OpenOffice code is too stagnant and encumbered to be able to make any radical changes. Sooner or later, things will probably change around OpenOffice too quickly for it to keep up. If it's not CPU architectures that change, it'll be radical changes in standard GUI widgets or file system design, or something else that challenges the static legacy design decisions of OpenOffice. And yes, of course people will still be able to use OpenOffice to do everything they need to do, as long as they keep a legacy OS or window manager or old un-supported worn-out hardware that's separate from their regular hardware, and as long as they're happy with OpenOffice acting inconsistently with everything else they use, or whatever, because sooner or later it probably won't be able to be easily changed to keep up.
In the Microsoft world, MS Office will either adapt (because Microsoft can afford to throw huge amounts of money at the problem), or other products more suitable to the changes will move in to replace the existing Office suite. OpenOffice, however, isn't exactly a long term solution to anything, and I think it's misleading to suggest that it's a perfect solution to replacing MS Office. Right now, as porkThreeWays put it in a separate response to my earlier post, OpenOffice is a transition tool, but it's not likely to be a long term tool. But a transition to what? A system that relies on OpenOffice as its main Office tool?
Re:My main problems with OpenOffice (on any OS)
on
Office Delayed, Too
·
· Score: 1
I don't know about Sun being responsible for the mess, I think that'd be more StarDivision's fault. StarOffice goes back at least 10 years.
BUT... We barely even look at Office 2003 either. The only useful part about that one is that I think Outlook 2003 has vastly improved design against worms and spam.
I mean... Come on. What features do people need from Office 2007!?
Well, since you mentioned Outlook, I can think of at least two things from the point of view of someone who's had to write Outlook addins. (Even worse, in inheriting the maintenance of other people's Outlook addins.)
I'd like Outlook to have a consistent API for writing addins that's native to.Net (or anything else that has decent garbage collection), and where it's not necessary to directly interface with COM objects to get things done. It seems a bit ridiculous that 5 years after Microsoft released and started pushing its new Microsoft's own applications that were released several years afterwards!
I'd consider settling without that if Microsoft would simply fix the bugs that seem to be preventing some Outlook event handlers from firing when they're supposed to. (Specifically in our case, the Inspector.Close event doesn't fire reliably, and there's nowhere else to cleanly put the clean-up code that goes and deallocates the COM objects.)
Irrespective of the interface, Outlook 2003 is buggy, and many people who've had to integrate it with anything will know this very well. If Microsoft could just make it stable, not to mention having it run addins in sandboxes so that malfunctioning addins can't make an entire desktop unstable, I'd be happy.
My main problems with OpenOffice (on any OS)
on
Office Delayed, Too
·
· Score: 5, Interesting
OpenOffice might not have all the features of Microsoft Office but I don't care because I'll never use them. Moreover, nobody is going to take away the download for OpenOffice 2 and decide we need a shiny new version.
That said, what are the chances of OpenOffice.Org actually improving radically? As much as I admire the people who put effort into improving it, the project gives me the impression of something like Netscape 4, which was like the engine of Netscape 3 with lots of band-aid features stuck over its face that made it act slower, inconsistent with itself, unstable, and generally buggy. Correct me if I'm wrong, but it feels like there's so much legacy code and design in OpenOffice that it's difficult to implement important changes. In essence, and I'd be happy to be proved wrong, it seems like a big ancient application built on legacy design that's only going downhill and will inevitably be overtaken by others if it hasn't been already.
I've been put off OpenOffice for some time now because it won't (cleanly) compile as a native 64 bit application. I was looking forward to the 2.0 release because I'd been led to believe that the incompatibilities were being ironed out specifically for that release, and then it would compile as a 64 bit application, but on release that unfortunately wasn't the case. Searching further, I discovered that the OpenOffice code was apparently still so messy from the Sun days that it simply hadn't been feasible to port to a 64 bit app in any reliable way, and probably wouldn't be for a long time to come.
If OpenOffice had nice and easy-to-maintain code, I would have thought that a 64-bit build would have been as easy as a recompile -- perhaps with a couple of unforseen bug-fixes here and there. The problem is that something as basic as native 64-bit compilation is yet another thing that was never in the original design brief, and trying to patch it in later is a horrible task. I'm not an OpenOffice.Org developer, so if someone knows otherwise about this I'm keen to know.
OpenOffice is convenient to have right now because it provides an 80% replacement for a lot of what MS Office does. Many people looking to switch might be able to use it as a drop-in replacement if their requirements aren't too complex. It's still a mammoth and heavily complex system with considerably dead weight, though, and unfortunately it's not particularly bug free.
Personally, I've found it much easier to go with the more light-weight open source office apps, which aren't trying to be mammoth applications. Lately I've been using the likes of AbiWord, KWord, Gnumeric, and so on, and I've found them to be much more responsive, integrated with my system, and generally more stable than either OpenOffice or MS Office would be. (Actually I can't test MS Office on my system because it's not Windows, so I'm comparing it with MS Office on a typical Windows system.)
The lighter-weight open source apps don't do as much as OpenOffice or MS Office, but they do enough to keep me satisfied. Unfortunately this isn't an option for most people who are locked into Microsoft Office for things like specialised code and plugins and various desktop integration stuff, but then neither is OpenOffice. eg. Supporting something like OpenOffice at my current work is completely out of the question, simply because it won't integrate with our document management systems, despite ODMA (Open Document Management API) being an open API that's existed for ages and is supported by the bulk of DMS products. (MS Office doesn't cleanly support ODMA either, but it's popular enough that it gets special attention from the DMS vendors.)
It might be that I wasn't clear enough, and it's also that you seem to have misunderstood me to some extent. If this was the case then please accept my apologies.
If you live in San Francisco, then you should know that the 1989 quake, as did the 1906 quake, resulted in some significant changes to building regulations, including highway bridge regulations, after it was noticed that several standard precautions already known about hadn't been implemented properly or effectively. If you live there, you're already paying extra to live in buildings of a higher standard than you might live in elsewhere. Also as much as they demand attention for preparation, earthquakes simply don't occur as often as severe storms. I also live in an Earthquake risk zone, and I pay extra for it too. Will my government bail us out if an Earthquake strikes? Sure, at least I hope so, but the chances of that actually happening are still considerably average over the next several hundred years. We might be hit tommorrow, or not for a thousand years. Like you, we also pay our way, and I'd like to think that a bailout cost every few hundred years would be insignificant compared with the economic return of being here.
It's completely true that sometimes there are very good reasons for living in dangerous places, especially when it's economic to do so. Maybe there's a big and very accessible harbour there, for instance. Alternatively, volcanic ash that surrounds volcanoes is great for producing crops efficiently. I'm not trying to suggest that people shouldn't be allowed to live in dangerous places across the board, or that a fence should be put up to stop people visiting on the off-chance that a disaster will strike. (For hurricanes it's not too difficult to predict their impact in a reasonable time, anyway.) But I think there should definitely be some restrictions on building in the places that are obviously most at risk, and likely to be subject to natural disasters again and again.
But come on, the coast of New Orleans is going to be hammered by big hurricanes over and over again from now on. The only difference between now and 50 years ago is the recent 50 year lapse in the standard weather pattern. During this time people became complacent and started building in places where they really shouldn't have built. Now that the pattern's resuming and they've finally been hit again, the response isn't to say "Oops, we shouldn't have done that.. we'd better pull back to where we were". On the contrary, the response is to spend billions of dollars trying to devise ways to let people continue living in places below sea level that will be repeatedly exposed to severe hurricanes, and that people never would have wanted to live in if they hadn't had an opportunity to establish themselves during an inconsistent patch of climatic conditions. To top it off, the methods being devised are probably not going to work with any certainty or effectiveness, and the area will continue to be a sink for other people's money that could otherwise be spent on much more useful things -- or alternatively given back to them if you happen to think that way.
Really, to be honest, New Orleans is in the US and I'm not deeply concerned about how you choose to run your internal affairs except when they have spinoffs that affect me. If you want to spend billions of dollars on subsidising people's poor choices of living locality, by all means do so and who am I to argue? It's not even my money. I do find it quite perpelexing to look at, though.
Locally, in New Zealand, I am concerned, because the places that cost the most to bail out of disasters are the small coastal towns that are demonstrably in locations subject to severe conditions (between their attractive sunshine). These places don't provide a lot of tax anyway. With a few exceptions, they tend to be full of people living there in retiremen
Now permit me to be cruel: I don't believe that New Orleans should be rebuilt. If the flood areas are subject to destruction as a result of broken levees and strong hurricanes can break the levees, then we are creating a cycle of destruction and rebuilding.
Thanks for stating this -- as far as I'm concerned, there are a lot of places where people simply shouldn't be living. As I understand it (I'm not from the area so correct me if I'm wrong), New Orleans used to get lots of hurricanes similar to Katrina, and there's simply been a remisssion for about 50 years. People became complacent during that time, property near the coast was subdivided, and everyone flocked to it. 50 years later big storms are back. Apparently the solution isn't to move away -- it's to spend tens or hundreds of billions of dollars rebuilding?? Trying to protect a region below sea level?? There are some things that are just ridiculous.
As far as I'm concerned, people whose homes and properties are wiped out like this should be given a chance where appropriate. I live in New Zealand, and while not on as-large-a-scale as some disasters in the US, we do have several places that have been wiped out by serious weather events.
These disasters have resulted in substantial amounts of money that, essentially, comes out of my taxes. I don't mind this the first time, but bailing people out over and over again just because they like to live in a place that's clearly vulnerable to forces of nature seems silly.
We also have plenty of examples of disasters-in-waiting, which are simply being ignored. One of them, for instance, is an expected Tsunami to hit Kaikoura in the near future. There's an underwater landslide down the coast that's just waiting to happen, and almost certainly will cause the place to be at serious risk. The attitude of the locals is to ignore the risk, claim that they'll get through it like any other day, and keep on living there.
I really do sympathise with people who are living in places like this, especially if they have roots there but I also think that governments should be making it very clear about significant danger zones, and if appropriate, preventing people from living in them. I'm tempted to say that people should be allowed to live in such places at their own risk, but I don't think it's realistic to expect that help won't be offered if it's needed. I also think that such a policy would victimise poor people, by making those areas much much cheaper to live in (as well as other areas more expensive).
If that's what you want, I'd honestly suggest starting with something like Knoppix. That way, you can even cut out step 2. It'll also give you a chance to decide if you want to use Linux in the longer term. Knoppix lets you install it on a HDD to avoid needing a boot CD if that's what you want, but if you're serious you might then decide to install something like Debian or Ubantu over the top.
Installation might be a hiccup, but you only have to do it once. (Never, if Linux came pre-installed.) Personally I think the post-install user experience is a much more significant thing than installation, simply because if it's good enough, PC distributors will do the installation for people.
For a Linux desktop to be preferred over Windows, the Linux desktop experience will have to provide something new and innovative that Windows does not, rather than just knocking off Windows features.
I use Windows XP at work all day and Linux at home -- both are stable, although I still find I have to reboot XP from time to time when installing applications (which I tend to do a lot of). This isn't as much of an issue in Linux. My opinion is entirely my own and I don't expect it to necessarily be relevant to others. For me, however, the major difference is the stability of integration between applications.
I've had nothing but problems with Windows applications, and trying to get them to work together. Even Microsoft applications don't work well with other Microsoft applications, and I suspect that 80% of my day job is fighting with applications that don't want to work nicely together.
The reason for this, as I see it, is the development model. Every application provider is in it for themselves. They don't share their information unless they have major partner agreements, they usually don't share their source code, they certainly don't let someone tweak their application and distribute it on their behalf.
The entire OSS model, which includes Linux, is the opposite of this. People release their software. If it's an good, it's expected that others will pick it up and tweak it -- not necessarily to fork it, but simply to get it to fit in with an environment. Some of the individual applications are a bit awkward to use and administer when compared with their Windows counterparts (the degree of which depends on who you ask), but in general I've found OSS to be much easier to get a genuinely integrated system working where different software cooperates with its neighbours.
I use Debian at home as a preference, but there are several good major distributions to choose from. Different distros don't always work perfectly or consistently together, but I can be much more sure at home that if I apt-get install some-package, then it won't break my system.
The configuration, although arguably more awkward for some people to edit if its badly documented, tends to be much more open, too. In Windows, applications throw around registry entries and binary files that are unreadable or incomprehensible by anything except the application. If I'm having trouble getting two apps to play nicely in Windows and want to integrate or centralise their configuration somehow, it can be very difficult to impossible. In an open source distribution, it's much more likely that I can quite easily write a script that might parse things, move files around, or do whatever's necessary --- I could even recompile the application if it's that difficult. Chances are I won't need to, though, because the distribution normally gets it right.
Does this make it a good distro for non-techies to set up in their homes? Probably not. When things go wrong on my home system, I still rely on a certain amount of technical ability to fix problems when others might simply choose to re-install. But if I was using Windows, I'd more likely have to reinstall the OS to fix the problems, because after a point it's just too complex to diagnose. The integration factor makes OSS much less of a headache for admins who understand what they're doing with it, though, in my opinion. It's not for every admin, though, and the fact that so many offices rely on specialised Windows-only applications means this isn't always an option anyway.
The necessity of hand-editing xorg.conf or frankly any.conf file keeps Ubuntu and Linux in general out of the mainstream. Joe Sixpack isn't going to do it. Fundamental things such as video, keyboard, and mouse should work immediately, with sane and functional fallbacks.
I don't disagree with you that most people aren't going to edit a configuration file. The frustrating irony though, I think, is that most people wouldn't be able to do what it takes to install Windows on their PC, either, if it wasn't already pre-installed when they bought their PC. I've lost count of the number of times I've tried to install Windows on a PC and not had it run smoothly, because fundamental things such as mouse and video let alone the CD Rom drive that I needed for various drivers (at times when I'd installed older Windows from floppy disks) simply didn't work cleanly out of the box.
Some people, including techies, are much more used to the Windows way of doing things, and would have a few problems configuring Linux immediately. That said, I'm skeptical that the use of a text editor is anywhere near as much of a barrier as knowing what's going on underneath, and knowing where to find the configuration. I also don't think people should need to understand this.
I'm not convinced that Windows is that much better than some of the more advanced Linux distros when it comes to installation. Its primary advantage lies in the various marketing deals that Microsoft has in place so that regular people don't have to install it. Good for Microsoft.
I know we don't have the previous satellite images from years gone by, but would it be practical to use some sort of image diffing program to look for changes in satellite imagery in the future? Yes, you'd get all the new building activity and whatnot, but we should also be able to tell when new craters hit (or other bigger changes happen) automatically.
If you mean to search for impact craters, then it's probably not at all practical for the types of craters that are discussed in this article. The initial crater mentioned is 195 kms in diameter. The article's not specific about the other two, but it seems that they're also on the order of many kilometres in diameter. Add to that that they'll be very very old, probably on the order of many tens of thousands to millions or hundreds of millions of years depending on the size and state. The erosion of them is part of the main reason they wouldn't have been discovered until now.
If any of these craters were created in modern times, we'd very definitely know about it, irrespective of where on the Earth it was. If the entire Earth's sky didn't turn red and light wasn't blocked for years and large populations weren't killed, the impact would show up quite obviously on geological equipment for detecting Earth tremors.
There are probably smaller impact craters forming on a more common basis if there were extremely high resolutions available, but they'd also be eroding much more quickly. Consequently you'd likely need very high resolutions, and need new ones frequently, and then some reliable algorithm for filtering out every farmer (or rabbit) who's dug a small hole for some reason.
I'm an amateur astronomer but I'm not an expert on meteorite impacts, so I'd be interested to hear the comments of someone who knew a bit more about satellite images and impact craters. It seems pretty unlikely to me from my own understanding that it'd be infeasible, though.
What programs are government agencies using that can't run on Linux?
If you can suggest an Open Source application that cleanly supports an interface with Document Management Systems, such as ODMA, I'd be very interested.
I work in a (non-US) government department, and we're required by law to keep all documents for certain amounts of time... the exact amount of which depends on the type of document. We also have some legal requierments to protect certain types of documents from some employees. (eg. If two branches of the department are supposed to be providing independent advice on the same topic from different perspectives, we need to be able to demonstrate they haven't been reading each other's work.) This sort of thing is also often very important for law firms.
We do this by educating staff to save documents into a Document Managenent System (we currently use Interwoven's Worksite but aren't locked into it), which requires them to enter some extra metadata about what the document is, and helps to centralise the whole document management thing immensely.
I use OSS at home for my own things all the time, and at home I've gone without Microsoft products at all for at least 2 years, but last time I looked at the main Office tools (OpenOffice, KOffice, AbiWord, etc), I couldn't find any reliable support for ODMA. To be fair, Microsoft Office also has hopeless half-done support for ODMA, but at least it's popular enough that the main Document Management System providers have grudgingly written their own plugins to work with MS Office. ODMA's an open protocol that's already supported by much DMS software, though, and it's unclear to me why it wasn't supported by open source office and related products long ago.
When you have a small to medium business all with computers on an active directory domain, it's nice that your email client can authenticate from your logon, and the shared calendar / contacts / etc are done nicely.
I think the whole Outlook/Exchange setup is a great tool for working in a small to medium business. I'm sure that other tools that mimic this behaviour are also great, but I haven't had an opportunity to try any.
That said, having had to write code that integrates with Outlook, I've found its implementation to be quite yucky. As well as having its own problems, Outlook is very susceptible to crashing and going down in flames if third party addins aren't written perfectly. This might not be so bad, except that Outlook itself has quite a few bugs that make it hard to write reliable addins, simply because event handlers don't fire on occasion when they're supposed to, and all sorts of other crazy things.
Add to that that the documentation for Outlook's API is awful. As with many Microsoft products, there are lots of show-by-example essays out there, but very few resourses that clearly document exactly what each available part of the API is, how it works, and what it's there for. My theory is that Microsoft doesn't actually know half of this stuff to a specification level, and if they're ever wondering for their own purposes, they just look at their own code.
Point 1 is a non-issue. Security holes wouldn't be any worse than they are presently -- if anything, a remote administration system could roll out updates to PC's much more quickly and easily. If you're really paranoid, by all means give the user a switch to flick so that a remote admin can't touch their system unless they're allowed in. Obviously you'd want a remote administrator to be properly authenticated, but that's not exactly hard to do these days.
Most people I know (not including the linux geeks) would prefer to have someone else administering their system because they don't have the time to do it themselves, nor do they understand or care about everything they have to take seriously to run their systems properly. They'd very seriously even consider paying a little for a service where someone else could keep their applications running, keep their computer working, and keep it in a state where they can use it for what they actually what to do. How many times have you gone to fix a friend or relative's PC when they've just thrown their hands in the air because they can't cope with all the crashing and spyware?
Windows is definitely improving with its remote administration systems, and perhaps such a system could even work via Windows in the near future, but linux (and most Unix-like) boxes are at least as easy to administrate remotely and have been for a long time. They're generally easy to lock down so that users can't break things as much accidentally, and they're also likely to be easier to keep predictible configurations for, if they're managed properly from the start.
Point 3 is also a non-issue, or at least no more of an issue than it already is under current systems. If anything, it'd be possible to help users with network problems much more easily. Obviously remote administration wouldn't be an option if the network broke, but that's only going to be a small proportion of calls anyway. It wouldn't exactly be much worse than existing calls for fixing network connections, and in rare cases where the network config was fried, users could even be provided with a pre-configured boot disk that would let an authenticated tech onto the system, assuming the physical connections were in place properly. Or hell, if they're really concerned, why not just an emergency boot disk that would re-install the operating system and applications but keep the main bits of the configuration and user's data intact?
Besides, if desired, a company like Dell could easily write their own network management interface for Linux that would give users at least as much direct control over and information about their network settings as they have in Windows, as long as people didn't play with the configuration (and most users wouldn't).
As for point 2, I could only disagree with that. It's 100% a trust thing, but it wouldn't be the first time -- it's necessary to trust service-people to do their jobs properly all the time. Businesses have to trust their IT employees all the time, so what's the difference here? Strict procedures about protocol for looking at other other user's systems, appropriate tracking of what happens, are really all that should be needed to keep insurance companies happy. If Dell discovers that someone in their employ has been abusing the position, then by all means take the appropriate actions. If users don't trust Dell, or some other designated administration company, to manage their systems, then by all means they should do it themselves... but they shouldn't let techies into their homes to fix their computers, either.
It's very simple. Support will be an absolute nightmare.
How so? Linux, or any Unix system, is the perfect OS to configure so that a support tech can more simply ssh into the box, look around, fix things themselves, and tell the user what not to do again.
Obviously it'd be a nightmare if you assume traditional methods of support, which are to try and get the user to communicate in detail what's going on (when they don't have a clue), and then try to get the user to do certain things (that they don't understand).
Oh, another cool thing about openSuSE: If it sees a program still using you CD drive and you try to button-push eject, it refuses just like umount does, rather than eject and then flip out that it no longer has access to the CD like Windows *still* does...
Does openSuSE tell you which application is using the CD? I don't use SuSE at home (Debian for me), but one of the things I've found awkward about umount is that it'll simply refuse to unmount the drive without providing more information. The problem could be anything from a program actively running from the CD, to an obscure xterm behind a million other windows that's still CD'd into a directory on the disk.
This falls back to one of the most common problems with usability everywhere, I think. Lots and lots of errors simply don't indicate clearly what the user needs to do, and I think this is largely because current programming techniques make it difficult to do so (and it's a very hard problem to solve). Even when the user isn't allowed to do something erroneous (such as ejecting a CD or selecting a menu option), they could still be wondering why particular menu options are unavailable.
There's so much abstraction in the sorts of things that can go wrong in a lot of software that it's probably going to take yet another quite revolutionary step in software development techniques to make UI's more helpful in this way.
Just to add to the topic, there's quite a fascinating documentary about Al Jazeera, which followed the journalists and news staff around during the American invasion, asks them about what they do, how and why they do it, and so on. It's called Control Room, and if you have any interest in this sort of thing, I think it's a must-see film whether you agree with the conclusions or not.
My parents fought broadband for years and years even though the accessed some work related stuff through the interenet (subdivision maps, deeds, and some other documents from the local court house). The never could see why there was any reason to pay 55 dollars a month plus, because of the wiring in the house not being available, a wireless access point and card.
My parents have avoided broadband to the point where they now have two spare phone lines for two separate PC's in addition to their voice line, which they don't want to tie up. The third phone line even comes from a different telco because the original telco would've charged through the roof for more than two lines. When the ISP decided to block people from dialing in from several places to a single account simultaneously, they bought a second ISP account. They still share their same email account and have a system of leaving mail on the server from one end so that both of them can see incoming mail. Their main method of transferring files from one PC to another is to email it to themselves and collect it from the other PC.
They've considered broadband a couple of times, and personally I think they're paying at least as much now as what it'd cost them for a reasonable broadband connection. Especially if they ditched the two spare phone lines.
What's putting them off is the thought of wiring up the house versus the uncertainty of wireless. They're also quite concerned about the possibility of wireless traffic being intercepted, even though it has safeguards if set up appropriately. In short, they don't want to spend $200 on a wireless infrastructure (including PCI cards), only to find that it doesn't work. To be fair, there are quite a lot of walls (and floors) between the two PC's, so without testing it there's quite a bit of uncertainty. It still seems quite crazy to me, though. At some point I plan to take my router over there with a couple of laptops just to test how well the signal might work, which might convince them that it's worth it.
Regardless, how much does market share factor into this? With Linux, if a patch breaks a program, most people can just shrug it off and rewrite the program to work with the patch. So mass testing isn't as big of an issue. With Windows, if a patch breaks a program, a user doesn't have a lot they can do except to sit there and weep until Company X releases their own patch or next version.
Personally I would have thought that this was more a development model and documentation issue than a market share issue. One of the major reasons that third party software breaks when Microsoft changes its own software is that it's so often unclear about its API's. Programmers have to rely on half-documented API's, and on brittle work-arounds for badly documented Microsoft bugs rather than robust and clear interfaces.
Try writing a non-trivial Outlook addin, for instance, without having to cope with a range of Outlook API bugs and strange ways of acting. The unofficial way of getting around these is to use undocumented hacks that end up being completely unofficial and quite flakey.
Market share seems to be one reason that Microsoft needs to test so many individual software packages with its changes, simply because it can cause such huge problems for people every time they break. If it'd provided stable, robust and well documented API's in the first place, though, I don't think that other people's software breaking would be nearly as much of a problem.
Slashdot Mirror
Is it really that similar, though? Perhaps it's different in the USA, but many cars I've seen are assembled away from the factory. Smaller components such as stereos tend to vary a lot depending on the location where the vehicle was assembled -- they're certainly not provided by or branded by the car maker.
I would have thought this was a standard market where smaller car stereo makers could negotiate with the car assemblers to get their product included. Clearly the end customer has less choice (unless they rip it out and change it afterwards), but it's not so much a case of locking out competitors.
Having an application that will run nicely in both desktops is appealing in itself, but aren't the respective API's for Gnome and KDE (which are quite different) one of the great incentives for developers? If this new API is going to appeal to lots of (all?) developers, it would need to somehow appeal to both camps, and given their significant fundamental differences in coding styles, that might be difficult.
Personally I don't think that a .xxx domain will be especially useful or beneficial, unless its part of a radical move such as opening up all possible TLD's. I also think it could quite possibly lead to undesirable things such as governments trying to implement legislation around its existance.
That said, what bothers me about this has nothing to do with the fact that it's being blocked -- it's the way that it's being blocked. There's a clear process available to be followed for deciding this, but several governments have decided that they're too important to be dictated to by that process, and are overriding it. It doesn't exactly set a good precedent for representative users of the 'net and the DNS to determine things themselves.
I find it hard to understand that companies such as Symantec and McAfee apparently haven't had a strategy prepared for this eventuality. If you've built a business on Microsoft's incompetence, then surely you'd have to expect that sooner or later Microsoft's competence would either improve, or Microsoft would go out of business, taking with it any businesses that leech off its existance.
If they truly haven't been prepared for this, they deserve to become obsolete.
I don't see why this is a problem, as long as parents use it sensibly and with the knowledge that it's not failsafe. It's a safety device. Giving parents an ability to control it is even better simply because a lot of children don't yet have the cognitive development, understanding or experience necessary to properly decide what volume level is safe for them.
How is this different from childlocks on car doors, grills in front of fireplaces, bars around children's beds (ie. cots), and a variety of other devices designed to help parents prevent their kids from getting into trouble?
If I was a parent with my own iPod, I'd probably consider setting this simply to cover those situations where the kids might want to borrow it. Sure they can amplify it, but chances are that they won't, and I'd be working on educating them at the same time. It's hardly the same as a parent using a TV as a babysitter and ignoring their child's existance, unless they choose to use it as such.
This is true for the most part, but personally I've also felt that the problems with maintaining backward compatibility have been a result of Microsoft's decision to produce closed source software, and to encourage other developers and businesses to copy their model. (ie. Hide your source so people can't read it, charge people to install and continue using your software, and don't let anyone use or improve on your code.)
With closed source software applications, any or all of the following are typically necessary when the OS is upgraded:
In essence, every time Microsoft changes Windows, its customers either have to rely on Windows having backward compatibility, or they have to rely on the vendors of all their software... even if the underlying API changes have been trivial. There's also a single point of failure because if the vendor doesn't fix any problems properly, there's no opportunity for anyone else to do it better.
Compare this with open source software, where even though the OS API's tend to be a little more stable, it's still quite straightforward to upgrade to new versions of software when the API's do change. If the vendor of an OSS product doesn't do it quickly enough, and their product is popular enough, chances are that someone's at least going to produce a patch. There's rarely such a thing as a vendor going out of business and causing major problems, because at someone else is likely to pick it up if enough people use it, or provide an easy-to-implement alternative that'll simply read data from the original app's open formats.
I'm definitely not trying to claim that open source is superior to closed source for everyone, and I doubt Microsoft could have been such a commercially successful company if it'd built itself on open source software. Having said so, though, I think the backward compatibility issues are a direct result of Microsoft promoting closed source software. It's not something that's even a consideration with open source users for the most part, and Windows wouldn't have to be anywhere near as backward compatible if it was easier to adjust and upgrade the applications that run on it.
I don't disagree with you that OpenOffice is great to have, simply because it gives many people a drop-in alternative to Microsoft Office, and I even said as such in my earlier post. As for this:
The 64-bit compilation issue was really only intended to be a demonstration of my point, which is that the OpenOffice code is too stagnant and encumbered to be able to make any radical changes. Sooner or later, things will probably change around OpenOffice too quickly for it to keep up. If it's not CPU architectures that change, it'll be radical changes in standard GUI widgets or file system design, or something else that challenges the static legacy design decisions of OpenOffice. And yes, of course people will still be able to use OpenOffice to do everything they need to do, as long as they keep a legacy OS or window manager or old un-supported worn-out hardware that's separate from their regular hardware, and as long as they're happy with OpenOffice acting inconsistently with everything else they use, or whatever, because sooner or later it probably won't be able to be easily changed to keep up.
In the Microsoft world, MS Office will either adapt (because Microsoft can afford to throw huge amounts of money at the problem), or other products more suitable to the changes will move in to replace the existing Office suite. OpenOffice, however, isn't exactly a long term solution to anything, and I think it's misleading to suggest that it's a perfect solution to replacing MS Office. Right now, as porkThreeWays put it in a separate response to my earlier post, OpenOffice is a transition tool, but it's not likely to be a long term tool. But a transition to what? A system that relies on OpenOffice as its main Office tool?
My mistake, thanks for the correction.
Well, since you mentioned Outlook, I can think of at least two things from the point of view of someone who's had to write Outlook addins. (Even worse, in inheriting the maintenance of other people's Outlook addins.)
I'd like Outlook to have a consistent API for writing addins that's native to .Net (or anything else that has decent garbage collection), and where it's not necessary to directly interface with COM objects to get things done. It seems a bit ridiculous that 5 years after Microsoft released and started pushing its new Microsoft's own applications that were released several years afterwards!
I'd consider settling without that if Microsoft would simply fix the bugs that seem to be preventing some Outlook event handlers from firing when they're supposed to. (Specifically in our case, the Inspector.Close event doesn't fire reliably, and there's nowhere else to cleanly put the clean-up code that goes and deallocates the COM objects.)
Irrespective of the interface, Outlook 2003 is buggy, and many people who've had to integrate it with anything will know this very well. If Microsoft could just make it stable, not to mention having it run addins in sandboxes so that malfunctioning addins can't make an entire desktop unstable, I'd be happy.
That said, what are the chances of OpenOffice.Org actually improving radically? As much as I admire the people who put effort into improving it, the project gives me the impression of something like Netscape 4, which was like the engine of Netscape 3 with lots of band-aid features stuck over its face that made it act slower, inconsistent with itself, unstable, and generally buggy. Correct me if I'm wrong, but it feels like there's so much legacy code and design in OpenOffice that it's difficult to implement important changes. In essence, and I'd be happy to be proved wrong, it seems like a big ancient application built on legacy design that's only going downhill and will inevitably be overtaken by others if it hasn't been already.
I've been put off OpenOffice for some time now because it won't (cleanly) compile as a native 64 bit application. I was looking forward to the 2.0 release because I'd been led to believe that the incompatibilities were being ironed out specifically for that release, and then it would compile as a 64 bit application, but on release that unfortunately wasn't the case. Searching further, I discovered that the OpenOffice code was apparently still so messy from the Sun days that it simply hadn't been feasible to port to a 64 bit app in any reliable way, and probably wouldn't be for a long time to come.
If OpenOffice had nice and easy-to-maintain code, I would have thought that a 64-bit build would have been as easy as a recompile -- perhaps with a couple of unforseen bug-fixes here and there. The problem is that something as basic as native 64-bit compilation is yet another thing that was never in the original design brief, and trying to patch it in later is a horrible task. I'm not an OpenOffice.Org developer, so if someone knows otherwise about this I'm keen to know.
OpenOffice is convenient to have right now because it provides an 80% replacement for a lot of what MS Office does. Many people looking to switch might be able to use it as a drop-in replacement if their requirements aren't too complex. It's still a mammoth and heavily complex system with considerably dead weight, though, and unfortunately it's not particularly bug free.
Personally, I've found it much easier to go with the more light-weight open source office apps, which aren't trying to be mammoth applications. Lately I've been using the likes of AbiWord, KWord, Gnumeric, and so on, and I've found them to be much more responsive, integrated with my system, and generally more stable than either OpenOffice or MS Office would be. (Actually I can't test MS Office on my system because it's not Windows, so I'm comparing it with MS Office on a typical Windows system.)
The lighter-weight open source apps don't do as much as OpenOffice or MS Office, but they do enough to keep me satisfied. Unfortunately this isn't an option for most people who are locked into Microsoft Office for things like specialised code and plugins and various desktop integration stuff, but then neither is OpenOffice. eg. Supporting something like OpenOffice at my current work is completely out of the question, simply because it won't integrate with our document management systems, despite ODMA (Open Document Management API) being an open API that's existed for ages and is supported by the bulk of DMS products. (MS Office doesn't cleanly support ODMA either, but it's popular enough that it gets special attention from the DMS vendors.)
It might be that I wasn't clear enough, and it's also that you seem to have misunderstood me to some extent. If this was the case then please accept my apologies.
If you live in San Francisco, then you should know that the 1989 quake, as did the 1906 quake, resulted in some significant changes to building regulations, including highway bridge regulations, after it was noticed that several standard precautions already known about hadn't been implemented properly or effectively. If you live there, you're already paying extra to live in buildings of a higher standard than you might live in elsewhere. Also as much as they demand attention for preparation, earthquakes simply don't occur as often as severe storms. I also live in an Earthquake risk zone, and I pay extra for it too. Will my government bail us out if an Earthquake strikes? Sure, at least I hope so, but the chances of that actually happening are still considerably average over the next several hundred years. We might be hit tommorrow, or not for a thousand years. Like you, we also pay our way, and I'd like to think that a bailout cost every few hundred years would be insignificant compared with the economic return of being here.
It's completely true that sometimes there are very good reasons for living in dangerous places, especially when it's economic to do so. Maybe there's a big and very accessible harbour there, for instance. Alternatively, volcanic ash that surrounds volcanoes is great for producing crops efficiently. I'm not trying to suggest that people shouldn't be allowed to live in dangerous places across the board, or that a fence should be put up to stop people visiting on the off-chance that a disaster will strike. (For hurricanes it's not too difficult to predict their impact in a reasonable time, anyway.) But I think there should definitely be some restrictions on building in the places that are obviously most at risk, and likely to be subject to natural disasters again and again.
But come on, the coast of New Orleans is going to be hammered by big hurricanes over and over again from now on. The only difference between now and 50 years ago is the recent 50 year lapse in the standard weather pattern. During this time people became complacent and started building in places where they really shouldn't have built. Now that the pattern's resuming and they've finally been hit again, the response isn't to say "Oops, we shouldn't have done that.. we'd better pull back to where we were". On the contrary, the response is to spend billions of dollars trying to devise ways to let people continue living in places below sea level that will be repeatedly exposed to severe hurricanes, and that people never would have wanted to live in if they hadn't had an opportunity to establish themselves during an inconsistent patch of climatic conditions. To top it off, the methods being devised are probably not going to work with any certainty or effectiveness, and the area will continue to be a sink for other people's money that could otherwise be spent on much more useful things -- or alternatively given back to them if you happen to think that way.
Really, to be honest, New Orleans is in the US and I'm not deeply concerned about how you choose to run your internal affairs except when they have spinoffs that affect me. If you want to spend billions of dollars on subsidising people's poor choices of living locality, by all means do so and who am I to argue? It's not even my money. I do find it quite perpelexing to look at, though.
Locally, in New Zealand, I am concerned, because the places that cost the most to bail out of disasters are the small coastal towns that are demonstrably in locations subject to severe conditions (between their attractive sunshine). These places don't provide a lot of tax anyway. With a few exceptions, they tend to be full of people living there in retiremen
Thanks for stating this -- as far as I'm concerned, there are a lot of places where people simply shouldn't be living. As I understand it (I'm not from the area so correct me if I'm wrong), New Orleans used to get lots of hurricanes similar to Katrina, and there's simply been a remisssion for about 50 years. People became complacent during that time, property near the coast was subdivided, and everyone flocked to it. 50 years later big storms are back. Apparently the solution isn't to move away -- it's to spend tens or hundreds of billions of dollars rebuilding?? Trying to protect a region below sea level?? There are some things that are just ridiculous.
As far as I'm concerned, people whose homes and properties are wiped out like this should be given a chance where appropriate. I live in New Zealand, and while not on as-large-a-scale as some disasters in the US, we do have several places that have been wiped out by serious weather events.
These disasters have resulted in substantial amounts of money that, essentially, comes out of my taxes. I don't mind this the first time, but bailing people out over and over again just because they like to live in a place that's clearly vulnerable to forces of nature seems silly.
We also have plenty of examples of disasters-in-waiting, which are simply being ignored. One of them, for instance, is an expected Tsunami to hit Kaikoura in the near future. There's an underwater landslide down the coast that's just waiting to happen, and almost certainly will cause the place to be at serious risk. The attitude of the locals is to ignore the risk, claim that they'll get through it like any other day, and keep on living there.
I really do sympathise with people who are living in places like this, especially if they have roots there but I also think that governments should be making it very clear about significant danger zones, and if appropriate, preventing people from living in them. I'm tempted to say that people should be allowed to live in such places at their own risk, but I don't think it's realistic to expect that help won't be offered if it's needed. I also think that such a policy would victimise poor people, by making those areas much much cheaper to live in (as well as other areas more expensive).
If that's what you want, I'd honestly suggest starting with something like Knoppix. That way, you can even cut out step 2. It'll also give you a chance to decide if you want to use Linux in the longer term. Knoppix lets you install it on a HDD to avoid needing a boot CD if that's what you want, but if you're serious you might then decide to install something like Debian or Ubantu over the top.
Installation might be a hiccup, but you only have to do it once. (Never, if Linux came pre-installed.) Personally I think the post-install user experience is a much more significant thing than installation, simply because if it's good enough, PC distributors will do the installation for people.
I use Windows XP at work all day and Linux at home -- both are stable, although I still find I have to reboot XP from time to time when installing applications (which I tend to do a lot of). This isn't as much of an issue in Linux. My opinion is entirely my own and I don't expect it to necessarily be relevant to others. For me, however, the major difference is the stability of integration between applications.
I've had nothing but problems with Windows applications, and trying to get them to work together. Even Microsoft applications don't work well with other Microsoft applications, and I suspect that 80% of my day job is fighting with applications that don't want to work nicely together.
The reason for this, as I see it, is the development model. Every application provider is in it for themselves. They don't share their information unless they have major partner agreements, they usually don't share their source code, they certainly don't let someone tweak their application and distribute it on their behalf.
The entire OSS model, which includes Linux, is the opposite of this. People release their software. If it's an good, it's expected that others will pick it up and tweak it -- not necessarily to fork it, but simply to get it to fit in with an environment. Some of the individual applications are a bit awkward to use and administer when compared with their Windows counterparts (the degree of which depends on who you ask), but in general I've found OSS to be much easier to get a genuinely integrated system working where different software cooperates with its neighbours.
I use Debian at home as a preference, but there are several good major distributions to choose from. Different distros don't always work perfectly or consistently together, but I can be much more sure at home that if I apt-get install some-package, then it won't break my system.
The configuration, although arguably more awkward for some people to edit if its badly documented, tends to be much more open, too. In Windows, applications throw around registry entries and binary files that are unreadable or incomprehensible by anything except the application. If I'm having trouble getting two apps to play nicely in Windows and want to integrate or centralise their configuration somehow, it can be very difficult to impossible. In an open source distribution, it's much more likely that I can quite easily write a script that might parse things, move files around, or do whatever's necessary --- I could even recompile the application if it's that difficult. Chances are I won't need to, though, because the distribution normally gets it right.
Does this make it a good distro for non-techies to set up in their homes? Probably not. When things go wrong on my home system, I still rely on a certain amount of technical ability to fix problems when others might simply choose to re-install. But if I was using Windows, I'd more likely have to reinstall the OS to fix the problems, because after a point it's just too complex to diagnose. The integration factor makes OSS much less of a headache for admins who understand what they're doing with it, though, in my opinion. It's not for every admin, though, and the fact that so many offices rely on specialised Windows-only applications means this isn't always an option anyway.
I don't disagree with you that most people aren't going to edit a configuration file. The frustrating irony though, I think, is that most people wouldn't be able to do what it takes to install Windows on their PC, either, if it wasn't already pre-installed when they bought their PC. I've lost count of the number of times I've tried to install Windows on a PC and not had it run smoothly, because fundamental things such as mouse and video let alone the CD Rom drive that I needed for various drivers (at times when I'd installed older Windows from floppy disks) simply didn't work cleanly out of the box.
Some people, including techies, are much more used to the Windows way of doing things, and would have a few problems configuring Linux immediately. That said, I'm skeptical that the use of a text editor is anywhere near as much of a barrier as knowing what's going on underneath, and knowing where to find the configuration. I also don't think people should need to understand this.
I'm not convinced that Windows is that much better than some of the more advanced Linux distros when it comes to installation. Its primary advantage lies in the various marketing deals that Microsoft has in place so that regular people don't have to install it. Good for Microsoft.
If you mean to search for impact craters, then it's probably not at all practical for the types of craters that are discussed in this article. The initial crater mentioned is 195 kms in diameter. The article's not specific about the other two, but it seems that they're also on the order of many kilometres in diameter. Add to that that they'll be very very old, probably on the order of many tens of thousands to millions or hundreds of millions of years depending on the size and state. The erosion of them is part of the main reason they wouldn't have been discovered until now.
If any of these craters were created in modern times, we'd very definitely know about it, irrespective of where on the Earth it was. If the entire Earth's sky didn't turn red and light wasn't blocked for years and large populations weren't killed, the impact would show up quite obviously on geological equipment for detecting Earth tremors.
There are probably smaller impact craters forming on a more common basis if there were extremely high resolutions available, but they'd also be eroding much more quickly. Consequently you'd likely need very high resolutions, and need new ones frequently, and then some reliable algorithm for filtering out every farmer (or rabbit) who's dug a small hole for some reason.
I'm an amateur astronomer but I'm not an expert on meteorite impacts, so I'd be interested to hear the comments of someone who knew a bit more about satellite images and impact craters. It seems pretty unlikely to me from my own understanding that it'd be infeasible, though.
If you can suggest an Open Source application that cleanly supports an interface with Document Management Systems, such as ODMA, I'd be very interested.
I work in a (non-US) government department, and we're required by law to keep all documents for certain amounts of time ... the exact amount of which depends on the type of document. We also have some legal requierments to protect certain types of documents from some employees. (eg. If two branches of the department are supposed to be providing independent advice on the same topic from different perspectives, we need to be able to demonstrate they haven't been reading each other's work.) This sort of thing is also often very important for law firms.
We do this by educating staff to save documents into a Document Managenent System (we currently use Interwoven's Worksite but aren't locked into it), which requires them to enter some extra metadata about what the document is, and helps to centralise the whole document management thing immensely.
I use OSS at home for my own things all the time, and at home I've gone without Microsoft products at all for at least 2 years, but last time I looked at the main Office tools (OpenOffice, KOffice, AbiWord, etc), I couldn't find any reliable support for ODMA. To be fair, Microsoft Office also has hopeless half-done support for ODMA, but at least it's popular enough that the main Document Management System providers have grudgingly written their own plugins to work with MS Office. ODMA's an open protocol that's already supported by much DMS software, though, and it's unclear to me why it wasn't supported by open source office and related products long ago.
I think the whole Outlook/Exchange setup is a great tool for working in a small to medium business. I'm sure that other tools that mimic this behaviour are also great, but I haven't had an opportunity to try any.
That said, having had to write code that integrates with Outlook, I've found its implementation to be quite yucky. As well as having its own problems, Outlook is very susceptible to crashing and going down in flames if third party addins aren't written perfectly. This might not be so bad, except that Outlook itself has quite a few bugs that make it hard to write reliable addins, simply because event handlers don't fire on occasion when they're supposed to, and all sorts of other crazy things.
Add to that that the documentation for Outlook's API is awful. As with many Microsoft products, there are lots of show-by-example essays out there, but very few resourses that clearly document exactly what each available part of the API is, how it works, and what it's there for. My theory is that Microsoft doesn't actually know half of this stuff to a specification level, and if they're ever wondering for their own purposes, they just look at their own code.
No, I'm not kidding.
Point 1 is a non-issue. Security holes wouldn't be any worse than they are presently -- if anything, a remote administration system could roll out updates to PC's much more quickly and easily. If you're really paranoid, by all means give the user a switch to flick so that a remote admin can't touch their system unless they're allowed in. Obviously you'd want a remote administrator to be properly authenticated, but that's not exactly hard to do these days.
Most people I know (not including the linux geeks) would prefer to have someone else administering their system because they don't have the time to do it themselves, nor do they understand or care about everything they have to take seriously to run their systems properly. They'd very seriously even consider paying a little for a service where someone else could keep their applications running, keep their computer working, and keep it in a state where they can use it for what they actually what to do. How many times have you gone to fix a friend or relative's PC when they've just thrown their hands in the air because they can't cope with all the crashing and spyware?
Windows is definitely improving with its remote administration systems, and perhaps such a system could even work via Windows in the near future, but linux (and most Unix-like) boxes are at least as easy to administrate remotely and have been for a long time. They're generally easy to lock down so that users can't break things as much accidentally, and they're also likely to be easier to keep predictible configurations for, if they're managed properly from the start.
Point 3 is also a non-issue, or at least no more of an issue than it already is under current systems. If anything, it'd be possible to help users with network problems much more easily. Obviously remote administration wouldn't be an option if the network broke, but that's only going to be a small proportion of calls anyway. It wouldn't exactly be much worse than existing calls for fixing network connections, and in rare cases where the network config was fried, users could even be provided with a pre-configured boot disk that would let an authenticated tech onto the system, assuming the physical connections were in place properly. Or hell, if they're really concerned, why not just an emergency boot disk that would re-install the operating system and applications but keep the main bits of the configuration and user's data intact?
Besides, if desired, a company like Dell could easily write their own network management interface for Linux that would give users at least as much direct control over and information about their network settings as they have in Windows, as long as people didn't play with the configuration (and most users wouldn't).
As for point 2, I could only disagree with that. It's 100% a trust thing, but it wouldn't be the first time -- it's necessary to trust service-people to do their jobs properly all the time. Businesses have to trust their IT employees all the time, so what's the difference here? Strict procedures about protocol for looking at other other user's systems, appropriate tracking of what happens, are really all that should be needed to keep insurance companies happy. If Dell discovers that someone in their employ has been abusing the position, then by all means take the appropriate actions. If users don't trust Dell, or some other designated administration company, to manage their systems, then by all means they should do it themselves... but they shouldn't let techies into their homes to fix their computers, either.
How so? Linux, or any Unix system, is the perfect OS to configure so that a support tech can more simply ssh into the box, look around, fix things themselves, and tell the user what not to do again.
Obviously it'd be a nightmare if you assume traditional methods of support, which are to try and get the user to communicate in detail what's going on (when they don't have a clue), and then try to get the user to do certain things (that they don't understand).
Does openSuSE tell you which application is using the CD? I don't use SuSE at home (Debian for me), but one of the things I've found awkward about umount is that it'll simply refuse to unmount the drive without providing more information. The problem could be anything from a program actively running from the CD, to an obscure xterm behind a million other windows that's still CD'd into a directory on the disk.
This falls back to one of the most common problems with usability everywhere, I think. Lots and lots of errors simply don't indicate clearly what the user needs to do, and I think this is largely because current programming techniques make it difficult to do so (and it's a very hard problem to solve). Even when the user isn't allowed to do something erroneous (such as ejecting a CD or selecting a menu option), they could still be wondering why particular menu options are unavailable.
There's so much abstraction in the sorts of things that can go wrong in a lot of software that it's probably going to take yet another quite revolutionary step in software development techniques to make UI's more helpful in this way.
Just to add to the topic, there's quite a fascinating documentary about Al Jazeera, which followed the journalists and news staff around during the American invasion, asks them about what they do, how and why they do it, and so on. It's called Control Room, and if you have any interest in this sort of thing, I think it's a must-see film whether you agree with the conclusions or not.
My parents have avoided broadband to the point where they now have two spare phone lines for two separate PC's in addition to their voice line, which they don't want to tie up. The third phone line even comes from a different telco because the original telco would've charged through the roof for more than two lines. When the ISP decided to block people from dialing in from several places to a single account simultaneously, they bought a second ISP account. They still share their same email account and have a system of leaving mail on the server from one end so that both of them can see incoming mail. Their main method of transferring files from one PC to another is to email it to themselves and collect it from the other PC.
They've considered broadband a couple of times, and personally I think they're paying at least as much now as what it'd cost them for a reasonable broadband connection. Especially if they ditched the two spare phone lines.
What's putting them off is the thought of wiring up the house versus the uncertainty of wireless. They're also quite concerned about the possibility of wireless traffic being intercepted, even though it has safeguards if set up appropriately. In short, they don't want to spend $200 on a wireless infrastructure (including PCI cards), only to find that it doesn't work. To be fair, there are quite a lot of walls (and floors) between the two PC's, so without testing it there's quite a bit of uncertainty. It still seems quite crazy to me, though. At some point I plan to take my router over there with a couple of laptops just to test how well the signal might work, which might convince them that it's worth it.
Personally I would have thought that this was more a development model and documentation issue than a market share issue. One of the major reasons that third party software breaks when Microsoft changes its own software is that it's so often unclear about its API's. Programmers have to rely on half-documented API's, and on brittle work-arounds for badly documented Microsoft bugs rather than robust and clear interfaces.
Try writing a non-trivial Outlook addin, for instance, without having to cope with a range of Outlook API bugs and strange ways of acting. The unofficial way of getting around these is to use undocumented hacks that end up being completely unofficial and quite flakey.
Market share seems to be one reason that Microsoft needs to test so many individual software packages with its changes, simply because it can cause such huge problems for people every time they break. If it'd provided stable, robust and well documented API's in the first place, though, I don't think that other people's software breaking would be nearly as much of a problem.