The company is presumably going to use the software in-house. Which means, until and unless they do at some point decide to release the software, there are no constraints. They can do whatever they want with it, including modify it without "releasing" the source.

I'm not sure what GPL-ing what will be in-house software gets you, the author.

qBitTorrent is a fantastic open source alternative to uTorrent.

I wholeheartedly agree. The whole point of Gigabit is that one computer can't saturate it. You don't want any one transfer saturating a network.

Conversation I just had...

Hello. My name is Kurt.
What kinda name is that.
German.
Cool! Me too!
You're German?
Czech.
So you're not German?
I am not.
Then why did you say "me too"?
I didn't.
Did the lobotomy hurt?
Where did th ebarn come from?

Well, I'll jump in and say with several polls showing that >80% of users who know about the way to disable tabs on top doing just that, my question is why make the majority of your users jump through the hoop?

If version numbers were just numbers it wouldn't matter. But version number inflating breaks plugins, and Mozilla is going "end-of-life" on previous versions much more quickly now. So instead of getting security patches for a year, you get them for a month. Now imagine you have a hundred, or a thousand PCs to support.

The whole problem is that it's not a just a number. And that's what makes us upset.

Normalizing against dates would work if they kept updating old versions with security patches for a year or so like they used to. But they're not doing this any more. They are going "end of life" on each "major" release as soon as the next one is out, which means you fall behind by a version and it doesn't matter that it's only a month old, you don't get security patches any more.

So sure, normalize against dates to see how "outdated" you are, but if your version is six months old, that's five months of security patches you're not getting.

Mozilla's new system is just simply untenable.

This is still too slow. They need 110816.0830(z)

Intelligent garbage collection is great. In fact, I disagree with what many of the "compiler" fanatics go on about when they say garbage collection is for programmers who don't know how to clean up after themselves. I also agree with much of the rest of your post. However, you don't need a VM for any of it. A VM implemented to accomplish tasks that you need to use a VM for because the OS lacks the support mechanisms is destined to end up along the wayside. And a VM implemented by a company who's bread and butter is operating systems that then uses a VM to accomplish tasks because their OS lacks the support is just sad.

None of what you promote (except for the garbage collection) are advantages of .NET, per se. They are advantages of the MS C# implementation. Rather than saddling people with yet another VM, MS could have added garbage collection into the native API and implemented C# purely native. What a fantastic benefit that would have been.

*sigh* I hate having to explain this every time. Makes me feel old.

What is interpreted? It's a native runtime reading a non-native set of instructions, deciding what to do with it in real-time, and then running native code to execute those instructions.

What is JIT compiling? Well, "Just-In-Time" compiling is compiling just-in-time to run. So it's a native runtime reading a non-native set of instructions, deciding what to do with it in real-time, and then running native code to execute those instructions.

JIT is a catchword euphamism. It came into being because "interpreted" became a dirty word when compilers became available to the masses. It does tend to infer a level of native code caching that straight "interpreters" didn't used to have. The reality is, though, that any good interpreted language has some amount of caching. In fact modern versions of some historically "interpreted" languages that now cache are in many cases labelled JIT compilers vice interpreters.

Keep in mind too that JIT compiler caching, even for the most state-of-the-art bytecode languages, isn't as efficient as many people like to think. Many language structures and primitives require re-"compiling" each time they are encountered.

The reality is, JIT "compiling" is simply a somewhat more efficient interpreter.