Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
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.
Blame the WTO's puppet organisation the US for this sort of thing, not the EU.
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.
Link to Original Source
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.
The linked article is just a sort of report on that post, which is pretty idiotic considering you can just read the original post.
Since it was first posed back in 2008, this question has now become the second most popular question of all time on StackOverflow.
Top 5 results: "Code Complete (2nd Edition)", "The Pragmatic Programmer: From Journeyman to Master", "Structure and Interpretation of Computer Programs", "The C Programming Language", "Introduction to Algorithms".
Full Details Here"
Link to Original Source