Ugh. For a site supposedly full of intelligent people, please can we stop repeating this nonsense? Two parties invent something, party A just before party B. Under first-to-invent, if party B files the patent, they can go through all of the expense of filing and then party A can come along and say 'actually, here's my lab record which shows that we invented that first, we'll take that patent.' Under first-to-file, party A can come along and say 'actually, here's my lab record which shows that we invented that first. It's prior art, so we'll invalidate that patent'. The latter is the only sane way of implementing a patent system, because if two people invent the same thing at approximately the same time then there is no social benefit to giving either of them a patent. It doesn't mean that you can patent things that have existing prior art: that's a completely orthogonal bug in your patent system.

You can't fire him. He's a 5-line perl script. All you can do is file bug reports.

False. LGPLv2 does not contain an 'or any later version' clause. The rest of this paragraph is not quoted because it didn't make any sense.

The 'or later' clause is not part of any version of the GPL or LGPL. It is simply a convention that the FSF encourages users of their licenses to adopt. You don't have to modify the license to remove it (which, by the way, you can't legally do because the FSF asserts copyright on their licenses and does not permit derived works).

It's perfectly normal for an embedded system. It is not normal, or sensible, for a general-purpose computing device. It is certainly not sensible for a thing that needs to receive regular security updates to have most of the (vulnerable) code in read-only storage.

And complaining that a 1GHz phone with 512MB of RAM is underpowered is ridiculous. It has far more horsepower than you need to run 4.1, it's only some of the newer apps that will struggle. I had a laptop with worse specs that ran far more demanding applications than anything I'd run no a mobile phone.

Bullshit. The problem is Android's notion of a system application. These are things that can't be uninstalled and must be on the internal storage. Some of these really are system services, but others are just shovelware. The 512MB on the Nexus One is more than adequate for a more recent Android, if you move some of the non-essential crap onto the SD card. The Nexus One came with a 4GB SD card and supports up to 32GB, so there's no reason not to do this, except that then you'd be able to uninstall some of the Google stuff.

This model, by the way, is especially wasteful because often these system components need updating, and due to the design of the Android filesystem layout they can't overwrite the old components, so you end up having to have two copies of a load of stuff installed, and you can't delete the unused one even though that's the one on the smaller storage device...

Once there was StarOffice, owned by Star Division.

Star Division was bought by Sun and the bits they owned were open sourced as OpenOffice. It was then renamed OpenOffice.org once they noticed someone else owned the OpenOffice trademark.

For years, Sun contributed 80% of the new code. Novell contributed about 10% and sulked that they weren't recognised as much as they felt they should be.

Novell started go-oo.org, containing their own patches to OpenOffice.org, including several things that were of dubious legality (e.g. implementing Microsoft patents that Microsoft guaranteed that they would not sue Novell for, but didn't extend this guarantee to anyone else).

Sun bought Oracle and most of the OpenOffice developers left (some voluntarily, others not) and found new employment.

Novell saw this as an opportunity to become the dominant players and pushed the LibreOffice brand for OO.o plus their patches. Lots of people fell for this and LibreOffice started to gain a lot more traction.

Most of the work in both forks is now by ex-Sun people. The code is horrible in both, although both teams are slowly trying to fix it.

LGPLv3 is not actually very different from GPLv3. It was rewritten as GPLv3 + some extra permissions. It is compatible with Apache 2.0, but it is not compatible with GPLv2 or LGPLv2.

This really can't be moderated highly enough. A donation model is nice in theory, but very few people donate. The main reason for open sourcing software is that software is not your core market and you want to lower development costs. Once you open source the code that you are using, even a small number of external contributors counts as a net win. If your business is selling software, then you need some incentive for people to pay you. For proprietary software, it's simple: they can't use it unless they pay. For open source, they can use it and copy it for free, so why would they pay you? Typically, the answer is that they want to be able to influence the direction of future versions, for example by having bugs that affect them or features that they want prioritised.

It's nothing to do with corporate raiders, it's a question of efficient use of capital. A healthy company has a buffer reserve so that they can deal with unexpected changes in the market, but beyond that has most of its capital invested in things that grow the business: factories, shops, ships, that kind of thing. If a company has a lot of cash and isn't spending it then it means that management can't think of anything to spend it on that gives a higher return than just leaving it in the bank. With interest rates as low as they are at the moment that's quite worrying for a company like Apple, which historically has made most of its profits by being an early mover in new markets and claiming the most profitable 10-20% of them before they become completely commoditised.

It usually is, yes. Apple paid off its loans as a publicity stunt some years ago, because the company had been heavily in debt when Steve Jobs took over and paying them off was a way of proving that now it could pay them. That said, the extra liquidity has given Apple a huge advantage over the past few years. When it comes to buying components for their latest gadget, their current strategy is to pay, up front, for the factory to be built and then have exclusive access to its output for the first year of operation at a rate that is sufficiently discounted to offset their initial cost. Companies that don't have enough cash to put up a billion or two for a new factory have to buy the remaining production output at a higher cost. As long as Apple has the liquid cash and the sales volumes, they can produce things a lot cheaper than their competitors.

Smalltalk-80 (well, Smalltalk-76) was the first truly visual development environment, although an honorary mention goes to some Lisp implementations, especially MacLisp (no connection to the Apple Macintosh, although later versions could kind-of run on a Mac, but only using the 68000 as a coprocessor for handling the display and input peripherals, with the real work being done in an expansion card). NeXT was the company that brought the RAD stuff into something vaguely mainstream though, and VB was Microsoft's attempt to copy the NeXT development tools on Windows. As with many such things (not just from Microsoft), they successfully copied the superficial, but largely missed the point.

Why do spammers all have Google Plus or Twitter icons next to their names now? If Slashdot can identify them, why not provide a mechanism for filtering them out, rather than just highlighting them?

A building can be safe for small numbers of people but unsafe for larger numbers. A single narrow winding staircase might be fine for evacuating two people, but be a problem for 10. This is why hotels, private homes, and houses rented for multiple occupancy all have different rules.

It wasn't a totally stupid argument. Cooperative multitasking can achieve higher throughput (on single-processor machines, at least), because you have less cache churn and you can schedule exactly when you want to yield. The down side is that one misbehaving thread can make the entire system unresponsive. Most supercomputing workloads use a cooperative model for this reason: throughput is the most important consideration and all of the code on a given node is trusted.

When OS X was introduced, it ran on 266MHz PowerPC machines. Efficient CPU usage was a lot more important than it is now. I'm typing this on a Mac that only sees the CPU usage go over 20% when I'm doing a big compile job. A little bit of deviation from maximum theoretical throughput is lost in the noise.

JavaScript, as TFS said, has some nice features. It's a pure object-oriented language with first-class closures, prototype-based inheritance and introspection. It's very flexible and really great for rapid prototyping and scripting. The problem is not that JavaScript sucks, it's that JavaScript sucks as an application development language. It has no concept of modularity: everything lives in the global namespace and must be parsed and executed as a linear sequence (modulo web workers). It has no declarative structure: your program imperatively builds the run-time structures. It has weak support for arithmetic: double-precision floating point values are the only numeric type.

Writing complex applications in JavaScript is possible, but so is writing complex applications in assembly. That doesn't make it a good idea.