The simple fact of the matter is that the pins on the US plug are so short that by the point it is far enough out of the socket to expose enough of the pins to touch them with your fingers, it's unplugged. No partially insulated pins or other wacky design contrivances are needed.
A US plug can stick out a few mm and still work. That's not enough to touch your finger to, but it's still somewhat dangerous. I once saw a fire in a dorm room start when a guy was sweeping (military school) and swept some kind of bare wire coming out of the radiator across some exposed plugs on a surge protector. It was more funny than anything since the broom was the only flammable thing around. Kind of an odd situation but I try to make sure my stuff is plugged in all the way (difficult with heavy wall warts).
OTOH, I don't think it's really a problem since it basically requires a thin strip of uninsulated metal to become dangerous. Smaller outlets are indeed preferable as far as I'm concerned. I just wish we'd go ahead and switch to DC for normal outlets and leave AC for stuff like appliances and powerlines.
Of course, given that apparently some British folk thought people might do this, I can see why they'd want an idiot proof outlet.
That has some interesting applications. Whereas it might take hundreds or thousands of UAVs/aircraft to locate these balloons, a sympathetic population might very well be able to do it for a fraction of the cost and risk. Who knows, maybe the next time we're occupying a country the military might give out free cell phones to generate a little good will and put the population to work finding our enemies.
Interesting, that seems to directly contradict my personal experience.
The intelligence of the poor is on par with any other population - but the metrics are skewed for culture and training.
I grew up in a very rural area. A large portion of the population lives on SSI and there are very few high paying jobs for those who don't. OTOH, nutrition is better than in most poor areas since many people farm. All that said, a very high percentage of the children are quite slow, and it's apparent in even the lowest grades. I had many classmates that were unable to read even in the eighth grade after years of special education. That doesn't seem like a social artifact nor a lack of education, but genetics. Culturally, being that slow will get you picked on, so it's not like they weren't trying.
The rich ARE evil.
Obviously I didn't want to stay in my hometown school system (3rd from the bottom in the state, and the state can't be rank very high either). So I applied and was accepted to a rather nice boarding school. I was friends with several children from millionaire families, and probably am underestimating the number since they didn't stick out. I.e. there was a stigma about mentioning family income, and there was no definite way of identifying them (grades were average, nobody live in luxury in the dorms, etc.). I hardly found them to be evil.
One thing I have noticed is that the rich almost never admit to being wealthy. In medical school there was a speaker on diversity that asked everyone to raise their hand given their income level while growing up. Now, keep in mind a good portion are doctor's children so 6 or 7 figure family incomes aren't uncommon. When he mentioned poor, about 1/5 - 1/4 of the class raises their hand. Middle class got most of the rest. Wealthy got two hands, one of which broke into tears (her mother had major medical problems so they're poor now). In my high school, one student mentioned that his father was the CEO of [major company] when he first arrived, and was rather unpopular for the remainder of his four years there.
The rich are one of the few social classes most people feel it is ok to hate. It's not really manipulation that causes some people to not do so. It's partially optimism that they will one day enter their ranks, and partially because many feel that successful people deserve praise rather than contempt. That's of course referring to public attitude toward the wealthy that earned their money. The ones that inherited it are kind of ignored since there's too much class mobility in America for wealth to persist for many generations without being competently managed. Not to mention that the wealthiest people in the world all made their fortunes (excluding heads of state).
A fair number of the helper applications manufacturers bundle broke with the upgrade. On my Sony laptop installing the Vista version of the Vaio Control Center will trigger a non-Sony battery detected message at startup and force hibernation. A couple of my friends with tablets report that HP's new Windows 7 compatible tablet "driver" is missing a couple of features.
Species can be defined in four ways (IIRC). The biological species concept is just one of them, although probably the least arbitrary. It's rather interesting, since human classification of animals into species doesn't seem to vary much by culture (e.g. isolated jungle tribes generally group them the same way the modern world does). The problem is scientifically validating the classification since it's more semantics than anything. The lack of gene transfer between species is about the only biological distinction, but even that isn't absolute. There is the rare fertile mule, for example. Viruses can also transduct genetic material between hosts, perhaps different species, although that would be rare and even more rarely heritable.
Basically, there is little chance that Humans and Neanderthals will be called the same species because that's not how they are popularly viewed.
I think it's more a matter of what's important to you. I'm quite satisfied with my JMicron drive despite its faults. OTOH, I was well aware of what I was buying, and figured the random write performance and lack of capacity wasn't that big of an issue for me, whereas performance in all other areas and lowered power consumption were a great improvement for my laptop. So it was well worth the $50 I spent on it.
My anecdote: I've have a 30 GB OCZ Core V2 since December and haven't really had any serious problems with it. Partition alignment seems to be important since I did have some minor stutter on the one partition that was misaligned. OTOH, that was my Vista install so it might not have been the drive. I've installed Gentoo three or four times (everything compiled except for open office), Vista about five times, Win7 Beta, RC, then Retail, and maybe a dozen builds of Haiku. Performance has always been quite good except on the misaligned Vista install, and even then it was acceptable after tweaking. I have never noticed any data loss (or symptoms of it), but IMHO it's far better suited as a cost effective higher performance boot drive rather than long term storage.
There also is a firmware update available that apparently fixes a lot of the well known problems, and many people have reported success with it. Unfortunately, OCZ has announced that they will not release or support any updates for Core V2s, which kinda makes ya wonder why they advertised them as upgradable.
And if he was forced to upgrade manually (without package management), he'd probably upgrade far less often, even when it was a critical security issue.
That is self resolving. If he doesn't keep his box secure then he'll get burned and learn to not do that in the future. That strategy won't work for end users since they don't recognize the breach, and have admins to fix stuff for them, but it should work for admins.
Trivial to maintain with package management. A bitch to check 100 different sites (or subscribe to 100 different mailing lists) without package management.
And how many really should be updated without knowing anything about the update? I figure it'd be better practice to keep the daemons up to date, but don't modify the other software unless there's a really good reason.
To an extent.
For example, if I'm unpacking an archive, or playing a movie, what codecs or decompression tool is used is completely beside the point. The point is understanding that this is a movie, or that this is an archive (and not a folder) if it's going to be unpacked...
That's the thing, in all of those examples some users will almost immediately need to know more advanced details. Video codec choice matters since a) anyone can see differences in quality, b) storage space and download speed come into play, c) not all computers are configured to play all codecs, and d) with moderate quality (or higher) h264 hardware acceleration is essentially a requirement. Archive formats also matter for reason c and b to some extent. Basically, some users have to deal with these issues before they can use those formats, and there isn't a good way to get around some of them.
The ability to tweak each setting by hand shouldn't be removed, but users shouldn't be required to tweak these settings. This is essentially why the "more details" button exists.
That is unnecessarily difficult. It's rare for "advance" settings to need to be configured independently. By allowing that option you're forcing the user to learn about all of them in detail. It's the difference between "ok, I need this set to that, oh, here's something that fits my needs" and "ok, I need this set to that and WTF do I set the other 15 values to?".
On the contrary, I think it helps the learning curve. Immediately exposing users to all details leads to information overload, and the perception that this application is "hard".
Don't expose them to all details, but don't hide all the details either. If the user has to click "Advance Options" to do something then usually the "Easy" interface has done nothing to prepare them to work with the "Advance" interface. IMHO that's more of a lazy practice for when a programmer can't think of a way to make the underlying process any easier except for the most common (easy) case.
So add an intermediate interface.
But even if that is the choice, it's still better that users have the default interface, at least, than forcing users to see the advanced one, and thus driving them away.
An intermediate interface just divides one big problem into two smaller problems. That might work, but it's better to solve the problems entirely. The point is not to always show the advance interface, it's to integrate the options into the default one in a way that retains ease of use. It's harder to do, but it makes for better programs.
The problem is, if the butler generally is easier to use, users will use the butler, and not the tool.
True, although a stupid butler is a very dangerous thing. I'm surprised that the combination of (stupid) AI and programmer foresight is enough that this approach actually works most of the time.
I'm saying the bug absolutely should be fixed upstream. But until it can be, if the package manager can fix it, that's a good thing.
The way I see it, the probability of getting a bug fixed is a function of developer motivation. If users can't run the software then there's lots of motivation to fix the bug. If package maintainers are complaining then it's going to be a lot lower priority. The latter more closely resembles reality, and such bugs rarely get fixed so it doesn't seem like that really works.
But the biggest reason this isn't a problem is, if you've upgraded your server, and something broke -- especially if you don't have the option of rolling it back -- you're Doing It Wrong.
Absolutely true. But I figure the dude with a single linux server sitting in the corner of an office might be tempted to blindly upgrade everything. Servers, for security and performance reasons, should only run the absolutely essential software. That should be trivial to maintain with or without package management. Too much abstraction leakage might cause security or performance issues. OTOH, there is a place for easy-to-administer servers, minor performance differences just wouldn't be an issue though.
The flaw in this is that we're still talking about moving to a "traditional" system, ultimately.
You've honed in on the caveat that I didn't mention for fear of being overly verbose. This assumes that the new way doesn't become wide-spread. I suppose it's good to have confidence, but expecting future applications to emulate yours at the mere design stage is quite bold. OTOH, I suppose innovation requires tradition breaking, but one should keep as much skill crossover as possible.
I'm not advocating that users remain ignorant. I'm advocating that if we want to educate users, we should start by teaching them the things which are most important.
Users, for the most part, just want to get something done ASAP, and try to learn as little as they can get away with. I figure education can't be effectively front loaded, you need to teach it along the way. This method makes no differentiation between major or minor stuff. Actually, what's major and what's minor is entirely subjective and differs with each user.
What's more frightening is, you will probably find that every user uses exactly 27 permutations out of those 1024, but they each require a different 27, and there's no way you could cut it down without pissing someone off.
With that example, each user probably only uses about three permutations, and all the different users combined use the 27. Take h264 video encoding for example. There are a ton of options, and several different user requirements. You can change resolution, bitrate, CBR or VBR, and a great many more advance options. The thing is, every user wants the best video quality possible under their individual conditions. Virtually nobody wants a high resolution, low bitrate file, and if they do they are likely doing something wrong (e.g. assuming resolution is more important than bitrate for quality). H264 specifically gets around this with encoding profiles. L4.1 is what bluray is encoded at and is hardware acceleratable, L5 is only playable with beefy computers, and L1 - L3 are for lower spec mobile devices. It's the essence of abstraction. (A TCP stack, for example, removes one's option of sending any arbitrary waveform over an ethernet cable.)
Users who aren't curious shouldn't be punished by being forced to wade through confusing commandline output.
Well, by hiding things away with a click what you do is steepen the learning curve. Users can't do much with the default interface, but are overwhelmed by the advance one. IMHO the better, albeit more difficult, way is to give the user an idea of what's going on, but still be easier to use than whatever you're
But new plugins for the new app shouldn't necessarily be forced to be backwards-compatible.
They shouldn't be forced into being incompatible either. =)
Or you provide a list of plugins, and allow the restart only once all are successfully installed.
Well, I was also using it for plugin development, so basically upgrades were minutes apart, but the bot needed to run each iteration of the updated code so it could be tested. A package manager sending a HUP signal would have worked. However, this requires applications to be written with that in mind, so it's not quite expandable to novel applications. OTOH, almost no application needs to reloading plugins without restarting, so I wouldn't worry too much about that limitation. This just happened to be an odd program.
I would say it's not either-or. It is a bug, and should be fixed.
Looks like we differ in opinion here. I'd see that as sacrificing future improvement for present convenience. If an application is broken, it's broken, and IMHO it'll waste an infinite amount of package maintainer's time to fix bugs with every release that the program author shouldn't be introducing in the first place. Not being able to use the application is inconvenient, but that should be enough to motive the author to improve the code quality, thus a net long-term benefit for a short term detriment.
If OpenWRT used a decent package manager, such a third-party version should be possible to integrate.
This lends itself to explanation using an imaginary Venn diagram. You have one circle representing OpenWRT users, and another representing Privoxy users. There's obviously considerable overlap. Next, within each circle is another, that represents the experienced users of each system. The experienced Privoxy users recognize that the lack of GZip support is a problem, and the experienced OpenWRT users know how to create such a package for OpenWRT. Unfortunately, these two circles have exceedingly little overlap, and the same, rare users are probably in similar situations for an abundance of applications. So there aren't enough of the mythical man-hours to actually fix these problems in a timely manner. IMHO that's one drawback of Linux's diversity; everyone might be working on the same problems, but they aren't really working together.
I don't think this would be a problem for me, personally, but many users would complain about performance.
I'd always figured package management was within the realm of desktop users, where a sub-percent performance difference would be absorbed within unrelated bottlenecks. Servers might be easier to administer using package management, but I'd suspect that causes more problems than it fixes. Example: "Oops, that last update killed the webserver plugin, and reverting isn't an option since the old version can't be installed with the newer versions of everything else present because the package maintainer didn't feel like maintaining the scripts necessary to do so."
Second is time. That is, I have none. I really want to do this right -- that is, I want to do it personally, and I want it to be done right. I don't even have time to half-ass it now.
Tell me about it... I've got like a dozen projects stalled since I chose to go into a field essentially unrelated to computing, and apparently they think free time is wasted time. (Although the dude that wrote free cell was in my profession, so it is possible...)
The point here is not that it's dumbed down, but that it's easier.
Easy is good, so long as it is abstracted in a way that's consistent with everything else. For example, interacting with files on a partition is easier than dealing with the hardware, and basically every application uses that system, so users learn useful conventions. OTOH, suppose three developers feel th
Or you simply decide that once you update the parent application in your distro, new versions of this plugin will only work with the new parent application.
This is arbitrarily limiting compatibility though. And with less compatibility between versions there's a greater risk of incompatible combinations.
So how would you normally load a new plugin without shutting down?
It was written in perl, and essentially did its own package management. Basically it'd download plugins, ask the remote user about permissions, add those permissions to the global settings hash, execute the new plugin within the same process, push back the new plugin object in the plugins array, and call a plugin subroutine to start initial configuration. This method was somewhat necessary since restarts in quick succession (e.g. installing multiple plugins) would get the bot temporarily banned from IM servers, rendering it incommunicado.
I've seen Gentoo add packages within hours.
IIRC Firefox version 3.5 basically never got added. It was hardmasked so long the next version came out.
The advantage of doing it that way is that the distro is at least a central place where you can be sure that one stable release of an app cooperates with another stable release.
IMHO, this is a bug and should be fixed rather than mitigated with package management.
I'm more often a point release away than a compile-time option away, which means I usually only have to wait for the next OS release.
My "favorite" example of this was with Privoxy on OpenWRT. Basically, OpenWRT was lagging years behind Privoxy releases, and didn't enable gzip compression until recently. The problem is that Privoxy can't filter gzipped HTML pages without that option. So the choice was basically disable HTML compression (ten fold longer page load times), or not filter them (thus defeating the point of using Privoxy on 99% of the internet). I waited on this feature for probably two or three years, and attributed the wait to the package maintainer not realizing the importance of the feature.
Your ideas on implementation of a better package manager sound solid. The devil, of course, is in the details, but I see no obvious problems.
How many users do you see with desktops filled with installer exes?
Plenty, but eventually they learn to delete them. Or at least some do and I try to be optimistic in saying that the rest are in the process of learning.
If a package manager makes things harder
Not necessarily harder, but more in line with the Einstein quote you mentioned. IMHO learning is impossible unless you have at least a rough idea of what is going on. Application installation obviously isn't a trivial operation, so if the package manager makes it seem that way then it's too dumbed down. It's fine if stuff is easy, but it needs to be accurate and complete. E.g. having sane defaults is essential, having a plethora of niche options is poor design, and hiding options and major details from inexperienced users keeps them that way.
There are a lot of microorganisms that can give you pneumonia. Vaccines have not been developed for many of them. What you got was most likely a pneumococcal vaccine effective against 23 of the 80 serotypes of pneumococcus. Also, Swine flu can give you a viral pneumonia all on its own. (So can the seasonal flu, it's just more rare.)
A very impressive list of benefits, which verifies that the idea certainly has merit. The primary reason for not doing so that I can think of would lie in script incompatibilities. If something about the underlying OS changes in an update, the scripts may need to be updated. Likewise, if the parent application or plugin changes then you could quite possibly need to maintain scripts for the new plugin version installing to an old parent, vice versa, old to old, and new to new. The number of scripts needed expands with each plugin API change as a factorial. Such a system is workable if plugin API changes are rare (as they are AFAIK), but it can very quickly become impractical given the way it expands.
Fixing applications so plugin systems are consistent would definitely work. It should probably be done anyway. But I'm doubtful programmers will all break plugin compatibility for that reason. And even if they did, there's still the issue of legacy applications.
Can you come up with a plugin system which would be better implemented as anything more complex than either a single file or a dedicated subdirectory in a predictable place?
Easily, but it would be contrived since I haven't seen them in the wild. I suppose I once wrote an extremely modular chatbot that was designed to be fairly autonomous and remotely upgradable. Therefore, it installed, uninstalled, and hotswapped plugins as it ran. Each had mandatory settings (e.g. security level) and as such had to be mentioned in the config file. The thing is, settings were only loaded at launch, and kept internally afterwards, so a shutdown would be necessary for an external package manager to change anything. This would be undesirable given the nature of the program. But that's something I wrote for my personal use and never released, so I probably had a little too much fun when I designed that system.
Except for users in the know, who check add/remove programs first.
Users in the know simply delete the virtual filesystem layer they installed the application in. =P Using the start menu is usually faster than Add/Remove Programs though since it involves less scrolling and you don't have to wait for the list to be populated. Even more so now that Microsoft changed that applet's name to "Programs and Features" so it appears in the middle of the control panel rather than the top.
But that's a criticism of a buggy implementation, not of the idea itself.
Quite true, though I figure that it must be a very difficult problem given how many times I've seen it done poorly.
Logically, I don't like the centralization of application control,
I do, so I have to ask, why not?
Practical reasons: I've seen too many repositories, download sites, and the like come and go to want to rely on them indefinitely. I suppose I could create my own repository but that just complicated my life. There's also instances of when the repository might be bandwidth limited around the release of a popular program, which is also frustrating. Philosophical reason: It takes power away from the user. As a user I should be free to install whatever I want to with minimal difficulty, which would imply consistency in installation.
That's a criticism of the distribution and the repository, not of package management itself.
The lag is a fundamental part of introducing a third party to the interaction. Even if you had an obsessive package maintainer that did nothing but package stuff at 4:03 am with a 5 minute turn-around time, it's still a delay.
That's the kind of thing that it's nice for a package manager to fix.
I think that's something for the application developer to fix. If an application is misbehaving a better option is to not use it and let free market forces/natural selection take place. There is a place for this kind
But the same can be said of many programs, and of things which package management has historically handled -- for instance, Apache modules.
Package managers can certainly handle some plugins, but IMHO it's different enough to make this a very liberal interpretation of the Unix philosophy.
I believe Debian does this with a post-install script now...
That's getting fairly close to each program requiring an installer, and turning the package manager into a download manager. It can be done obviously, but you start losing the benefits of package management over installers/uninstallers.
On the other hand, good software wouldn't require it, under most circumstances -- if the goal is to have separate configurations and customizations to the app, good apps can have this done through configuration.
I was more referring to having multiple versions installed. There are also times that it's beneficial to install multiple times so permissions can be set differently. (That's kinda a hack.)
Some programs have both that and an uninstaller in add/remove programs, both of which ultimately do the same thing.
Same thing, yes, but it's still the default approach of users to check the start menu first.
Really? The last I checked, there was a separate Flash installer for Firefox and other browsers which implement the NS Plugin API. The ActiveX Flash, that is, the Flash used by IE, was a separate program.
You got me there, I forgot flash did that. Java acts the other way though (IIRC, I don't have it installed right now so I can't check). So does the Microsoft Office plugin, and Adobe's PDF viewer plugin.
I'd be curious to hear a criticism of package management which couldn't be answered by either a feature that you don't know exists, or a new feature that we all really should implement yesterday.
On an emotional level, I've never used one that hasn't given me problems. I've learned to tolerate ipkg, opkg, and portage, but I still have to do a lot of extra work due to them misbehaving at times. Logically, I don't like the centralization of application control, the lag between application release and inclusion in the package database, and the arguable disadvantages of having software modified by a third party,
I'd be curious how system-wide updates could be accomplished without a package manager.
I try not to toss out the baby with the bathwater. Program updates and removal are amenable to package management, but I would prefer if installation was handled via other means.
Consistent plugin management certainly has its merits, but I'm not sure if it's quite better. I suppose this is linked with my reluctance to think of plugins as programs that use their parent application as a dependency. The interaction is fundamentally different since plugins don't merely use their parent application, they modify how it works. E.g. ad-block doesn't do anything on its own but instead modifies how Firefox works. Firefox though has little to no effect on how Gnome/KDE/XFCE works, which in turn don't affect Xorg all that much.
As for all plugins basically working the same, I'll give you that most do. Some don't though. PHP sticks out since you have to modify your config file to include modules. There are also issues when you have multiple installations of the same application (package management isn't too amenable to this in the first place). The amount of redundant code is rather minimal beyond having to implement a plugin configuration window since package managers generally don't handle settings.
On Windows I have 10/18 programs that have an uninstaller listed in the start menu. It used to be worse in the past IIRC. Flash and Java are actually several plugins (IE, Firefox, Opera), and Java is also stand-alone so I can see why they'd be in Add/Remove Programs.
I suppose part of my resistance to the idea of managing plugins with package managers is because I don't care for package management very much at all. So I'm definitely biased, and I'll admit I had to stretch a bit to come up with reasons that it's not a good idea. (Logic alone, I still don't think it's the best approach, but it's probably a good and valid one.) System-wide updates is a concept that I love though.
That's an understandable reason, but it's inconsistent with the plethora of other Firefox plugins, extensions, and themes. I would understand if Ubuntu managed all of Firefox's add-ons that way, but it doesn't.
I also wouldn't consider that to be consistent with the Unix philosophy. Firefox includes a tool that does two things, adds and removes Firefox add-ons. That is a different thing than a similar application for Pidgin plugins. If a package manager handled all known plugin systems it'd be a massive tool that did hundreds of different things.
You'd be right about Windows if programmers followed Microsoft's guidelines. Unfortunately, most don't, so the usual method of uninstallation is to click "Uninstall" from the application's start menu subfolder. Plugins are almost never in Add/Remove programs though (Flash and Java sorta are, but I can't think of any other examples). Windows application plugins are generally DLLs dropped into a folder and the only way to remove them is manual deletion or uninstalling the application.
Regedit doesn't delete files, so it'd be somewhat difficult to remove a dependancy. (I mentioned it since I didn't want to delete the file and risk breaking.net or whatever, that wouldn't be done from regedit obviously.)
avoids putting your system in a broken state (unlike regedit),
Using a bit of common sense will prevent breaking your system with regedit either (what would you expect deleting HKLM/Software/Microsoft/Windows to do). If you delete something important, it'll just be regenerated in most cases. In the worst possible case, you can do a system restore to undo any damage you did with regedit. A package manager, OTOH, deletes stuff without backing it up first.
and, if it discovers a problem with the package state, it gives you an exact command to paste into a root shell to automagically fix it (VERY different from regedit)
With regedit it's pretty obvious how to fix the problem. You do the opposite of what you did to break it. No automagic required. More explicitly, you can always undo everything using a system restore. That's generally unnecessary unless you managed to have no idea what you did earlier, didn't export the settings first, and it's one of the few important keys that don't get regenerated.
Regedit and a package manger are very different tools. Regedit is naturally dangerous given its purpose, so there are safeguards all over the place. Package managers make much larger changes to the system, and you can't "undo" anything. You can reinstall if you know what it was that you removed, but there's no "oh crap, make everything like it was before" feature.
Just to see how difficult it is I made an attempt to remove the plugin using the registry editor without consulting instructions. It's trivial, go to HKLM then Software then Mozilla Plugins, highlight it and hit delete. This doesn't remove it from the harddrive, but I'd be hesitant to do so in case of dependencies. People who know absolutely nothing about the registry shouldn't attempt it, but the same goes for people with no knowledge of a package manager (which I would consider to be a far more destructive tool).
Is Ubuntu's package manager so much simpler than looking in a logical location (or searching) in a GUI program and hitting delete? So much so they aren't "remotely comparable"?
IMHO it's ridiculous to require the use of a third party program to uninstall any plugin. How "easy" it is is irrelevant, it's inconsistent.
For anyone who is old enough, has no respiratory problems, and who isn't immunosuppressed, the live nasal spray vaccine is a much more sensible choice.
You need to add: "and isn't in close contact with someone who is". Other than that you're right. Apparently people vastly prefer the injected form though. My guess is that for many it feels more like a "real" vaccine.
Swine flue IS a pandemic. It's not super amazingly deadly, but it IS a pandemic.
I was just listening to a virologist yesterday talk about why the novel H1N1 is not a pandemic. Apparently, the definition of pandemic is "occurring over a wide geographic area and affecting an exceptionally high proportion of the population". Novel H1N1 fails that last criteria. He also explained that pandemic flus replace the seasonal flu because they are so much more infectious, and that certainly hasn't occurred yet (seasonal H1N1 still is far more prevalent than novel H1N1).
OTOH, WHO says that it is, so most people are calling it one. That said, that classification has created a lot of misunderstandings, even at the highest level of policy making. You're completely right that pandemic doesn't imply serious illness. People think it does since nobody bothers remembering the pandemics that aren't serious.
Actually, there is a famous study that did exactly that. In the thirties syphilis treatments were dangerous and questions were raised about their efficacy. So a large study was conducted in Tuskegee. Google it if you haven't heard about the results.
For that reason, modern medical ethics require that your placebo group be given the current standard of care. That's getting the vaccine. If we practiced pure science, this wouldn't be accepted (science is amoral and if everyone in your control group dies that's irrelevant). But, since the point of medical research is to improve upon existing treatments we do this because any treatment that's better than nothing but worse than the current standard is clinically useless. Of course, this raises the question of how the flu vaccine became standard of care without sufficient research evidence backing it up, but that's a different issue.
There's no way this would fly with animal rights. So it'd probably have to be done in China... prompting the question, which rodent is most efficient at gold farming? My bet would be on squirrels.
I'd think that image transfer is rather important, since pictures can usually arouse a greater response than words. E.g. some random dude in Madeupistan says that the fanatical government is burning down schools. What are the chances he'll be believed? Now, how do his odds fair if he takes a picture and sends it?
As for the breakdown of traffic, I must say I'm not surprised. In relatively peaceful times I'd guess that Tor is used much like the internet, i.e. mostly for porn and somewhat for other entertainment. Due to the performance difference most people aren't going to use it for stuff that's legal. OTOH, during political turmoil people become motivated to not just passively consume entertainment and start using it for "legitimate" things.
Not really. A CPU running at half speed uses something like 70% of the power that it does at full speed. So it's better to run at full speed for a short time, then go into power saving mode than to run at slow speed for a long time. This has been called "race to idle", and reminds me of the de facto motto of my old military school, "hurry up so we can wait".
That said, Tom's Hardware did make a pretty big blunder on SSDs and battery life before, even having the gall to start that article with "Could Tom’s Hardware be Wrong? No, our results are definitely correct.". I haven't RTFA, but I'd be quite hesitant to take their word on anything to do with power consumption without carefully examining the methodology of their tests.
No clue if this was part of the rationale, but I'd consider the internet a tool for both speech and assembly. It'd rather difficult to carry on a conversation or assemble if you're not using the same communication tools as everyone else.
I'm not sure if I buy the argument that we shouldn't try to make [bad thing] less [bad] because doing so makes [bad thing] more likely to occur. That argument can be equally applied to developing medical treatments for alcoholic liver disease, metabolic syndrome, or smoking-induced lung cancer. Also, would it be better for police to not try to stop crimes in progress since that makes them less heinous? How about safety devices in cars since they might encourage reckless driving?
Slashdot Mirror
The simple fact of the matter is that the pins on the US plug are so short that by the point it is far enough out of the socket to expose enough of the pins to touch them with your fingers, it's unplugged. No partially insulated pins or other wacky design contrivances are needed.
A US plug can stick out a few mm and still work. That's not enough to touch your finger to, but it's still somewhat dangerous. I once saw a fire in a dorm room start when a guy was sweeping (military school) and swept some kind of bare wire coming out of the radiator across some exposed plugs on a surge protector. It was more funny than anything since the broom was the only flammable thing around. Kind of an odd situation but I try to make sure my stuff is plugged in all the way (difficult with heavy wall warts).
OTOH, I don't think it's really a problem since it basically requires a thin strip of uninsulated metal to become dangerous. Smaller outlets are indeed preferable as far as I'm concerned. I just wish we'd go ahead and switch to DC for normal outlets and leave AC for stuff like appliances and powerlines.
Of course, given that apparently some British folk thought people might do this, I can see why they'd want an idiot proof outlet.
That has some interesting applications. Whereas it might take hundreds or thousands of UAVs/aircraft to locate these balloons, a sympathetic population might very well be able to do it for a fraction of the cost and risk. Who knows, maybe the next time we're occupying a country the military might give out free cell phones to generate a little good will and put the population to work finding our enemies.
The intelligence of the poor is on par with any other population - but the metrics are skewed for culture and training.
I grew up in a very rural area. A large portion of the population lives on SSI and there are very few high paying jobs for those who don't. OTOH, nutrition is better than in most poor areas since many people farm. All that said, a very high percentage of the children are quite slow, and it's apparent in even the lowest grades. I had many classmates that were unable to read even in the eighth grade after years of special education. That doesn't seem like a social artifact nor a lack of education, but genetics. Culturally, being that slow will get you picked on, so it's not like they weren't trying.
The rich ARE evil.
Obviously I didn't want to stay in my hometown school system (3rd from the bottom in the state, and the state can't be rank very high either). So I applied and was accepted to a rather nice boarding school. I was friends with several children from millionaire families, and probably am underestimating the number since they didn't stick out. I.e. there was a stigma about mentioning family income, and there was no definite way of identifying them (grades were average, nobody live in luxury in the dorms, etc.). I hardly found them to be evil.
One thing I have noticed is that the rich almost never admit to being wealthy. In medical school there was a speaker on diversity that asked everyone to raise their hand given their income level while growing up. Now, keep in mind a good portion are doctor's children so 6 or 7 figure family incomes aren't uncommon. When he mentioned poor, about 1/5 - 1/4 of the class raises their hand. Middle class got most of the rest. Wealthy got two hands, one of which broke into tears (her mother had major medical problems so they're poor now). In my high school, one student mentioned that his father was the CEO of [major company] when he first arrived, and was rather unpopular for the remainder of his four years there.
The rich are one of the few social classes most people feel it is ok to hate. It's not really manipulation that causes some people to not do so. It's partially optimism that they will one day enter their ranks, and partially because many feel that successful people deserve praise rather than contempt. That's of course referring to public attitude toward the wealthy that earned their money. The ones that inherited it are kind of ignored since there's too much class mobility in America for wealth to persist for many generations without being competently managed. Not to mention that the wealthiest people in the world all made their fortunes (excluding heads of state).
A fair number of the helper applications manufacturers bundle broke with the upgrade. On my Sony laptop installing the Vista version of the Vaio Control Center will trigger a non-Sony battery detected message at startup and force hibernation. A couple of my friends with tablets report that HP's new Windows 7 compatible tablet "driver" is missing a couple of features.
Species can be defined in four ways (IIRC). The biological species concept is just one of them, although probably the least arbitrary. It's rather interesting, since human classification of animals into species doesn't seem to vary much by culture (e.g. isolated jungle tribes generally group them the same way the modern world does). The problem is scientifically validating the classification since it's more semantics than anything. The lack of gene transfer between species is about the only biological distinction, but even that isn't absolute. There is the rare fertile mule, for example. Viruses can also transduct genetic material between hosts, perhaps different species, although that would be rare and even more rarely heritable.
Basically, there is little chance that Humans and Neanderthals will be called the same species because that's not how they are popularly viewed.
I think it's more a matter of what's important to you. I'm quite satisfied with my JMicron drive despite its faults. OTOH, I was well aware of what I was buying, and figured the random write performance and lack of capacity wasn't that big of an issue for me, whereas performance in all other areas and lowered power consumption were a great improvement for my laptop. So it was well worth the $50 I spent on it.
My anecdote: I've have a 30 GB OCZ Core V2 since December and haven't really had any serious problems with it. Partition alignment seems to be important since I did have some minor stutter on the one partition that was misaligned. OTOH, that was my Vista install so it might not have been the drive. I've installed Gentoo three or four times (everything compiled except for open office), Vista about five times, Win7 Beta, RC, then Retail, and maybe a dozen builds of Haiku. Performance has always been quite good except on the misaligned Vista install, and even then it was acceptable after tweaking. I have never noticed any data loss (or symptoms of it), but IMHO it's far better suited as a cost effective higher performance boot drive rather than long term storage.
There also is a firmware update available that apparently fixes a lot of the well known problems, and many people have reported success with it. Unfortunately, OCZ has announced that they will not release or support any updates for Core V2s, which kinda makes ya wonder why they advertised them as upgradable.
And if he was forced to upgrade manually (without package management), he'd probably upgrade far less often, even when it was a critical security issue.
That is self resolving. If he doesn't keep his box secure then he'll get burned and learn to not do that in the future. That strategy won't work for end users since they don't recognize the breach, and have admins to fix stuff for them, but it should work for admins.
Trivial to maintain with package management. A bitch to check 100 different sites (or subscribe to 100 different mailing lists) without package management.
And how many really should be updated without knowing anything about the update? I figure it'd be better practice to keep the daemons up to date, but don't modify the other software unless there's a really good reason.
To an extent.
For example, if I'm unpacking an archive, or playing a movie, what codecs or decompression tool is used is completely beside the point. The point is understanding that this is a movie, or that this is an archive (and not a folder) if it's going to be unpacked...
That's the thing, in all of those examples some users will almost immediately need to know more advanced details. Video codec choice matters since a) anyone can see differences in quality, b) storage space and download speed come into play, c) not all computers are configured to play all codecs, and d) with moderate quality (or higher) h264 hardware acceleration is essentially a requirement. Archive formats also matter for reason c and b to some extent. Basically, some users have to deal with these issues before they can use those formats, and there isn't a good way to get around some of them.
The ability to tweak each setting by hand shouldn't be removed, but users shouldn't be required to tweak these settings. This is essentially why the "more details" button exists.
That is unnecessarily difficult. It's rare for "advance" settings to need to be configured independently. By allowing that option you're forcing the user to learn about all of them in detail. It's the difference between "ok, I need this set to that, oh, here's something that fits my needs" and "ok, I need this set to that and WTF do I set the other 15 values to?".
On the contrary, I think it helps the learning curve. Immediately exposing users to all details leads to information overload, and the perception that this application is "hard".
Don't expose them to all details, but don't hide all the details either. If the user has to click "Advance Options" to do something then usually the "Easy" interface has done nothing to prepare them to work with the "Advance" interface. IMHO that's more of a lazy practice for when a programmer can't think of a way to make the underlying process any easier except for the most common (easy) case.
So add an intermediate interface.
But even if that is the choice, it's still better that users have the default interface, at least, than forcing users to see the advanced one, and thus driving them away.
An intermediate interface just divides one big problem into two smaller problems. That might work, but it's better to solve the problems entirely. The point is not to always show the advance interface, it's to integrate the options into the default one in a way that retains ease of use. It's harder to do, but it makes for better programs.
The problem is, if the butler generally is easier to use, users will use the butler, and not the tool.
True, although a stupid butler is a very dangerous thing. I'm surprised that the combination of (stupid) AI and programmer foresight is enough that this approach actually works most of the time.
I'm saying the bug absolutely should be fixed upstream. But until it can be, if the package manager can fix it, that's a good thing.
The way I see it, the probability of getting a bug fixed is a function of developer motivation. If users can't run the software then there's lots of motivation to fix the bug. If package maintainers are complaining then it's going to be a lot lower priority. The latter more closely resembles reality, and such bugs rarely get fixed so it doesn't seem like that really works.
But the biggest reason this isn't a problem is, if you've upgraded your server, and something broke -- especially if you don't have the option of rolling it back -- you're Doing It Wrong.
Absolutely true. But I figure the dude with a single linux server sitting in the corner of an office might be tempted to blindly upgrade everything. Servers, for security and performance reasons, should only run the absolutely essential software. That should be trivial to maintain with or without package management. Too much abstraction leakage might cause security or performance issues. OTOH, there is a place for easy-to-administer servers, minor performance differences just wouldn't be an issue though.
The flaw in this is that we're still talking about moving to a "traditional" system, ultimately.
You've honed in on the caveat that I didn't mention for fear of being overly verbose. This assumes that the new way doesn't become wide-spread. I suppose it's good to have confidence, but expecting future applications to emulate yours at the mere design stage is quite bold. OTOH, I suppose innovation requires tradition breaking, but one should keep as much skill crossover as possible.
I'm not advocating that users remain ignorant. I'm advocating that if we want to educate users, we should start by teaching them the things which are most important.
Users, for the most part, just want to get something done ASAP, and try to learn as little as they can get away with. I figure education can't be effectively front loaded, you need to teach it along the way. This method makes no differentiation between major or minor stuff. Actually, what's major and what's minor is entirely subjective and differs with each user.
What's more frightening is, you will probably find that every user uses exactly 27 permutations out of those 1024, but they each require a different 27, and there's no way you could cut it down without pissing someone off.
With that example, each user probably only uses about three permutations, and all the different users combined use the 27. Take h264 video encoding for example. There are a ton of options, and several different user requirements. You can change resolution, bitrate, CBR or VBR, and a great many more advance options. The thing is, every user wants the best video quality possible under their individual conditions. Virtually nobody wants a high resolution, low bitrate file, and if they do they are likely doing something wrong (e.g. assuming resolution is more important than bitrate for quality). H264 specifically gets around this with encoding profiles. L4.1 is what bluray is encoded at and is hardware acceleratable, L5 is only playable with beefy computers, and L1 - L3 are for lower spec mobile devices. It's the essence of abstraction. (A TCP stack, for example, removes one's option of sending any arbitrary waveform over an ethernet cable.)
Users who aren't curious shouldn't be punished by being forced to wade through confusing commandline output.
Well, by hiding things away with a click what you do is steepen the learning curve. Users can't do much with the default interface, but are overwhelmed by the advance one. IMHO the better, albeit more difficult, way is to give the user an idea of what's going on, but still be easier to use than whatever you're
But new plugins for the new app shouldn't necessarily be forced to be backwards-compatible.
They shouldn't be forced into being incompatible either. =)
Or you provide a list of plugins, and allow the restart only once all are successfully installed.
Well, I was also using it for plugin development, so basically upgrades were minutes apart, but the bot needed to run each iteration of the updated code so it could be tested. A package manager sending a HUP signal would have worked. However, this requires applications to be written with that in mind, so it's not quite expandable to novel applications. OTOH, almost no application needs to reloading plugins without restarting, so I wouldn't worry too much about that limitation. This just happened to be an odd program.
I would say it's not either-or. It is a bug, and should be fixed.
Looks like we differ in opinion here. I'd see that as sacrificing future improvement for present convenience. If an application is broken, it's broken, and IMHO it'll waste an infinite amount of package maintainer's time to fix bugs with every release that the program author shouldn't be introducing in the first place. Not being able to use the application is inconvenient, but that should be enough to motive the author to improve the code quality, thus a net long-term benefit for a short term detriment.
If OpenWRT used a decent package manager, such a third-party version should be possible to integrate.
This lends itself to explanation using an imaginary Venn diagram. You have one circle representing OpenWRT users, and another representing Privoxy users. There's obviously considerable overlap. Next, within each circle is another, that represents the experienced users of each system. The experienced Privoxy users recognize that the lack of GZip support is a problem, and the experienced OpenWRT users know how to create such a package for OpenWRT. Unfortunately, these two circles have exceedingly little overlap, and the same, rare users are probably in similar situations for an abundance of applications. So there aren't enough of the mythical man-hours to actually fix these problems in a timely manner. IMHO that's one drawback of Linux's diversity; everyone might be working on the same problems, but they aren't really working together.
I don't think this would be a problem for me, personally, but many users would complain about performance.
I'd always figured package management was within the realm of desktop users, where a sub-percent performance difference would be absorbed within unrelated bottlenecks. Servers might be easier to administer using package management, but I'd suspect that causes more problems than it fixes. Example: "Oops, that last update killed the webserver plugin, and reverting isn't an option since the old version can't be installed with the newer versions of everything else present because the package maintainer didn't feel like maintaining the scripts necessary to do so."
Second is time. That is, I have none. I really want to do this right -- that is, I want to do it personally, and I want it to be done right. I don't even have time to half-ass it now.
Tell me about it... I've got like a dozen projects stalled since I chose to go into a field essentially unrelated to computing, and apparently they think free time is wasted time. (Although the dude that wrote free cell was in my profession, so it is possible...)
The point here is not that it's dumbed down, but that it's easier.
Easy is good, so long as it is abstracted in a way that's consistent with everything else. For example, interacting with files on a partition is easier than dealing with the hardware, and basically every application uses that system, so users learn useful conventions. OTOH, suppose three developers feel th
Or you simply decide that once you update the parent application in your distro, new versions of this plugin will only work with the new parent application.
This is arbitrarily limiting compatibility though. And with less compatibility between versions there's a greater risk of incompatible combinations.
So how would you normally load a new plugin without shutting down?
It was written in perl, and essentially did its own package management. Basically it'd download plugins, ask the remote user about permissions, add those permissions to the global settings hash, execute the new plugin within the same process, push back the new plugin object in the plugins array, and call a plugin subroutine to start initial configuration. This method was somewhat necessary since restarts in quick succession (e.g. installing multiple plugins) would get the bot temporarily banned from IM servers, rendering it incommunicado.
I've seen Gentoo add packages within hours.
IIRC Firefox version 3.5 basically never got added. It was hardmasked so long the next version came out.
The advantage of doing it that way is that the distro is at least a central place where you can be sure that one stable release of an app cooperates with another stable release.
IMHO, this is a bug and should be fixed rather than mitigated with package management.
I'm more often a point release away than a compile-time option away, which means I usually only have to wait for the next OS release.
My "favorite" example of this was with Privoxy on OpenWRT. Basically, OpenWRT was lagging years behind Privoxy releases, and didn't enable gzip compression until recently. The problem is that Privoxy can't filter gzipped HTML pages without that option. So the choice was basically disable HTML compression (ten fold longer page load times), or not filter them (thus defeating the point of using Privoxy on 99% of the internet). I waited on this feature for probably two or three years, and attributed the wait to the package maintainer not realizing the importance of the feature.
Your ideas on implementation of a better package manager sound solid. The devil, of course, is in the details, but I see no obvious problems.
How many users do you see with desktops filled with installer exes?
Plenty, but eventually they learn to delete them. Or at least some do and I try to be optimistic in saying that the rest are in the process of learning.
If a package manager makes things harder
Not necessarily harder, but more in line with the Einstein quote you mentioned. IMHO learning is impossible unless you have at least a rough idea of what is going on. Application installation obviously isn't a trivial operation, so if the package manager makes it seem that way then it's too dumbed down. It's fine if stuff is easy, but it needs to be accurate and complete. E.g. having sane defaults is essential, having a plethora of niche options is poor design, and hiding options and major details from inexperienced users keeps them that way.
There are a lot of microorganisms that can give you pneumonia. Vaccines have not been developed for many of them. What you got was most likely a pneumococcal vaccine effective against 23 of the 80 serotypes of pneumococcus. Also, Swine flu can give you a viral pneumonia all on its own. (So can the seasonal flu, it's just more rare.)
Fixing applications so plugin systems are consistent would definitely work. It should probably be done anyway. But I'm doubtful programmers will all break plugin compatibility for that reason. And even if they did, there's still the issue of legacy applications.
Can you come up with a plugin system which would be better implemented as anything more complex than either a single file or a dedicated subdirectory in a predictable place?
Easily, but it would be contrived since I haven't seen them in the wild. I suppose I once wrote an extremely modular chatbot that was designed to be fairly autonomous and remotely upgradable. Therefore, it installed, uninstalled, and hotswapped plugins as it ran. Each had mandatory settings (e.g. security level) and as such had to be mentioned in the config file. The thing is, settings were only loaded at launch, and kept internally afterwards, so a shutdown would be necessary for an external package manager to change anything. This would be undesirable given the nature of the program. But that's something I wrote for my personal use and never released, so I probably had a little too much fun when I designed that system.
Except for users in the know, who check add/remove programs first.
Users in the know simply delete the virtual filesystem layer they installed the application in. =P Using the start menu is usually faster than Add/Remove Programs though since it involves less scrolling and you don't have to wait for the list to be populated. Even more so now that Microsoft changed that applet's name to "Programs and Features" so it appears in the middle of the control panel rather than the top.
But that's a criticism of a buggy implementation, not of the idea itself.
Quite true, though I figure that it must be a very difficult problem given how many times I've seen it done poorly.
Logically, I don't like the centralization of application control,
I do, so I have to ask, why not?
Practical reasons: I've seen too many repositories, download sites, and the like come and go to want to rely on them indefinitely. I suppose I could create my own repository but that just complicated my life. There's also instances of when the repository might be bandwidth limited around the release of a popular program, which is also frustrating. Philosophical reason: It takes power away from the user. As a user I should be free to install whatever I want to with minimal difficulty, which would imply consistency in installation.
That's a criticism of the distribution and the repository, not of package management itself.
The lag is a fundamental part of introducing a third party to the interaction. Even if you had an obsessive package maintainer that did nothing but package stuff at 4:03 am with a 5 minute turn-around time, it's still a delay.
That's the kind of thing that it's nice for a package manager to fix.
I think that's something for the application developer to fix. If an application is misbehaving a better option is to not use it and let free market forces/natural selection take place. There is a place for this kind
But the same can be said of many programs, and of things which package management has historically handled -- for instance, Apache modules.
Package managers can certainly handle some plugins, but IMHO it's different enough to make this a very liberal interpretation of the Unix philosophy.
I believe Debian does this with a post-install script now...
That's getting fairly close to each program requiring an installer, and turning the package manager into a download manager. It can be done obviously, but you start losing the benefits of package management over installers/uninstallers.
On the other hand, good software wouldn't require it, under most circumstances -- if the goal is to have separate configurations and customizations to the app, good apps can have this done through configuration.
I was more referring to having multiple versions installed. There are also times that it's beneficial to install multiple times so permissions can be set differently. (That's kinda a hack.)
Some programs have both that and an uninstaller in add/remove programs, both of which ultimately do the same thing.
Same thing, yes, but it's still the default approach of users to check the start menu first.
Really? The last I checked, there was a separate Flash installer for Firefox and other browsers which implement the NS Plugin API. The ActiveX Flash, that is, the Flash used by IE, was a separate program.
You got me there, I forgot flash did that. Java acts the other way though (IIRC, I don't have it installed right now so I can't check). So does the Microsoft Office plugin, and Adobe's PDF viewer plugin.
I'd be curious to hear a criticism of package management which couldn't be answered by either a feature that you don't know exists, or a new feature that we all really should implement yesterday.
On an emotional level, I've never used one that hasn't given me problems. I've learned to tolerate ipkg, opkg, and portage, but I still have to do a lot of extra work due to them misbehaving at times. Logically, I don't like the centralization of application control, the lag between application release and inclusion in the package database, and the arguable disadvantages of having software modified by a third party,
I'd be curious how system-wide updates could be accomplished without a package manager.
I try not to toss out the baby with the bathwater. Program updates and removal are amenable to package management, but I would prefer if installation was handled via other means.
Consistent plugin management certainly has its merits, but I'm not sure if it's quite better. I suppose this is linked with my reluctance to think of plugins as programs that use their parent application as a dependency. The interaction is fundamentally different since plugins don't merely use their parent application, they modify how it works. E.g. ad-block doesn't do anything on its own but instead modifies how Firefox works. Firefox though has little to no effect on how Gnome/KDE/XFCE works, which in turn don't affect Xorg all that much.
As for all plugins basically working the same, I'll give you that most do. Some don't though. PHP sticks out since you have to modify your config file to include modules. There are also issues when you have multiple installations of the same application (package management isn't too amenable to this in the first place). The amount of redundant code is rather minimal beyond having to implement a plugin configuration window since package managers generally don't handle settings.
On Windows I have 10/18 programs that have an uninstaller listed in the start menu. It used to be worse in the past IIRC. Flash and Java are actually several plugins (IE, Firefox, Opera), and Java is also stand-alone so I can see why they'd be in Add/Remove Programs.
I suppose part of my resistance to the idea of managing plugins with package managers is because I don't care for package management very much at all. So I'm definitely biased, and I'll admit I had to stretch a bit to come up with reasons that it's not a good idea. (Logic alone, I still don't think it's the best approach, but it's probably a good and valid one.) System-wide updates is a concept that I love though.
That's an understandable reason, but it's inconsistent with the plethora of other Firefox plugins, extensions, and themes. I would understand if Ubuntu managed all of Firefox's add-ons that way, but it doesn't.
I also wouldn't consider that to be consistent with the Unix philosophy. Firefox includes a tool that does two things, adds and removes Firefox add-ons. That is a different thing than a similar application for Pidgin plugins. If a package manager handled all known plugin systems it'd be a massive tool that did hundreds of different things.
You'd be right about Windows if programmers followed Microsoft's guidelines. Unfortunately, most don't, so the usual method of uninstallation is to click "Uninstall" from the application's start menu subfolder. Plugins are almost never in Add/Remove programs though (Flash and Java sorta are, but I can't think of any other examples). Windows application plugins are generally DLLs dropped into a folder and the only way to remove them is manual deletion or uninstalling the application.
It handles dependencies (unlike regedit),
Regedit doesn't delete files, so it'd be somewhat difficult to remove a dependancy. (I mentioned it since I didn't want to delete the file and risk breaking .net or whatever, that wouldn't be done from regedit obviously.)
avoids putting your system in a broken state (unlike regedit),
Using a bit of common sense will prevent breaking your system with regedit either (what would you expect deleting HKLM/Software/Microsoft/Windows to do). If you delete something important, it'll just be regenerated in most cases. In the worst possible case, you can do a system restore to undo any damage you did with regedit. A package manager, OTOH, deletes stuff without backing it up first.
and, if it discovers a problem with the package state, it gives you an exact command to paste into a root shell to automagically fix it (VERY different from regedit)
With regedit it's pretty obvious how to fix the problem. You do the opposite of what you did to break it. No automagic required. More explicitly, you can always undo everything using a system restore. That's generally unnecessary unless you managed to have no idea what you did earlier, didn't export the settings first, and it's one of the few important keys that don't get regenerated.
Regedit and a package manger are very different tools. Regedit is naturally dangerous given its purpose, so there are safeguards all over the place. Package managers make much larger changes to the system, and you can't "undo" anything. You can reinstall if you know what it was that you removed, but there's no "oh crap, make everything like it was before" feature.
Just to see how difficult it is I made an attempt to remove the plugin using the registry editor without consulting instructions. It's trivial, go to HKLM then Software then Mozilla Plugins, highlight it and hit delete. This doesn't remove it from the harddrive, but I'd be hesitant to do so in case of dependencies. People who know absolutely nothing about the registry shouldn't attempt it, but the same goes for people with no knowledge of a package manager (which I would consider to be a far more destructive tool).
Is Ubuntu's package manager so much simpler than looking in a logical location (or searching) in a GUI program and hitting delete? So much so they aren't "remotely comparable"?
IMHO it's ridiculous to require the use of a third party program to uninstall any plugin. How "easy" it is is irrelevant, it's inconsistent.
For anyone who is old enough, has no respiratory problems, and who isn't immunosuppressed, the live nasal spray vaccine is a much more sensible choice.
You need to add: "and isn't in close contact with someone who is". Other than that you're right. Apparently people vastly prefer the injected form though. My guess is that for many it feels more like a "real" vaccine.
Swine flue IS a pandemic. It's not super amazingly deadly, but it IS a pandemic.
I was just listening to a virologist yesterday talk about why the novel H1N1 is not a pandemic. Apparently, the definition of pandemic is "occurring over a wide geographic area and affecting an exceptionally high proportion of the population". Novel H1N1 fails that last criteria. He also explained that pandemic flus replace the seasonal flu because they are so much more infectious, and that certainly hasn't occurred yet (seasonal H1N1 still is far more prevalent than novel H1N1).
OTOH, WHO says that it is, so most people are calling it one. That said, that classification has created a lot of misunderstandings, even at the highest level of policy making. You're completely right that pandemic doesn't imply serious illness. People think it does since nobody bothers remembering the pandemics that aren't serious.
Actually, there is a famous study that did exactly that. In the thirties syphilis treatments were dangerous and questions were raised about their efficacy. So a large study was conducted in Tuskegee. Google it if you haven't heard about the results.
For that reason, modern medical ethics require that your placebo group be given the current standard of care. That's getting the vaccine. If we practiced pure science, this wouldn't be accepted (science is amoral and if everyone in your control group dies that's irrelevant). But, since the point of medical research is to improve upon existing treatments we do this because any treatment that's better than nothing but worse than the current standard is clinically useless. Of course, this raises the question of how the flu vaccine became standard of care without sufficient research evidence backing it up, but that's a different issue.
There's no way this would fly with animal rights. So it'd probably have to be done in China... prompting the question, which rodent is most efficient at gold farming? My bet would be on squirrels.
I'd think that image transfer is rather important, since pictures can usually arouse a greater response than words. E.g. some random dude in Madeupistan says that the fanatical government is burning down schools. What are the chances he'll be believed? Now, how do his odds fair if he takes a picture and sends it?
As for the breakdown of traffic, I must say I'm not surprised. In relatively peaceful times I'd guess that Tor is used much like the internet, i.e. mostly for porn and somewhat for other entertainment. Due to the performance difference most people aren't going to use it for stuff that's legal. OTOH, during political turmoil people become motivated to not just passively consume entertainment and start using it for "legitimate" things.
Not really. A CPU running at half speed uses something like 70% of the power that it does at full speed. So it's better to run at full speed for a short time, then go into power saving mode than to run at slow speed for a long time. This has been called "race to idle", and reminds me of the de facto motto of my old military school, "hurry up so we can wait".
That said, Tom's Hardware did make a pretty big blunder on SSDs and battery life before, even having the gall to start that article with "Could Tom’s Hardware be Wrong? No, our results are definitely correct.". I haven't RTFA, but I'd be quite hesitant to take their word on anything to do with power consumption without carefully examining the methodology of their tests.
No clue if this was part of the rationale, but I'd consider the internet a tool for both speech and assembly. It'd rather difficult to carry on a conversation or assemble if you're not using the same communication tools as everyone else.
I'm not sure if I buy the argument that we shouldn't try to make [bad thing] less [bad] because doing so makes [bad thing] more likely to occur. That argument can be equally applied to developing medical treatments for alcoholic liver disease, metabolic syndrome, or smoking-induced lung cancer. Also, would it be better for police to not try to stop crimes in progress since that makes them less heinous? How about safety devices in cars since they might encourage reckless driving?