I was referencing this sentence: "Sure, I could TRY to convince the company to switch to a completely different application that is incompatible with skype, just because I want to use Linux" Which is backwards because Skype is the incompatible one, not the other way around.

For anyone who actually cares about open standards, it is important to point out the distinction I made. I just perhaps was a bit too harsh on PARENA at the time.

With respect to PARENA, it does indeed look like he's quite knowledgeable (based on his reply to me), but used a slightly poor word choice IMO.

You misunderstand the technologies at play here. It's not that other clients are incompatible with Skype, it's that Skype decided to turn its nose to the standards already established to effectively lock in users. Obviously it worked. If they were using standard SIP technologies this would be almost no story here.

I had a hell of a time when I was looking for an 8-bit PCI network card for a 286 machine. Ended up finding one from someone who had bought a bunch of old computers from a government auction. To this day I consider finding one for cheap an extremely lucky occurrence.

I thought at the time, AT&T was the only one willing to take the iPhone, with all other carriers turning them away. In any case, they still made a killing off the iPhones.

One thing that I think has many web developers excited is the possibility of creating browser based games that are on par with that of computer & console games of 10-15 years ago. Take for instance the Quake 2 port to GWT. Because this uses WebGL, it's purely Javascript speed that matters and not DOM manipulation.

And in the not too distant future, some DRM inside you will disable your movements so you have to watch the ads

Well, in Go you'd have to do:
if( a ) {
  do_a()
}

You'd probably write it this way then in Go:
if( a ) { do_a() }
if( b ) { do_b() }

In Go (no real change except it automatically breaks, not sure if I like that yet or not to be totally honest...)
case A: do_a()
case B: do_b()

Again, the first example in Go is what you'd write here again because it forces the use of braces.

To an extent I agree, but I've also seen some people who also believe that and their code not only looks like garbage, and/or there's subtle bugs because they did something like this (in C):
if( a )
  if( b )
    do_something();
else
  not_a(); // wrong

I personally don't care for this style. I've also never really heard a compelling argument to make me consider using that style. Back to Go, you're in luck with this example because Go doesn't have a dedicated enum. Instead, you use const.
const (
  Red = iota
  Green
  Blue
)

Obviously not the most accurate way to do a benchmark, but just throwing this out there:
# Parrot with it's compiled byte-code
fib(28) = 317811 1.11825299263s
parrot -c fib.pbc 1.12s user 0.01s system 99% cpu 1.130 total
# Parrot
fib(28) = 317811 1.1524600982666s
parrot fib.pir 1.15s user 0.01s system 99% cpu 1.165 total
# Mono C#
fib(28) = 317811 Elapsed: 00:00:00.0094437
mono fib.exe 0.02s user 0.01s system 98% cpu 0.030 total
# Python 2.7
fib(28) = 317811
python2 fib.py 0.36s user 0.02s system 99% cpu 0.379 total
# Ruby 1.9.2p0
fib(28) = 317811
ruby fib.rb 0.13s user 0.00s system 97% cpu 0.136 total
# Perl 5.12.1 fib(28) = 317811
perl fib.pl 0.56s user 0.01s system 99% cpu 0.572 total

In Parrot's defense, they have been putting more work lately into optimizations (ever since Rakudo started to become moderately popular and performance issues came up.) Also keep in mind that parrot hasn't really been at a "stable" version for nearly as long as any of the others this "benchmark" was against. Also, IIRC, the philosophy behind Parrot tends to be, "write the code correctly, then optimize, for its easier to optimize code that's correct to begin with then to try to optimize code that's already broken." Or at least something to that effect.

Anyways, I find Parrot to be an interesting project, that I seriously hope can continue improving so the FOSS community can have a good, general purpose VM to work with (Sure the Mono CLI should be safe since it's an implementation of an open standard, but Parrot doesn't have to worry about even that since it's an original implementation.)

Sure, they control the language, but it's typically not the language (or even a few of the standard libraries) that is of concern since it's an open specification. Where the, "we might have cause for concern" comes in is all the libraries/API that Mono implements that is not part of the standard (the .NET framework for instance.) IANAL, but I think they'd have a hard time with any lawsuit against Mono C#, the VM, and the few open spec libraries. On the other hand, I could see it something coming about for the use of their API .NET. Though, IIRC, I think it might be another hard case since Microsoft has repeatedly given Mono developers direct consultation on various aspects of .NET.

Anyways, just thoughts on the issue. See also: http://www.mono-project.com/ECMA

1) The games themselves will more or less not care about Cocoa because they'll use the least that they can to get an OpenGL window open and usable.

2) Non-issue, if it's closed source and the person who buys it complains about the driver being closed but the game not, there are bigger issues that person needs to work on. The 100% FOSS users obviously aren't going to want either. So again, they're not going to complain that a closed source game needs a closed source driver to work. As for the closed drivers themselves, AMD/ATI are descent (if you have hardware that they support) & nVIdia's Linux drivers are quite good. The OpenGL renderer for the games will likely need little to no changes to run on these drivers.

3) Short answer: yes http://www.wolfire.com/humble http://2dboy.com/2009/10/26/pay-what-you-want-birthday-sale-wrap-up/ Long answer: more than likely. The most common complaint I've heard over the years from Linux users is the lack of commercial/popular games that are only available on Windows (or Windows and OS X)

In fact, what happens is that the formal language uses semicolons, much as in C or Java, but they are inserted automatically at the end of every line that looks like the end of a statement. You don't need to type them yourself.

Javascript programs/scripts often has subtle and often hard to find bugs for this very same reason. Douglas Crockford even calls this feature a design mistake for Javascript, and I see absolutely no reason why the same claim couldn't be applied here as well.

That's just how things go. The not distributing and rolling their own can be hard in situations such as compilers or development tools. Using a different project is always an option, but the same is true in the commercial world. It's the same as choosing a library to use based on the license price, features, whatever. You're going to choose what works best for the project. If not contributing back and keeping the source closed is a deal breaker for the project, GPL isn't going to be an option if you have to release/distribute the program. So you're right, yet, there are still plenty of companies that try to use GPL code without releasing the source till legal action is finally threatened.

It's typically not used as an example of them doing anything legally wrong, just more ethically (in their eyes.) GPL advocates at least want the option of being able to incorporate the changes back into the main line, or being able to make further changes to the code that was forked. Someone in another thread said it quite well: BSD gives more freedom to the developers, and GPL gives more freedom to the users. And you're right, the BSD devs didn't/don't care if their code is used commercially without releasing their changes. It's a non-issue to them because they're developers and care more about making developers' lives easier.

Big programs like Blender, Firefox, some of the more demanding open source games, and others the startup time is quite a bit longer while running through GDB. It's not the biggest issue in the world, but it would at least help. May not be high on your priority list, but waiting 30 seconds for the program to load instead of 10 or even 20 is still a big improvement.

I don't really disagree with that, but I did watch the development blogs as KDE 4 was being developed and they painted a different picture of what the KDE 4.0 release meant (at least to them.) I believe the logic behind it was for a couple of reasons. (These are in relation to KDE 4, and not Amarok or Koffice)

Release early release often. This was a cited reason. They didn't want the development life cycle to drag on for another few years just till a perceived stability of a dot release could be achieved. The libraries were at a fairly stable point. The main Plasma was still basically at a tech preview state when 4.0 was released.

Now, I'm not sure how well KDE would have faired if they would have waited till it was at a stable point before releasing. Because it would have been at least a year more. Some devs said KDE 4.2 was the stable release of KDE. I personally feel it was closer to 4.3. In the time from 4.0 to 4.2-4.3, they received a huge number of bug reports and feature requests. I think at least some of these were fixed otherwise the current versions would still be as bad as early versions.

So, it may have been almost a necessary evil for them to release KDE 4.0 when they did and as they did in order to get the large scale feedback they (IMO) desperately needed. There is also the fact that most distributions didn't even begin to pick up KDE 4 as the default until 4.1 or 4.2.

While not entirely proper, namespaces can pretty much be emulated trivially with objects. So I don't really see the issue here, unless you're one of those people who think that the programming language has to include everything for you to be able to use it.

ECHMAscript has had exceptions since 1999 with the release of version 3. Javascript quite possibly had them even before that. What's the issue here?

If static typing is one of your requirements, then you're correct, Javascript doesn't fit your needs.

What's wrong with how Javascript does prototyped-based OO?

Javascript is actually a pretty interesting language once you learn how to use it correctly. There are just a lot of ways to use it incorrectly (which is how it's used 70-90% of the time.) Anyways, feel free to actually look these features that Javascript has had for at least the last 10 years yourself if you don't believe me (or want to further try to justify your statements.)