This is why so many projects require contributors to sign over their copyright when they commit code. They want to retain that control over the licensing centrally.

Copyright assignment is a speedbump in the road that helps to prevent contributions though. Many people are uncomfortable with the notion that their freely contributed work can be taken into a closed project. Many more people are just uncomfortable with the paperwork you need to do.

You only have to look at what happened to OpenOffice when it forked. OpenOffice kept the copyright assignment clause. Now the project is dying in a garden shed in the Apache server farm. LibreOffice ditched copyright assignment and behold, it thrives.

I can confirm that's true. Digging out the driver disk when you reinstalled was a total PITA. A lot of the secret sauce on the card was software, without DRM controls their earlier hardware could probably have been pushed to have most of the features of their later models.

The Linux drivers just work though. I remember booting Linux on that hardware the first time and seeing a colourful SBLive banner in the bootup messages and thinking "Huh. It works!"

Not to shoot out of them. To produce images in them.

At least one piece of science fiction I've read has eyeball lasing cells in it. Now it seems less fictional.

You do need special considerations for XML files though - there are several solutions

The weakest solution is to rely on the ability of the target user to spot diffs and correctly merge XML files. And also not to use automatic merging, ever, because the nature of XML files means that conflicting changes may not occur in adjacent lines.

---

The next (and inadequate) solution is to order the XML consistently - you can do this in your diff tool, or you can write your tools to produce a reliably ordered file in the first place.

Many tools that work on XML files exhibit what I call "juggling" - the elements and attributes change order when you change the value of them or their siblings, because the software is directly using the DOM to manipulate the file - and does this by creating new objects and removing the old ones from the collection. This is a real PITA for text-based diff tools because not all the changes will even conflict with each other (element sequences are often spread across multiple lines, more so if you put attributes on their own line to enhance the ability to merge).

So, you can either write your code to write a consistent order - usually by serializing a fresh XML stream from a model when you write the file.

Or you can add a layer that re-orders the document when you diff it - many of the available diff tools will let you do this. For some files, I used to write an XSLT sheet (to re-order elements consistently). For attributes, I wrote an extra option for Tidy that sorts attributes - doing that plus laying them out on separate lines is sufficient for many files. I've gone as far as writing custom tools that unpack HTML written into an attribute (with all the escape sequences that entails) into a CDATA section for clarity, runs it through Tidy, and then repacks everything after you're done.

---
Intermediate : I've thought of taking this a step further and converting the XML to a directory tree of text files designed to merge well, principally to make things clearer for end-users who currently have the kind of diff-tool-plus-converter described above but still occasionally make merge errors.
---
The next step is to write tools to specifically diff your model. This is probably a bridge too far for most developers, because we have the kind of brain that can abstract a text representation of the model and map it to the actual model that will be created. For end users, it may well be advisable.

Diff / merge tools are a field that need more work - currently the main users are developers who can cope with them being a bit immature. But we will increasingly see collaborative tools based on the kinds of version control that we take for granted, and normal users will need to be able to do this stuff too.

> no more free development for .NET 4.6 with visual studio

Community supports the vast majority of useful features... and really, what's the problem with it costing money if you want more than 5 developers or have a $1M+ turnover company? You're still allowed Community if you're using it for classroom learning, academic research, or open-source development.

If you're working for a company that presumably makes money from writing software (in one way or another) is it really so bad to give some of that money to a company that helped you do that with their product? If you hire a developer, their salary is far more than the $1,119 it will cost you for VS Pro with MSDN ; do you really want to waste their time by making them write their code with a text editor and build it with just the .NET SDK tools?

I usually prefer SharpDevelop for my .NET dev but I've not done any in a long time - I'd be inclined to give Visual Studio a go, even if I've found it's prior iterations to be far too handholding and patriarchal.

And the most depressing thing about this?

It basically excludes new players from the market. Only the big firms have the resources to go through all that compliance paperwork. Which means the only people left are the lying, cheating, scum that caused the problem in the first place.

This has only fostered a risk-averse mentality that chokes every aspect of government and big business. No wonder it's the small firms that have the reputation for innovation - it's because they still have their innocence and aren't wasting 95% of their energy looking over their shoulder and checking up on things to cover their asses.

They already have by far the best remote-desktop service. [1]

A screen-recording tool just needs to be able to serialize the stream that RDP uses to disk - very efficient, very conservative of space. I can't believe that the Linux RDP tools don't already do this.

[1] "Best" as in - works, works well, has low latency and the tools are easy to get hold of and set up.

NX or whatever it has evolved into was very good in terms of performance, raw X11 blows over a network (which is ironic given that's part of it's design brief and one of the principle things holding back the Linux desktop environment for so long). Neither are easy to set up or use.

Stronger for everyone except them, perhaps.

They did something similar, put a couple of specific constants, into the Dual_EC_DRBG random number generator. It was later shown that they amounted to a skeleton key - if you knew the numbers used to derive the constants, you could predict the future output of a given RNG instance with only a small amount of sample data. So any encryption based on Dual_EC_DRBG could be considered to be broken by the NSA (somewhat conveniently, in a way that only the NSA could actually prove).

Despite the poor performance of this algorithm which lead most implementers to ignore it, it managed to end up as the default in the product of one of the most trusted vendors, RSA. There was speculation that the NSA bribed them to make this design choice. [1]

Unsurprisingly, it was withdrawn from the standard in 2014.

[1] The only comment on that story makes the same point - that the NSA, in the past, had reinforced weaknesses in DES. In the light of the later evidence about Dual_EC_DRBG, that may bear further examination - if the change was the tweaking of constants, it's entirely possible that this reinforced the standard for everyone but the NSA.

People use the engine behind LDAP servers as a database.

LMDB

This has been true in the past, but now automation is improving faster than people can retrain and the economy can expand.

The most common job in the USA at present? Truck driver. (well, maybe not, but still, 2.8M truck drivers - 1.5% of the entire working age population in the USA, earning an average of $51,000 apiece)

Imagine how that one's going to go down when automated trucks are viable. Haulage firms will push HARD to get them approved to run on the road - they're already running them on private land (like in the Alberta tar sands, where the robot trucks are safer and require less maintenance and burn 25% less fuel, aside from working all day and all night and saving the company millions in wages).

Almost overnight, unemployment will bump another 1.5% in the USA, and all that money that was going into the economy via truck driver's wages will initially go into the pockets of very rich people before prices adjust.

What are the truck drivers going to do instead? Their life of sitting in a cab knowing the best route and which diners have the best cheese-steak sandwiches isn't going to prepare them for a life in many other professions, definitely not any that are paid as well as $51,000 ; they're certainly not going to get jobs building robot trucks (by definition - if the number of people you're employing to make a more complex and expensive machine is anywhere close to the number of people the machine replaces, then it's not economically viable - so even if someone invents an edumacatatron to fill their heads with robotics engineering, ain't gonna happen).

They won't even get jobs as greeters in WalMart because those jobs are so hotly contested by old folks.

AirBNB has more rooms on offer than Hilton. Hilton employs 152,000 people, AirBNB employs 800.

The trucking industry will likely in the next decade go from having 2.8M drivers in the USA, to zero, and maybe 100,000 or so skilled robot repair mechanics.

Amazon will go from using people as robots in it's warehouses, to just using robots.

Even if people eventually benefit from all this, there are going to be some dark times.

No commercials on Netflix here in the UK - I guess having an ad-free public broadcaster of world-renowned quality forces the other market players to raise their game (we have an average of 12 minutes per hour rather than 18 on our other FTA networks).

Given that most of the costs must be for content, imagine what the USA could have with a similarly funded ($19 a month) public broadcaster...

McDonald's have experimented with this - people forced to clock out when the restaurant was empty because "they weren't working".

"Fairtax" is regressive. The rich love it, because it's a sales-only tax, and they spend less as a proportion of their income than anyone else. Who spends more? The poor.

We've had periods where McDonald's employees were directed to clock out if there were no customers in the restaurant, because they "weren't working", so it's almost literally true.

And there's definitely no cliché of the starving actor at all.