:wq ... nuff said!

Seems to work for the US military *ducks*

It's called the law of diminishing returns, and applies to nearly everything sadly

Two things:

1. The cost of MS license in the third world is really high comparatively, even with academic and non-profit discounts. I've worked at a school in South Africa where the licensing costs of a small lab could have hired an extra teacher. You don't get academic/non-profit discounts if you buy once-off licenses, to get those you've had to go with subscription model since at least 2003

2. The support offered by Microsoft at the school did not cover desktop support, or if it did, that support was so slow in coming as to be useless. That's one reason I had a job. IN this case using off-the-shelf software carries no support advantage, and little usability advantage. Chances are nobody at the school can use a Access, or even excel particularly well. From the original poster suggestion of running it on a VPS I assume they have internet, and are probably more familiar with a browser and word than excel.

All that said, the idea of just using a spreadsheet makes a lot of sense. From a reporting perspective, it makes life easy, and getting data to UNICEF et al is as easy as emailing a copy. I'd avoid Microsoft though, and go with libreoffice.

If you are into learning, and don't already have a specific goal you can work towards, I strongly suggest re-inventing the wheel, specifically the file manager wheel, it covers a LOT of ground and will earn you invaluable experience. After writing one you will have solid experience in

1. File management, and filesystems
2. GUI coding and almost all of the common widgets
3. or you could do a text based file manager, up to you
4. Basics like arrays (lists), mappings (dictionaries), structures (no real equivalent in python, but can be mimicked with classes or dicts
5. User interface design
6. program design, this project can be done in a variety of ways, some good, some bad, be prepared to get it wrong throw it out and start again. Also done right, there are lots of small components (e.g. a file copy dialog) that aren't overwhelming to start with. The biggest step in going from beginner to intermediate is learning how to decompose the big problem into lots of little easy to handle small problems... this is the 'art' of computer programming.
7. A file manager covers a lot of different data structures, and hence the algorithms that use them, vectors, trees, graphs (these three alone get you a LONG way)
8. Finally, a file manager consists of a LOT of glue code, in fact, most of it is glue code, and writing glue code gives you more practical experience than anything else, because YOU have to figure it out yourself.

Notably, this lacks some other fundamental stuff to programming: SQL (a little knowledge here goes a long way too), graphics coding (the basics I learnt before openGL have stood me in good stead over the years), and I'm sure there's more. Still, a file manager is a good choice IMHO

No, you wouldn't charge him with bank robbery... but you would sure as hell do a DEEP investigation into conspiracy to commit bank robbery.

So the U.S. is on the "Right", as in "right wing", side? I see what you did there. Be prepared to be black bagged for pointing this out to the sheeple...

Guns are also more targeted. If revenge really is the motivation, that counts for a lot.

"Many eyes makes bugs shallow" applies not only to people working on the buggy code itself, but also all the developers who use the code. Bugs are almost always almost found because of software behaviour, and in general bugs in closed or open software are equally likely to be discovered by end-users. Bug are far more likely to be found by developers though. Consider some different scenarios: (1) A bug is discovered because following the documentation on how to use some API doesn't work exactly as expected; a really bad bug because behaviour under normal conditions is wrong. (2) A bug is discovered because a developer makes an invalid call to an API and it doesn't error out gracefully; still a bad bug, but most developers are going to correct their code to use the API correctly, and maybe file a bug report if the problem is bad enough to break their software. In case (1) someone is always going to file a bug report, closed or open source doesn't matter. In case (2) is different; chances are a developer isn't going to bother submitting a bug report if the buggy code is closed source, they'll just write some validation around the API call to avoid the bug before it happens. If open source, this validation will probably be submitted as a patch upstream, or at least someone is likely to report the bug. But then there's case (3), heartbleed. What you've got here is a bug that for correct input works, no bug to file, for incorrect input appears to still work, so still no apparent bug, but for incorrect input it does extra stuff you don't know in advance to check for. A developer with a case (3) bug is far less likely to discover that bug. If the library is open, a developer debugging their code might step into the library code and see the problem, slightly increasing the likelihood of the bug being found in open source as compared to closed.

The point is that downstream developers count as 'eyes', and probably make up the majority of those eyes. Because of lower barriers to entry, open source projects when compared to their equivalent closed-source counter parts tend to have many more downstream developers. Even is the case of non-library, end-user application projects, other devs are write plugins, extensions etc. so this remains mostly true. The argument that the eyes don't exist is not true. The eyes may not be looking directly at the code, but the code's behaviour is being tested in a variety of other ways. Case (1) bugs are going to be found and reported regardless of whether the source is open or not. Case (2) bugs are probably equally likely to be found, but far more likely to be reported and fixed if the buggy code is open source if there is a downstream workaround. Case (3) bugs are hard to find either way, but are MUCH easier to fix in the open source world.

And what's this saying that heterogeneity of the Linux world will make fixing it more difficult? Fix it upstream, and most distros, and ALL the major ones will have it out a s a security update in less than a week.

Yes, that's what I said... "This particular case is very different". SONY don't own the copyright, and as far as I can tell, their not even claiming that they do. SONY didn't even take the clip down themselves, or issue a take down notice as far, again as far I can tell. Does the automation system actually file a take down notice technically, or does it just "take it down"? Does SONY corp fully control what's on the list of things to compare against for take downs? These are all questions that need answers before we can say exactly what happened. If google/youtube just assumes that anything in SONY controlled channels is owned by SONY (quite possible), then SONY didn't assert copyright ownership. Google/youtube asserted that SONY owned it, which is doubly fraudulent. This is a fuck up. It's a complicated fuck up, and it's a fuck up because google/youtube swings to far in favour of big media/MAFIAA. I'm not saying it's right, but this time, it's doesn't look direct malice.

Read the GP Again... "claimant's copyright that was reportedly infringed immediately turned over to public domain". The claimant must, even with the fucked up copyright laws we still have, specify what copyright they own is being violated. So even in a false claim, Asshat Corp asserts you've violated their copyright on A, in your work B, they lose copyright on A. Your work, B, is unaffected. This particular case is very different from your normal take down request though, since Asshat Corp has taken your work, B, and included it in their line up (possibly legally if your work was creative commons without a non-commercial clause). Now an automatic system, which is fact totally one sided, has determined your B is the same as their B, and because it always assumes Asshat Corp own everything and everyone else is thief (because that reflects reality ) your B gets taken down. The problem here is the automation. The system should, when a potential infringing case is identified, check the licence of Asshat Corp's claimed infringing content. In this case it would have been CC, so no need to take down. If Asshat corp had CHANGED the license, and the original was CC-SA, then the blender guys would have a very good reason to file suit.

I've never understood why people think free and speech and libel laws don't work together. You can say what you want (free speech) even if it's false, inflammatory, libellous , whatever. By suing you for the HARM caused by your speech, I am in no way infringing or curtailing your right to do it again. Gag orders are a different matter, I agree, and jail time as a sentence gets iffy, because I don't believe anyone imprisoned really has free speech, and if that jail time is a result of exercising only free speech in the first place, that's a problem. But if you incite a riot, it's free speech, go ahead. But you are partially responsible for any damages. There is a conspiracy to commit vandalism, loot, whatever. If someone dies, it's conspiracy to commit murder, or maybe manslaughter. The point is, punishing someone doesn't infringe their right to free speech automatically, and punishing someone for the results of their speech is not inherently punishing them for speaking freely. Basically, I see free speech like this: You can say what you want, and you can't be punished for saying it unless it causes harm.

Here's a link to Naomi wolf presenting on the ten steps, which she describes in her book "The End of America"; https://www.youtube.com/watch?...

Crap, my tinfoil hat is still conductive! What am I going to do now?