Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Note: You can take 10% off all Slashdot Deals with coupon code "slashdot10off." ×

Comment SwiftKey? (Score 4, Interesting) 126

What about the disastrous SwiftKey vulnerability? It makes Samsung Android systems vulnerable too. Samsung said they'd fix it back in June, but we still have no patch.

When buying an Android phone: Measure how many days it takes from the vulnerability report (at least publicly) until it's patched in phones already used by customers. Focus on phones more than 2 years old, since your phone will be that age someday. Then: Don't buy from unresponsive makers. I suspect that if a few buying guides included those numbers, some manufacturers and service providers would start paying attention.

Comment There are LOTS of projects with these problems (Score 2) 119

"How would an experienced developer get these problems in the first place?"

A lot of projects do not follow widely-accepted best practices... even if they are experienced... and that is a problem!

A remarkable number of OSS projects fail to have a public source control system (#2). That includes many established projects that everyone depends on. Actually, a number of OSS projects - and projects that people THINK are OSS but are not (because they have no license) - fail many of these points. It's not that Red Hat's internal processes are immature; Tom was trying to bring in software from someone else (Google in this case) and was fed up by the poor practices from people who should know better.

Yes, #7 refers to a best practice (let people pick their install directory) that's been around for at least 20 years and probably much longer, but it's still widely NOT followed.

Anyway, that's Tom's point; there are a lot of widely-accepted best practices that are NOT followed, and that needs to change.

Comment If you don't like it, send a comment! (Score 1) 126

If you don't like this idea, send an email (as they request) to Sharron Cook, publiccomments@bis.doc.gov. Please refer to RIN 0694-AG49 in all comments and in the subject line of email comments. Explain why you think it's a bad idea, with reasoned arguments. Before commenting, you should read the proposal first: https://www.federalregister.go...

Comment Put away the bingo card (Score 4, Interesting) 138

Put away the bingo card. Some languages, like Lisp and Haskell, actually DO bring seriously different ideas to the table, and there are tasks where their ideas are useful. A few examples may help. Once a "variable" is set, you cannot change its value (though it CAN go out of scope). This has serious reasoning and optimization advantages, but it requires a different way of thinking. Haskell has lazy evaluation, i.e., it computes nothing until you ask for it. It's routine to define infinitely-large data structures, which is a non-problem because only the parts you need are calculated. If you're only familiar with the ALGOL language family (C, C++, Objective-C, Java, C#, PHP, Python, etc.), you'll need to do some real learning.

Comment Heartbleed - how it could have been found (Score 0) 53

My article How to Prevent the next Heartbleed lists in detail different ways that Heartbleed could have been found ahead-of-time. The point isn't to find it now, it's to learn from Heartbleed so we prevent a recurrence. There are many ways to detect vulnerabilities like this ahead of time... we need to start using some of them.

Comment Have a billion speakers (Score 1) 626

At one time a number of constructed languages were created and got some speakers (including Esperanto). But relatively few people learn a language just for fun (yes, I know about Klingon and Elvish, but they will not be replacing English). Most people will only learn a language if they have a strong need to USE that language to communicate with some large group of people. Esperanto is actually much easier to learn than English; it's a reasonable constructed language. I spent a little time learning some of it, and I appreciate its clever approaches to making it easier to learn (e.g., the "mal-" prefix). The problem is that you can only speak with other Esperanto speakers in it. English is a mess of complications, like all natural languages. In some ways English is easier; in others it is harder. But when you learn English, you can talk to the other 1 billion people who can speak English as a first or second language. For most people, THAT is what makes English worth learning. Again, you normally learn a language specifically so you can communicate with others. Chinese actually has more speakers than English, but they are concentrated in China; worldwide, it's easier to find an English speaker than any other specific language. If you want an easier-to-learn language than standard English, you might consider an English-based controlled language like "Basic English" https://en.wikipedia.org/wiki/... or the "Special English" used by Voice of America https://en.wikipedia.org/wiki/... ; these are more complicated than Esperanto, but you can talk with many more speakers. I can imagine "mostly compatible with existing English" could be a necessary criteria for "new" constructed language, if you need to create one at all.

Comment Apache has mod_spdy (Score 3, Insightful) 147

I agree that Apache web server support is vital if HTTP/2 is to get much use. That said, the mod_spdy plug-in for Apache supports SPDY, and has been accepted into Apache trunk. See: http://googledevelopers.blogsp... https://svn.apache.org/viewvc/...

Since HTTP/2 is based on SPDY, it seems likely that this plug-in will be tweaked to support HTTP/2. That said, I suspect the Apache Foundation would say something like, "patches welcome".

Comment Words have meanings (Score 1) 112

The vast majority of people who use the term "open source software" use it with roughly the same meaning as OSI does, which is all that matters. You can confirm this with a quick Google search. Also, note that many organizations that require something to be be "open source software" will point to the OSI definition.

By the commonly-used definition of "open source software", you MUST be able to fork the project and maintain your own version. You cannot legally do that with TrueCrypt, therefore, by definition it is not open source software. Case closed.

Comment TrueCrypt is not open source software. (Score 5, Interesting) 112

TrueCrypt isn't open source software, in spite of the author incorrectly claiming it is. More detail is here, which the author could have learned in 2 minutes of Googling: http://en.wikipedia.org/wiki/T... ... for your amusement, I have quoted it below:

TrueCrypt was released under the "TrueCrypt License" which is unique to the TrueCrypt software. It is not part of the pantheon of widely used open source licenses and is not a free software license according to the Free Software Foundation (FSF) license list, as it contains distribution and copyright-liability restrictions. As of version 7.1a (the last full version of the software, released Feb 2012), the TrueCrypt License was Version 3.0.

Discussion of the licensing terms on the Open Source Initiative (OSI)'s license-discuss mailing list in October 2013 suggests that the TrueCrypt License has made progress towards compliance with the Open Source Definition but would not yet pass if proposed for certification as Open Source software.

According to current OSI president Simon Phipps:

...it is not at all appropriate for [TrueCrypt] to describe itself as "open source." This use of the term "open source" to describe something under a license that's not only unapproved by OSI but known to be subject to issues is unacceptable.

As a result of its questionable status with regard to copyright restrictions and other potential legal issues, the TrueCrypt License is not considered "free" by several major Linux distributions and is therefore not included in Debian, Ubuntu, Fedora, openSUSE, or Gentoo.

The wording of the license raises doubts whether those who use it have the right to modify it and use it within other projects. Cryptographer Matthew Green noted that "There are a lot of things [the developers] could have done to make it easier for people to take over this code, including fixing the licensing situation", and speculates that since they didn't do those things (including making the license more friendly), their intent was to prevent anyone from building on their code in the future.

End of life and license version 3.1

The 28 May 2014 announcement of discontinuation of TrueCrypt also came with a new version 7.2 of the software. Among the many changes to the source code from the previous release were changes to the TrueCrypt License — including removal of specific language that required attribution of TrueCrypt as well as a link to the official website to be included on any derivative products — forming a license version 3.1.

On 16 June 2014, the only alleged TrueCrypt developer still answering emails, replied to an email by Matthew Green about the licensing situation. He is not willing to change the license to an open source one, believes that Truecrypt should not be forked, and that if someone wants to create a new version they should start from scratch.

Marriage is the sole cause of divorce.

Working...