Mod the AC up.

Oracle clearly wanted the vertical stack due to support problems with Oracle on Linux. Remember "Oracle Linux"? Having a OS and application framework (Java) built for Oracle DB gives them a huge advantage. Imagine if they tie changes to J2EE to Oracle DB implementations (they own the 2 open source competitors), this will completely lock out competitors like DB2. This is already largely true. AIX+DB2, Windows+MSSQL, and Solaris+Oracle are the 2 big platforms.

It's extremely unlikely this group has any connections with Iran whatsoever, ad hoc or otherwise. Iran simply doesn't have a big hacker community. This is almost certainly an international group (maybe in China) that is using the recent Iranian cyber attacks as a "cover" for the typical hooliganism.

This is actually less likely than people seem to think. Courts (and more importantly, police) have tended to allow for the unsecured/cracked wifi defense because hackers/bad people tend to use them. For example, Downloading child porn. Botnets. etc. The innocent bystander defense usually works.

If someone has vacant rental home and meth heads break in and set up a secret lab to "cook" meth, the homeowner is not responsible for their actions. He's as much a victim as anyone else.

Your real question is:

Convincing Your Employer To Go With Plone?

The answer to this depends on how good your organization is with Zope/Python. If you have onsite developers with Zope knowledge (who can support Plone), Plone is a no-brainer. And if you have developers familiar with other OOS software like Java, you have plenty of other products to choose from:

http://en.wikipedia.org/wiki/Category:Open_source_content_management_systems
http://www.cmsmatrix.org/

If you don't have any onsite development staff, the value proposition of OSS/Plone goes down because you will presumably have to hire someone to run it.

Frankly, that's what I would stress. If this is a large enough project you're going to have to hire someone to run it anyway. You can save on software costs by hiring someone who knows Plone.

If you're not hiring new staff it boils down to who within your organization is running the CMS and what THEY want. Most other considerations are relatively trivial. The more "out of the box" they need the software to be, the more that leans towards a proprietary solution. They might also want to be able to have a vendor to complain to and to provide direct support, again, proprietary has an edge here.

Popularity also factors in. I don't really know how popular Plone is, but Confluence is really popular. That means there will be lots of online resources (forums, FAQs, etc.) for Confluence that you might not find for Plone.

You need to understand something about "momentum" in police investigations.

The police are already 100% convinced by their investigation (mostly guessing) that this guy is a child rapist. There is literally nothing he can do to change this opinion. So, for the police, this is now about "pinning" a charge on him.

Since they are already convinced of his guilt, any new evidence the police obtain will be used to pin SOMETHING on this guy, even if has nothing to do with the original charge. So it's possible that there is no child porn on the partition, but if there is pirate software or whatever they will charge him with theft, etc. all the while telling the judge he's really a child rapist. Or worse, they'll lie and claim they found child porn on the computer.

Not giving the password actually protects him from (likely) false evidence because his defense can show they haven't been able to encrypt the data. IOW, it limits their ability to plant evidence somewhat.

Even if you think the above scenario is paranoid and unlikely, it doesn't change the fact that it's probably his best strategy whether he's guilty or innocent of the specific charge.

Cost benefit analysis crops up here. If the drive contains child pornography or other material that would net the target a long prison sentence it would make logical sense for him to "forget" the password because the penalty for perjury is much lower. This doesn't protect against likely rubber-hose decryption (using violence or coercion to get the password) which is very likely in most scenarios. This is the one case where the weren't willing to torture a little kid.

A better solution is to have a self-destructing system that eats itself when you enter in the wrong password x number of times. Give the investigators a bad password and let the data eat itself. With the data gone, rubber hose decryption is defeated.

Hardware wasn't ready. DirectX 9 video cards were too expensive for entry level systems at the time of Vista's launch so they couldn't run Aero, the new Vista UI (and one of it's primary features). This led to the "Vista Capable" debacle. Entry level hardware has been fully DirectX 9 capable for a few years now.

Also, Vista introduced a new driver model (for various reasons) which left many devices unable to work on Vista without new drivers, which many hardware manufacturers simply didn't make. Often all they had to do was add 1 line to a config file, but they still wouldn't do it because they wanted to sell NEW hardware. Again, now that a few years have past all new hardware comes with Vista drivers.

There is no reason to do this. The performance gap on entry level new hardware between XP and 7 with Aero disabled is less than 10% (if that) and stability and security is vastly improved in 7.

You do know there are OEM versions of 7 that bypass activation, right? And installing a site-licensed Windows XP Professional Corporate version on home PCs is software piracy. If you're going to pirate Windows anyway, why not just download a cracked version of Windows 7? You're going to need a crack anyway since XP Corporate doesn't bypass WGA, which you need for updates.
OEM and Retail pricing for XP and 7 is pretty much the same, so if you're going to pay, you won't pay a premium for 7 and you can get cracked versions of 7 just as easily as XP.

In the sense that he uses reason and foresight to determine what makes himself the most money, you're correct.

"Inner operating systems"? I think you're confused. The core problem is that Apple won't allow 3rd parties direct access to hardware or to use their own toolchain, they must use Apple's interfaces. If your application runs sub-optimal using Apple's interfaces (Flash, as one of many examples), it sucks to be you.

I'm sure your upscale American university is completely representative of the streets of Mumbai.

[quote]If I get to a site that requires Flash, usually, I just close the window. I can't imagine I'm alone in this.[/quote]

Well, either your position of refusing to use Flash is not widely held OR there is a massive conspiracy involving all world media and most of the world's population to make it APPEAR that Flash sites are really popular. I think the former is more likely.

I don't see how having the capability limits your choice. If you know sites with Flash are crashing on your device you can choose not to visit those sites. Or you can disable Flash and view those sites. I really fail to see how having the option could possibly harm the user.

Also: Do you really try to apply this argument more generally? For example, if one downloaded application crashes on your iPhone do you never download and install an app again? Even if you don't want to install apps (which might crash your phone), how does having the capability to download apps harm the user? (excluding troyjan and virus risks)

I'm not sure how pointing out that the proprietary iPod/iTunes relationship is similar to the proprietary XBOX/Halo relationship supports your argument that Apple is "open".

I'd also argue that this is unfair to Microsoft. Microsoft's comparable product, the Zune, doesn't force users to use the Zune software or web store. You don't have to do so on the XBOX 360 either.

"That's why there is a Graphical tool for everything in Ubuntu."

No, there isn't. That's, in part, why Linux Mint exists. To add graphical tools to areas Ubuntu doesn't cover. And Mint doesn't get everything either. Last time I used Mint, I had to use the CLI to configure various multimedia crap and Samba (and other stuff). This was to do the incredibly complicated task of playing a video file over the network.

"On a not so rusty machine it take less than 20 minutes (compare this to installing Win7 !!!)"

20-30 minutes is the average install time for Windows 7. More importantly, it's a lot easier than it used to be. Install process:

1. Boot PC with Windows 7 disc in drive.
2. Click "Install".
3. Enter user name and password.
4. You're done.

The Windows 7 installer is vastly improved.

CLIs are not easy to use. They are hard to learn by almost everyone, therefore they are not "easy". CLIs can very often be faster and more convenient for learned users, but that's not the same thing.

Yes, in your example it is somewhat faster for a tech support guy using email to send a command (especially a long command with lots of flags) to a user and tell them to enter it in verbatim. This is a great system if you want a tech support guy to literally hold the hand of the user through every minor configuration. Frankly, if you're going to do this just SSH in and do it FOR him. It's the same thing.

There is a "past" that existed before there were GUI operating systems, and these systems were NEVER configured by "average users" at all. First off, the "average" user was a full-time computer professional. They, as full-time computer operators, did pretty well with CLI. Look at a more realistic example, like dumb terminals connected to an IBM running MAS90 accounting software. Ask those accountants how easy that CLI is to use. Ask them how much they like function keys and having to remember arcane character sequences.

When using a CLI you essentially have to learn a completely different language. "sudo", "cpuspeed", etc. are hardly obvious commands (let alone options and syntax) you could somehow guess. The "average" user has little talent or interest in learning obscure "CLI languages" (that's why they're not computer professionals) which means that, in practice, he'll have to laboriously look up the every single command, and it's syntax and options, every single time he wants to use it. This is simply not faster than clicking through menus with item descriptions, even a bunch of menus. Yes it might take more time than using a CLI command, but it will take a lot less time than LEARNING the CLI command.