That markup also makes the document more comprehensible to users of gui displays.

No, really.

The gui mail client markup is so catastrophically bad that the text mode stuff is much more understandable. People freuqently are impressed by the clarity I produce in mutt using vim as compared to all my outlook-weilding cavemen.

Are you at SUNYA?

Btw, the economy may seem horrible in Upstate New York (because it is) but there are other parts of the country doing a lot better. Don't set your sights too low.

If you can't see that this is DRM, ask yourself:

Is this game fundamentally multiplayer? (If you don't realize it isn't, you certainly haven't played it.)

Once you realize there's actually almost nothing multiplayer about it, ask yourself why you can't just play offline.

At this point, you realize it's DRM.

Yep, it's DRM.

It's DRM that they can plausibly convince dupes that it's not because it theoretically has some utility value.

Don't bee fooled, or be a fool.

You clearly didn't read my post, nor understand the issue.

We didn't choose to do the smart thing, so our needs are irrelevant.

I'm in regular contact with a larger percentage of large enterprise IT shops, probably over 20% of the total base of sizable IT departments, and I speak from the experience of what *they* choose.

Meanwhile, if you need to deal with virtualization management at large scale, vmware is worse in terms of staff efficiency, because you can't do custom automation in a reasonable way.

Your numbers are about optimization for some medium-sized business, and it may well be the right choice there, but that's just barely "enterprise".

Enterprise customers have been using a wide variety of linux virtualization solutions for many years now. Virtuozzo, kvm-based systems, xen based systems and many others are the norm. It's only people who seem to have more money than sense who standardize on vmware.

They're the new version of "let's store everything on netapps".

FD: my company makes both these nonsense choices, but most of our customers don't anymore.

Straw man. I didn't claim that my choices mean those things.

I claimed that my choices CLEARLY DELINEATE theft and copyright infringement.

Meanwhile, I cannot choose not to copyright things (this is the correct spelling), as all creative works are copyright by default in the modern era.

I can, however, choose what to do with my rights.

You have the straw man.

Duplication is copyright infringement. Theft is removal. That was my point.

You have yet ANOTHER straw man when you claim that I said duplication is always okay.

Then you have ANOTHER straw man when you claim duplication is counterfeiting, which it's not. That's when you PASS OFF replicated physical items as if they are goods produced by someone else.

So.. My score 0, for not saying anything insightful, but nothing wrong either. your score: -3.

It seems you are suffering from a form of mind control where you believe that property and "intellectual property" are the same thing.

Let's break this down. I am not going to give you access to take my things.

I'm happy for you to make duplicates of any information I have. For example by hearing the words I speak or reading the words I type, and saying them later.

I could have copyrighted various code I wrote on my own time in a way that denied access to others, but I've never done so.

I could participate in the patent program at my workplace, but I do not do so, and encourage others not to do so.

I don't own any "IP", so you are welcome to all of it.

Granted, I'm not a writer, or a musician, or what have you, so this issue does not strike terribly close to home, but all I wanted to do was deconstruct your silly "let me steal your stuff" false equivalence that you attempted to draw.

Yeah, I tend to notice them when they use a significant portion of my bandwidth.

Sure hope you:

* Make it possible to disable or alter password expiry policies. This sort of thing just pushes people to put them on paper.
* Do not use UPnP without customer authorization.

Otherwise, I wouldn't really trust you / want to use your things.

Well, it's definitely distinguishable.

Gnome has built, at the application layer, services which exist in ram, rather than loaded by library name. And they've done this in a way that does not have runtime versioning.

They've basically re-created the pain of DDE/OLE.

Granted, it's the same era of error with the same level of foolishness, but it's a slightly different problem.

It's not like this has newly surfaced though. In early days of gnome (2), bringing up a gnome program without going through the "proper procedure" would result in it not being able to locate the runtime support of other processes, such as configuration management daemons. This meant that programs run could behave bizarrely and fail to work without any error emitted or any mistake on the part of the user. It all stems from assuming that the whole runtime environment is the one you imagine it to be without taking any steps to test for or create that environment, or deal with any problems your design choices have caused.

In short, gnome (and kde) are rife with this kind of sloppy design and pretty much always have been. Acting as if it's some kind of new development is sort of missing the boat.

Packaging is pretty independent from policies surrounding dynamic linkers and installations of soname objects.

All unixes, once dynamic linking became prevalent, pretty much did not have this problem. Unixes which died not embrace dynamic linking also did not have this problem.

No, we have volcanoes. See: http://www.nationalatlas.gov/dynamic/dyn_vol-ca.html

Just because they haven't been active lately isn't any terribly good guarantee for volcano timescales.

However we are completely lacking in hurricanes, also blizzards (unless you go pretty far up into the mountains), and tornados.

The usual suspects like floods and fires we have, and more than the country's share of earthquakes. Also more than our share of infrastructure issues.

Wrong.

DLL hell referred to a problem where all apps installed their private DLLs into shared system directories.

This meant that apps would collide their dll files, and break each other.

In UNIX/Linux, shared libraries (.so) always were installed with versioned filenames, so multiple versions of the same dll could be installed and the system could deal with it.

Additionally, in UNIX/Linux, apps did not install libraries shared between projects on install. If building from source, you would simply build the dependencies first (separately), which meant there would be no collisions, though it did mean that installation took a bit more work.

Thus, UNIX/Linux never had this problem of apps breaking each other on build and install. Sometimes, build and install might be trying, and there were a few libraries which did not do the versioning correctly (mostly libpng), but those were just bugs. In the meantime, those small number of bugs have been fixed.