[Note: I forgot to log in and posted this AC. I'm not sure if reposting as my user is compatible with Slashdot netiquette canon, but this makes it easier to keep track of replies, so pardon the noise.] Several people have rushed to suggest Moodle as the obvious solution to this problem. I have two distinct and largely independent concerns about such answers. First and foremost, it is unclear to me that the proper solution to this sort of problem must be a monolithic, integrated and gigantic learning management system. The submitter indeed wonders about specific tools, so suggesting something like Moodle is at least a helpful pointer, yet there isn’t necessarily any indication that a comprehensive tool is the proper solution to the problem. If all that's required is a tool for calculating grades and generating report cards, then the proper solution, following our beloved UNIX philosophy of doing one thing and doing it right, should not be a tool that calculates grades, generates report cards, manages teams, permits file uploads, hosts discussion forums, sends notifications through e-mail, etc, all for any number of courses in which registered users enrol. Such a system could happen to be desirable, of course, but the scope of the question becomes a major concern. The benefits of such a system, if indeed they exist, must of course come when applied to solve problems that fall within the scope of their design: one grand unified system to manage all of the institution's academic information processes. A greater question is whether such a system is ever a good idea, even when much more is desired than a substitute for spreadsheets. I believe our experience (information technicians as most of us are) with opaque, monolithic systems is quite telling in this regard: it's probably a bad idea, and it's probably better to decouple the bits of the problem as much as possible within the constraints of simplicity imposed by a non-technical user base. My second concern is more specific and perhaps less important. I’ve had some experience using Moodle itself to manage an undergraduate CS course, and it has been less than pleasant. It certainly takes a stab at a great variety of problems: managing user registration for students and instructors, enrolment in multiple courses, discussion forums, e-mail notifications, student teams, time-limited file uploads for turning in assignments, grading, and so on. Most unsurprisingly, though, its solutions are actually rather poor, at least on the version I happened to work with. Grades, for whatever reason, are necessarily discrete, simple integers. The student and group information interface does not provide comfortable listings or tables; instead, information is split across multiple pages, one for each student or group, with links to assignments they've turned in and the like. Unfortunately, opening those pages seems to be a stateful action, so if, say, you happen to open the pages for a dozen students in background tabs hoping to download each of their solutions to programming assignments or anything of the sort, by the time the last one loads, the rest are invalidated; you actually have to crawl them one by one. This is only an example, of course, of a pattern present in nearly every function Moodle implements. It's extremely uncomfortable. Moodle is generally ill-suited for any sort of non-trivial use, and programmatic interaction with it is extremely impractical. Querying its database directly isn't too helpful, as it's full of implementation artefacts and redundant data, and the regular interface relies heavily on the assumption that the user will only ever use it within a Web browser, one page at a time. These concerns may not be too important in the context of a high school whose instructors are unlikely to have the technical skills to try any form of automatic interaction with the system, but the fact that it is even desirable says much of its shortcomings. I do note that I haven't checked whether the version of Moodle I worked with is up-to-date, and it may well be that these issues have long been resolved. Interaction with spreadsheets is far more comfortable. Non-technical users are typically already familiar with the paradigm, and it's quite easy to obtain the data from a spreadsheet file in a format suitable for programmatic manipulation if you want to implement any sort of automated process for generation of report cards. Free software solutions exist, of course: others have mentioned Open/LibreOffice Calc, and I believe Gnumeric (of the GNOME project) deserves mention as well. A spreadsheet would solve precisely the problem of calculating grades in a simple, expressive and commonly understood manner, and with some imagination, it even generates printable reports; and if that's not enough, it's far easier to automatically produce report cards with data from a spreadsheet used with some common sense and discipline than it would be with some monolithic package with a poor API, or worse yet, with none. It's still not quite a proper solution, of course: automatic generation of report cards still requires restrictions on the use and format of spreadsheets, and requiring discipline is, of course, asking for trouble. I don't know of a better solution that is flexible enough to be satisfactory; only of this one, yet it's perhaps overly flexible.

Chrome and most other browsers establish the connection even when the services aren't able to ensure a certificate hasn't been tampered with.

And the solution, obviously, is not checking at all. Slick.

I don't know about junk mail, but perhaps in five years Slashdot spam bots will be smart enough to use "geeky stuff" as something desirable on a website with the motto "news for nerds, stuff that matters", rather than as something that should be abandoned.

Fixed that for you.

While I love to bash on Ubuntu on every (reasonable and merited) opportunity available, and they certainly aren't scarce, this isn't one of them. As others have already pointed out, the packages were removed because Oracle will not license updates, and the latest distributable version has important security vulnerabilities. It would be irresponsible to keep the current packages in the distribution and illegal to update them.

More importantly, this move is exactly what Oracle wants done, and no, it's not any sort of evil move. Dalibor Topic explains in his blog the reasons behind this change in licensing: OpenJDK is (the basis of) the reference implementation for Java 7, and the Sun (now Oracle) JDK implementation is now (going to be) based on OpenJDK; the gratis, non-free licensing for the Sun (now Oracle) JDK was a temporary solution that's reached the end of its applicability:

That non-open-source license was introduced by Sun Microsystems back in 2006, when the open-sourcing of Sun's Java SE implementation was announced at JavaOne, as a stop-gap measure until OpenJDK matured. It was a way to enable Linux distributions to take Sun's JDK 5.0 and provide their own 'native packages' based on Sun's non-open-source bits.

It was always intended to be a temporary solution, and the final solution has always been migrating to OpenJDK. Yeah, it sucks, compatibility is far from complete, and things will break as a result of this move, but it's always been the plan, and it's not Canonical fucking it up this time. For reference, as one of the comments in TFA points out, Debian did it too.

In short: nothing to see here; move along. If this makes you lose sleep, maybe you shouldn't have used Java, and maybe you should migrate to something better.

This story got me thinking that many of the tasks routinely executed on personal computers (perhaps cryptography, video decoding, and such) may benefit from including a FPGA in PCs to serve as a programmable coprocessor. Much like graphics-intensive software can come with shader code to offload processing to the GPU, couldn't a video codec or an implementation of SSL or whatever come with code that would allow an FPGA to do part of the work?

I googled around and found that at least CERN has done something of the sort, but that was over seven years ago. There was a story on Slashdot about something of this sort, but it's even older than the CERN publication. Is anyone working on this sort of idea? If not, why? Is it simply a matter of cost, or is there some other issue that makes this impractical?

Maybe I just suck at googling...

This is a great point. The distinction that actually matters is not so much whether the bug reports are submitted by developers or lusers, but whether they're submitted by idiots. The fact that someone's been hired as a developer reduces the odds of idiocy w.r.t. software, but it's neither necessary nor sufficient, and a certain degree of optimism is required to assert even the correlation. Likewise, it's plausible that lusers are more likely than developers to be idiots about software, but exceptions exist.

The real, general solution to this problem is, of course, to get rid of the idiots on both sides. The solution to this problem is left as an exercise for the reader.

I completely agree with your general sentiment, but dude, gedit? Seriously? Why not vim or emacs (or both, to avoid the ridiculous flame war)?

Nice of you to mention Plan 9. If you had bothered to read anything at all about it instead of just pasting the first geeky modern OS name you could think of, you'd realize how stupid your comment sounds. Try reading about who made Plan 9, or what its design is like, or who spent decades working on it.

Hydrogen bombs include fusion. That's what the hydrogen does, and it's also why they're sometimes called "fusion bombs".

You really need to read this essay about filenames, as well as these two bits about parsing the outputs of ls and ps. In short: correct and secure work with filenames is made difficult by certain features of shells and their default configuration, and the output format of common tools (including ls) makes their output literally impossible to parse in a correct and secure manner. Parsing the output of ps is a very bad idea for similar reasons. It's fine if you're just doing one-liners for simple, everyday interactive work in the shell, but if you write shell scripts and don't understand these issues, you've likely been writing buggy, incorrect, insecure and exploitable code.

I've personally never used PowerShell. My solution to these difficulties has always been to learn to do things properly regardless of the difficulty. While I don't know enough about it to be convinced that it would be a proper solution, I can imagine many ways in which the idea of passing objects instead of text may make things easier. If you can't see why, you need to learn a lot more about shells and their issues. I'm not trying to be patronizing here or anything; it's just that shell scripting is a lot more complex than people typically realize, and such misconceptions cause security holes.

Here.
The linked article is just a sort of report on that post, which is pretty idiotic considering you can just read the original post.

Security people have since forever warned the rest of the world against the risks of blindly trusting centralized/hierarchical trust schemes. It's not the first time this happens. It won't be the last. And while standard practices remain as they currently are, we're all in the hands of whoever's got money and power, and governments tend to have a lot of both. Most of you might not care much about this since you probably live in places with decent governments*, but it's a real concern for an enormous portion of the world's population.

*IN RELATIVE TERMS. I know many of the governments of the "free world" are guilty of all manners of despicable privacy violations with all manners of awful consequences, but please don't even attempt to compare these issues to the sorts of oppression that happen in full-blown totalitarian regimes.