It's hard to detect sarcasm on the internet, so I'm going to assume you're serious. :-)

Quite. Only the big studios can afford to license the old films for remakes.

So Disney's big break was with a film based on a folk story written down by the Brothers Grimm - it was out of copyright. Nobody to pay, nobody to clear changes with... Does the modern film-maker looking for a break have such luxuries?

Can any new film maker do what Disney did? Modern copyright probably makes it very difficult indeed, and somewhat risky as there may always be someone who crawls out of the woodwork to sue you after you've done the expensive hard work...

So we are forced to see nothing but franchises and remakes of old films, as they are "safe" in copyright terms.

A great pity.

Everyone should care, because creative works rarely happen in a vacuum.

As I write this, the other replies have focused mostly on long copyright terms affecting availability - digital libraries, Braille editions, audiobooks, etc.

But creativity often builds upon what went before. The longer we lock up works with copyright, the more expensive it can become to create new works - because you suddenly find yourself sued by someone who did a similar thing before you were even born, and believes you stole their plot. Or character(s). Or world.

And yes, people really do sue over these kinds of things.

Imagine a future where only the largest companies can create, because they have "creativity cross-licenses" where they've agreed not to sue each other. Sort of like we have for patents.

Now look at the mess that sloppy implementation of ever-further-reaching patent law has gotten us into.

That's why you should care.

Your example is great, but not that great.

In an ideal world, the information you retrieved would not be in your mailbox. It would be in some kind of document/information store.

People get hit by buses. Or are on vacation when the shit hits the fan. Or just leave the company, and their mailbox is deleted. In your scenario, those are all the biggest risks for the company should there be a repeat of that incident.

Nothing personal. I certainly don't want you to be hit by a bus! But $BIGCORP organisations with short retention periods are usually trying to say "store it where we (the company) can use it, please".

Of course, some departmental managers might then balk at the costs of the document/information store, and not pass on the whole message. All strategies are defeated by human stupidity, given enough time... ;-)

Nope.

All versions between Exchange 4.0 and Exchange 2003 did single-instancing of both messages and attachments.
With Exchange 2007, that changed to just attachments: http://blogs.technet.com/b/exchange/archive/2008/02/08/3404852.aspx
With Exchange 2010, that changed to no single-instancing at all: http://blogs.technet.com/b/exchange/archive/2010/02/22/3409361.aspx

Disk storage space is now addressed by compression of HTML/text bodies.

Thanks for sharing your experiences.

I know what you mean about the SIII's looks. But it's a phone - it's going in my pocket, not on the wall of an art gallery. ;-)

I can agree with this.

I've got a HTC Desire Z, which is coming up for an upgrade on my contract. As a tablet, I have a HTC Flyer (bought at steep discount recently).

The phone has just a touch more than 32Gb of storage used between internal and external combined. The Flyer, with 32Gb internal AND a 32Gb SD card, is doing fine.

I really want a HTC One X. It's a straight up choice between that and a Samsung Galaxy S3. The HTC's build quality is better (mmmm, polycarbonate!) and it has HTC Sense - which I am used to and quite like.
But I know that the moment I move to the HTC One X, I'll have to trim a few MP3s out just to do the migration. Now, perhaps that's no bad thing. It's probably overdue in fact.
But if I buy the Samsung S3, I just throw my SD card in the back and start re-installing apps. It feels cheap and plasticky? Sure, buy a silicon skin from ebay or Amazon. Problem solved.

HTC have released a 64Gb version of the HTC One X, but it's too little too late. As a still newly released flagship version, it'll be much more expensive than the S3 by December/January when my upgrade rolls around.

So currently, I'm veering towards the Samsung. If the HTC One X had an SD card slot, the S3 would get about a second's consideration, then I'd buy the HTC anyway. Instead, I'm buying apps like HD Widgets (in the recent Play store sale) and starting to migrate my widgets from Sense ones to those where applicable.

Sorry, HTC. You've made a phone that's brilliant, but you forgot a very simple feature...

Your argument convinces me!

Oh no, wait, the other one. Your argument has descended into ad hominems and profanities.

Still, I apologise for perhaps not making the context clear. Elsewhere in this conversation - which I assumed you were reading, as you'd dropped by halfway through it - I pointed out that I recently hit the walls of the garden when dealing with some malformed XML files.

Yes, I could just use Get-Content to import the file. But I then still need to rewrite the functionality of awk and sed to filter it down to the data I want.
Why bother when awk and sed are already there?

The malformed file breaks the paradigm, and therefore makes PowerShell a more expensive solution for this problem. By comparison, the very simple paradigm of "text, please" means the Unix utilities did the job regardless.

If all you ever do is administer a Microsoft environment, then PowerShell is great. You'll never step outside that paradigm, so you'll be fine.

I hope that clarifies the issue.

(And by the way, try watching better YouTube vidoes - I find that as the intelligence of the video goes up, so does the intelligence and quality of the comments.)

Not a bad example. As I said, the XML is a bit dodgy. Wrong, if you prefer that word.
There is some question as to why the vendor is writing dodgy XML files for what are effectively summary log files - it's a real case of overkill. It also makes parsing them a pain.
(Strangely they write the normal logs for each process run to plain text files. I can only assume they meant to develop some kind of reporting tool at a later date, but we've seen no such tools as yet.)

If the input is dodgy but the data is still there, then you have to run with what you've got. This is an edge case. And like I've been saying, at edge cases PowerShell becomes a bit of a chocolate teapot.

I suppose I could have written a voluminous script that did it all by manual brute force in PowerShell - but it was easier to reach for the *NIX utilities. I could also have written a solution in VBScript, but I wanted a result that morning.

Whilst you're right that in theory my solution is indeed "really, really bad design" in the real world we sometimes have to deal with really really bad design. You're still thinking like a programmer, and still stuck to working within the paradigm. And as I've been trying to say, that won't always work - because the real world doesn't obligingly stay neatly within that scope.

None of this means that PowerShell is somehow intrinsically bad. As I said, it's much better than what it replaced. But it is limited by its design, and that can be a problem.

I do realise it's extensible.

But you've missed my point entirely. Indeed, you've pretty much proved my point - that PowerShell is an admin tool designed by developers, with a strong paradigm that breaks on edge cases because it's too wedded to its own way of doing things.

You've basically just said "Hey, want to use a new object in your pipeline? No problem, break out a C# compiler!"

How on earth is that acceptable to the average administrator? Some *NIX administrators might relish the challenge - assuming that they have the time - but the average Windows admin migrating from the school of point-and-click that Windows administration used to be is having a hard enough time of it already. Learning C# and development tools (and possibly deployment tools in a larger environment) as well is not a great solution to their edge case problems!

I believe my point stands - that PowerShell is a nice tool, but it's basically a walled garden in which you are constrained to the objects Microsoft wants you to have. By comparison, the rich toolset that Linux has available is far more versatile than PowerShell is now, and perhaps ever may be.

And if we then use your own solution to PowerShell's limitations in the Linux environment - "Just break out the dev tools and write your own extension" - well, we have perl/python/php/ruby/C/C++/Java and many more... You're not making a smart move there. In terms of choice, cost or availability, you're bringing a pen knife to a nuclear arms race. But hey, have fun flashing the blade at folks...

Administrators should be able to throw scripts together, and there's a case to say that good administrators should be able to write small programs. (Where small is, say, under 1000 lines of code in a high level/scripting language.)
But I'm not convinced that it's right to say administrators should be C# developers any more than they should be Java or C++ developers. That's the kind of solution only a developer could come up with...

Which takes us back to what I've been saying about paradigms and PowerShell.

PowerShell is interesting, but seems like a classic Microsoft solution.

By which I mean that Microsoft has some fantastic developers, some great minds - but they work in a very monolithic way. They set out their paradigm (ugh, I feel dirty for using that word even when it's appropriate!) and they stick to it.

So when I'm using PowerShell to administer a Windows environment, it's great. It works really well. For example, the other day I wanted to get statistics for some Exchange mailboxes. With a few pipes of mailbox objects into Where-Object for filtering, and a bit of sorting, and finally outputting to ft, I had a nice little report.

But the reason that the word paradigm is validly used is that the moment you leave their use cases, you're screwed. PowerShell is a very nice walled garden for administering Microsoft products, but for doing anything outside of that it's pretty poor. (So for example if the statistics I wanted aren't served by their cmdlets/objects, I'm straight back to writing a program rather than a script for it.)

This is why I keep UnxUtils - a Win32 port of essential GNU utilities - on my machine at work. Whilst I administer no *NIX boxes at all in my job, and am technically not a *NIX administrator or even close, having grep/sed/awk saves the day a lot more often than PowerShell ever does.

PowerShell is great for day to day admin of the Windows-based products, but the moment I find myself with a non-Microsoft logfile or similar, PowerShell is no longer the solution.

By comparison, the other day I solved an issue with reporting via a (slightly convoluted) chain of grep->awk->sed->tr. The issue was getting statistics from "XML" report files that a process dumps when it's completed. My other options were to write an actual program using an XML library and VBscript/C#/$whatever.
Or to chain together 30 year old UNIX tools to create a CSV file from (slightly dodgy) XML.

I tell no lie when I say that it took me longer to convince Excel 2010 to produce a usable chart from the data after importing than it did to extract the raw data. It was under two hours to get the data out, and a lot longer struggling with Excel's poor interface for multi-axis charting....
And I'm not a UNIX expert - I had to refer to the O'Reilly sed/awk manual several times.

So in a nutshell, PowerShell is a great environment - but it's designed by programmers for one specific environment, and doesn't work at all once you leave their specifications. By contrast, the UNIX utilities are so broad and useful that people are still applying them to uses that the authors probably never even imagined would be possible, let alone probable.

I'd like a PowerShell style UNIX environment, but I suspect I'd still end up calling grep/sed/awk many times within it precisely because an object isn't going to be as useful as I'd like at that point in time.

This isn't to say that PowerShell isn't very powerful and nice - just to say that until it gets a decent set of tools that allow it to step outside its own paradigm and just work with anything it's given, it will always be a walled garden.
(Albeit a garden of national park proportions.)

Define a UX expert.

And then show that they are not biased towards the interfaces that they are already comfortable with.

Frankly, I think that there are few decent UX experts in the world. The rest are commentators and bullshitters pushing their own preferences, and hoping nobody notices...

I'm still on Ubuntu 10.04 as my main OS, but have VMs that are 12.04 for some projects - Unity seems fine to me.

Bugs are inevitable, and without specifics I'm not sure what I can possibly say to change your mind.

My point was that I think that if you find a Linux desktop environment you're happy with, then the rough spots are much more likely to be far outside the desktop owner's realm - hardware support and 3rd party software support.

Desktops are much of a muchness these days. The dark days of CDE/Windows 3.1's Program Manager are behind us, and everything's reached a certain base level of usability that meets 99% of people's needs.
People may quibble over details, but generally we're living in a veritable age of plenty.

My mother can use Linux, and does on her netbook. It's far better than Windows XP on that hardware.

All I had to do to get the netbook to a usable state for her was get the wireless network drivers working. And if you'd given her the netbook and a base Windows XP install, she'd have had the same hardware support issue - and more. And with no CD drive, it probably would have been befuddlingly impossible for her.

But it's running, and meets her needs just fine. She's even connected it to other wifi networks on her own when travelling, and rarely asks me for any help - everything on it Just Works(tm) for her needs.

By such a measure, Linux is a success, and getting more successful each year.

The problem here is the assumption that something is broken.

Generally, the Linux desktop is fine. There is a choice of UIs, sure - and recent developments in KDE then Gnome haven't helped much. Big changes made people say it was broken - but over time, it seems to settle down.

And with the competition (Apple and Microsoft) also making changes to their desktops, Linux is hardly unique here. We seem to be in a time of change, where people have been challenging the old paradigms. Apple are being the most conservative, Microsoft the most radical, Linux is somewhere in between.

Hardware support? Not necessarily a desktop job, but I'll address is anyway. Linux can't do jack here without more support from manufacturers. When I installed Windows 7 on a (then) new Sandy Bridge motherboard, it found NOTHING. It literally booted into a low res desktop with no sound or network. Only the large collection of driver CDs saved the machine - Windows had nothing to do with it.
Support of Windows from the manufacturers was the key factor.

So let's not bitch about Linux's support of hardware - let's get it right, and bitch about hardware manufacturer's support of Linux.

Apps? We've got plenty, and are getting more. Some commercial apps (Corel Aftershot Pro, Sublime Text 2, VMware are ones I personally use) support Linux as well as Mac/Windows. It gets better every month, when it used to get better every year.

And I guess that's my key message. "You've never had it so good". You may not feel that way, but Linux is on a roll right now, and the question is not whether or not it becomes a 'usable second option'. It's already usable.

The question is whether or not it becomes a SUPPORTED second option - by OEMs, hardware manufacturers, and software companies.

And the signs are getting more positive as time goes on.

I've rarely, if ever, had a good reason to encrypt my email. I think the largest number of encrypted emails I ever sent was on a "crash Echelon" day back in the late 90's, which was hardly a good reason. ;-)

I used to sign almost all my non-list emails. (Mailing list software sometimes didn't like signed messages.)
But the problem with signing is that some very dumb (usually big business or government) mail gateways would see the PGP/GPG lines and assume encryption, even though it was just a signature. That meant my mails were being blocked regularly "due to encrypted content", which was a PITA for both me and my recipients to deal with.

Frankly, because of those kinds of issues, I gave up even signing my emails.

I would still sign or encrypt if there was a good reason to, but given my email usage I think signing is more likely than encrypting. And even that would be fairly rare.

It seems that this is hideously lopsided. One out of the six speakers being openly against the bill is an outrage!

Given how much has no doubt been paid by companies for their representation, that sixth person is a bit of a slap in the face. They should take action immediately, and refuse to pay their representatives.

(More seriously, American politics is becoming a textbook on how not to represent the people.)