Agreed, I see red too...

BTW, it's "affects" :)

Circular argument; I take it that you have done both?

Just because an individual states they do not have the competency to verify an action, it does not immediately make the original action invalid.
Source code verification and auditing is a problem in ALL fields, and is not a particular malignancy associated with any particular programming methodology. However, the ease at which one may perform a public audit, and verification, of any code in question is greatly enhanced when anyone can view the code. Furthermore, a closed source audit relies on trusting the entity doing the auditing, with no possible method of performing ones own personal audit unless one is prepared to enter into an agreement with the original owner of the source code in question.

At some point you have to trust something, and trust relies on repeated positive outcomes, or consistent outcomes; you can trust that something will fail in a given scenario, and something can be trustworthy even with known flaws (an aircraft's landing gear has several inherent flaws, but a pilot knows not to fly with it deployed all the time.) In this particular case the system is performing as expected, and the original source code is performing as expected. That several other pool operators deliberately altered their source code, and concealed this from their users and did not publicly publish the code, does not diminish trust in the original system, but diminishes trust in those who thought it would be a good idea to make a system variant that lied about its status and support. They are now paying for their transgression, figuratively and literally, as the correctly working part of the system mops up after their mess.

Curiously, Kim Dotcom saved the day: https://twitter.com/LizardMafi... https://twitter.com/KimDotcom

http://www.washingtonpost.com/...

I agree, and I do work at a school.

Ahh, just spotted what you were referring to, it's a SOP. A supplementary order paper, and in this case it is the one that caused controversy and was not enacted into the final bill: http://www.legislation.govt.nz/sop/government/2013/0237/latest/whole.html#DLM5187401 . I repeat, this SOP is not in force. Such papers are proposals for changes to the bill, you'll see this one is shown to be a proposal by it stating it is so.

So, please be a bit more careful, and link to your material next time :)

Here we have the legislative page: http://www.parliament.nz/en-nz/pb/legislation/bills/00DBHOH_BILL8651_1/patents-bill

Here we have the link to all related bill documents: http://www.legislation.govt.nz/bill/government/2008/0235/14.0/versions.aspx

Additionally here we have a link to the "live" bill currently in force, this is the passed version, 235-2: http://www.legislation.govt.nz/bill/government/2008/0235/14.0/whole.html

If you note Section 15, 3A, it still says the same. This is what is known as a trump line, in that under the currently in force legislation software is an invention which is not patentable.

I would be most interested in linked examples of what you are referring to, because I certainly have not found it on the government legislative website so far, so that a more informed debate may occur.

It's a bit too early in the piece to see the legal ramifications at this stage, but I'll give you a brief outline of what would most likely happen in this environment:

"A system comprising a computer with a touch-sensing display, and a program running on that computer such that gesture A causes the computer to display blah blah blah" ; this is actually two separate things, one is the physical hardware which is a device capable of sensing touch. The program running on the device that performs other actions in reaction to the manipulation of that device is considered software, as it may be substituted at any point by another program that can interpret the gesture differently.

The real interesting bit is actually the touch sensing display, which would be a device with embedded software that provides a basic API for positional feedback. If the embedded software provides gesture recognition as part of the panel, independent of the computer, then you have something that would probably be patentable. This would not stop someone creating another panel that could sense touch, but leave out all of the embedded API to the point it only provided RAW touch output and had to rely 100% on a software implementation for the rest; in that case you can patent the panel, but the software would be covered under standard copyright. In each case the software can be considered independent of the panel, except when the panel itself provides feedback to a computer as a result of embedded software [even then it has to be considered in it's entirety, not as independent bits, and would be trivial to get around.]

Now there is an older article here: http://www.iitp.org.nz/newsletter/article/430 Where if you look down to "The New Amendment", keyfeatures, point 4 you'll get the gist of where we are at. There are probably better sources and articles, but unfortunately I don't have them to hand right now. Key thing to remember is that it's all untested at this time, wait and see :)

*sigh* I am in New Zealand, and yes I have read and understood the legislation. For full disclosure I am also an Associate Member of the IITP, one of the groups who pushed hard to get this mess sorted out.

Most people skip the most important line which reads:

"A computer program is not a patentable invention." Section 15, part 3A: http://www.legislation.govt.nz/bill/government/2008/0235/latest/whole.html?search=sw_096be8ed8054d616_computer+program_25_se&p=1#DLM1419225

Now, is that unclear to anyone?

Quoting from the article "Gold is used for connectors because it does not oxidize quickly, and because of its high electrical conductivity; however, when mixed with solder that contains tin, the gold and tin can combine, making the combination brittle under certain conditions."

You are right, it is a mere part of the original dice article at: http://news.dice.com/2012/12/10/linux-virtual-private-server/ . It also does not help that the HowTo was written by someone who really does not fully well know what they are doing, and it is this sort of thing that catches out people trying to learn how to do things properly. What would help, though, would be if the guy actually got someone who knew what they were doing, and added those bits to his article so it was more complete [this is where a more collaborative blog is essential.]

For the record my first VPS was a pretty interesting beast at nosupportvpshosting.com, where you have to know what you are doing or suffer the consequences [I quite like them because they keep out of your way, plus I use it mainly for self-education purposes.] The HowTo at dice pretty much glosses over the security issues with a non-adequate solution in my opinion [if you have seen the nasty stuff flying around recently then you'll know what I mean.]

We seriously need King Kong with Biplanes placed on the Empire State building!

"including one that allows soldiers to track colleague's locations on the battlefield."

Now, lets say I am a soldier that has just been killed. My device does not know this, but the opposing force does. They pickup my phone, start running through a list of who is on the battlefield, and designate where their snipers need to aim.

Alternatively, opposing force finds device, and now appears on the location system as the soldier. This could be a bit of an issue if they send a message via it for everyone to regroup... or medical evac. I can imagine a well booby trapped body for that.

My point being: convenience is very nice, but deactivating it on death is vital. This is not something you'll get off-the-shelf, but can be as simple as a plugin heart monitor with password reset in the event of no pulse.