I have this bumpersticker posted on my office wall: "Building the Legacy Systems of Tomorrow". I'm not sure who created that phrasing - or the bumper sticker - but I like it.
You're quite right, it's perfectly secure if the client systems have the.gov TLD public key. And almost no one does, today. Of course, no one will bother trying to get DNSSEC or these keys until there's something to verify.
This is a classic chicken-and-egg problem. The good news is that the U.S. government _CAN_ require that its OWN sites implement DNSSEC - and once that's done, people who deal with those sites (most U.S. citizens) will have a reason to install DNSSEC and the relevant.gov keys.
What will probably happen is that there will be a Firefox plug-in (if there isn't already) that supplies these keys, and slowly browsers will add support for all this. The result: Accessing these sites will become more secure, over time. Good thing.
This won't solve all the problems of the universe, but this is a GOOD THING. Securing DNS is absolutely critical to making the Internet a safer place. If I type in "irs.gov", I want to go to "irs.gov", not some spam site, and this helps me get there.
DNSSEC can provide IP addresses with a strong guarantee that the IP addresses are actually correct.
DNSSEC can even provide other keys, and make it possible to EASILY send secure emails without having to do a key exchange ahead-of-time. See, for example:
http://www.dwheeler.com/essays/easy-email-sec.html
Yes, it's Java-heavy. The study author sells a proprietary static analysis tool for Java. So the Java bias is understandable, but their title should have made it clear that they were only analyzing a few Java programs, and not a representative sample of major OSS projects.
They also ignored the enterprise support options for these programs, which is completely unjustifiable.
I think its Java bias matters. Until very recently,
most Java programs required Sun's proprietary Java implementation. The FSF and others warned of the Java Trap - so a very large proportion of the FLOSS community has actively ignored these Java programs.
Sun has recently released most of its Java implementation as FLOSS, and the most recent versions of Fedora and Ubuntu have now integrated it (through Debian hasn't), so I think we'll start to see more cooperation in Java projects.
They made three claims, let's take a look at them...
"Failure to Provide Access to Security Expertise... [aka] documentation that covers the security implications and secure deployment of the software
they develop, a dedicated email alias for users to report security vulnerabilities, or easy access
to internal security experts to discuss security issues".
Odd, they seem to be ignoring the enterprise versions (e.g., Red Hat sells JBOSS support); that doesn't seem to be a fair methodology.
Their demand for a "dedicated email alias" and "easy access to internal security experts" shows that they fail to understand that some people want totally open discussions, which these projects do support. They may not LIKE that, and actually I'd agree with them, but claiming that there's NO way to report vulnerabilities or to talk with developers seems fundamentally mistaken.
I agree with them that documentation about security needs improvement, though I don't see any evidence that FLOSS is worse than proprietary on that count.
"Failure to Adopt a Secure Development Process...
In virtually every project analyzed, there were a significant number of security issues that
went unaddressed over three generations of releases...".
It's not clear what these "issues" were. Were these REAL issues, or just reports from a static analysis tool? I wish they'd gone more into this, it's hard to say this is really true or not given their report. Often static analysis tools' reports have LOADS of false positives. As a result, it's hard to see if this is real or not.
"Failure to Leverage Technology to Uncover Security Vulnerabilities: The number of security issues identified in the study - especially in the most popular open source packages - was surprising...". Again, not surprising if what is being measured is raw unanalyzed tool output. It could be that every single "vulnerability" is a false positive (not an uncommon result, unfortunately).
I would agree with them that I'd like to see more projects use more tools, but a lot of FLOSS projects do use tools. For example, the Linux kernel developers ended up creating their own static analysis toolsuite because tools are normally designed to analyze applications, not kernels.
The claim that this is representative of FLOSS is unfounded, since it only considers a few Java programs and ignores their enterprise support options (which is what you'd use for an enterprise!).
I really wish they'd explained what they meant by issues; the problem of tool false positives is very well known, and I don't see that they really addressed that.
The original said:
"Government and commercial organizations that leverage open source should use
open source applications with great caution. Risk analysis and code review should be
performed on any open source code running in business-critical applications...". Um, let's try:
"Government and commercial organizations that leverage software should use
software with great caution. Risk analysis and code review should be
performed on any software running in business-critical applications..."
I propose Offset 2000 version numbers, i.e.,
"(y-2000).mm[.dd]".
The first number is the year minus 2000, followed by "." and a two-digit month,
optionally followed by "." and a two-digit day when there's more than
one release in a month.
So version 8.07 would be the first release in July 2008.
If you made a later release on July 17, it'd be 8.07.17
(so if a project makes many releases in a month, you can again determine
how old yours is).
Date-based version numbers have a lot going for them, because at a glance
you know when it was released (and thus you can determine how old
something is).
If you choose the ISO order YYYY.MM.DD, the numbers sort very nicely;
Debian packages often use YYYYMMDD for versioning.
But there's a problem: full year numbers, or full dates in this format,
are annoyingly large.
For example, version numbers 2008.07.16 and 20080716 are
painfully long version numbers to remember.
That's not necessary.
So, use dates, but shorten then.
Since nothing today can be released before 2000,
shorten it by subtracting 2000.
Note this is subtracting - there's no Y2K-like rollover problem,
because the year 2100 becomes 100 and the year 3000 becomes 1000.
The second number is the month; using a two-digit month means you
don't have the ambiguity of determining if "2.2" is earlier
or later than "2.10" (you would use "2.02" instead).
If you need to disambiguate day releases
(or you make additional releases in the same month),
add "." and a two-digit day.
If you use a time-based release system, using this version numbering
system is easy, and you can even talk about future releases the same way.
But what if you release software based on when the features are ready,
or want to talk about the system under development?
You can't easily call it by the version number, since you don't know it yet,
but that's not really a problem.
In many cases, you can just talk about the "development" version or
give a special name to the development version
(e.g., "Rawhide" for Fedora).
If you need to distinguish between multiple development
versions, just give each of them a name
(e.g., "Hardy Heron" for Ubuntu); on release you can announce
the version number of a named branch (e.g., "Hardy Heron is 8.04").
This is more-or-less what many people do now, but if a lot of us
used the same system, version numbers would have more meaning than
they do now.
Ada has a lot going for it when it "has to be correct every time"; that is its main purpose. The big advantage is that the language maximally checks everything at compile time - so if it HAS to work correctly every time, that's a big plus. It also has more run-time checks. It even has some extra features that let it be more specific. It has a nearly-unique ability to specify number ranges; if you spec a variable as being in the range 1..100, then any attempt to assign outside that range is immediately detected. That turns out to detect lots of errors before they get out of hand.
It's not the best language for EVERY purpose, but it has its place.
I have a tutorial here, if you're curious:
Lovelace tutorial.
The problem isn't that Wikipedia is occasionally wrong. The problem is that there are still unwise people who think OTHER sources are always accurate.
George Packer Berry was the Dean of Harvard Medical School (1949-1965) and had a much wiser approach to information.
In an address to students at the Medical School, he said, "Half of what we are going to teach you is wrong, and half of it is right. Our problem is that we don't know which half is which."
Wikipedia is new, so it's forcing people to notice something that was always true about any information, but that they've been ignoring up to now: You need to check information that's
important to you.
I don't want my documents in essence owned by any one supplier of office suites - I should have the
freedom to choose, and change, who my supplier is.
ODF meets that requirement well; OOXML does not.
ODF was developed over many years, by a large number of different organizations working together - both open source and proprietary.
It's not just "Sun and the open source community", it was a large collaborative effort (as is usual for standard-setting).
In contrast, OOXML was developed under the sole control of a single supplier, who's rigged things to ensure that they stay in control by them, in perpetuity.
If you're looking for "compromises", you should look at OOXML, not ODF.
Rob Weir shows that OOXML is full of a massive
number of errors - I estimate over 172,000 unresolved errors.
These comments about ODF are without merit;
OpenDocument can handle change requests
(see, for example, section 4.6) and tables in presentations.
OpenDocument 1.0 handles tables-in-presentations just fine, they're just encoded differently than you seem to be expecting.
Embedded tables are encoded as embedded spreadsheets;
this is slightly different than how OOXML encodes it, but all the data and capabilities are there.
OpenDocument 1.2 will make the indirection optional, but this is all invisible to end-users anyway.
Note that this means that tables CAN be in presentations, but more importantly, they're encoded the same way that they are
encoded in other kinds of documents -
OpenDocument has a single, clear table model.
In contrast, OOXML has multiple incompatible table models.
OpenDocument is remarkably consistent, as well as building on well-established standards - which is why it can be so
much smaller, and so much more capable, at the same time.
Sure, many office suites will implement some subset of OOXML.
But it would be wise to view it as a temporary transition format, so that you can escape from vendor-specific formats
to an open standard like ODF.
Yes, it's convenient to have it as a "published standard", but Ecma is enough for that; there's no reason to have
an ISO stamp on it.
OOXML is essentially the proprietary format of a single vendor.
There's no reason to confuse anyone
into thinking it's some sort of universal format, and the ISO stamp is likely to cause that kind of confusion.
The format for documents should not be controlled by any single office document supplier.
That is a key reason why OOXML should be rejected by ISO, and published only by Ecma as some sort of
interim format (to enable people to move off it).
OOXML is also so error-ridden that it should have been laughed out of the fast track process.
It's a really bad spec, and should never have been submitted to the "fast track" process. Rob Weir analyzed OOXML using a sampling technique, and found that the ISO process found 1.5% or less of the errors in the spec. That suggests there are at least 172,000 errors in the spec that were not even NOTED in the last gathering for ISO's fast track.
Inigo Surguy's "Technical review of OOXML" also found a massive number of errors. It's hard to express how warped the process has become. In a five-day meeting, they couldn't address almost all the errors (because there were too many) - instead, they did a block vote, and I know of no one who really even understood what had been accepted by the vote.
The countries "approving" the spec don't even have a final spec to approve - instead, it's an original document with a bunch of text describing the kinds of changes to be made to it.
It's not EXACTLY what you asked for, but another alternative is
Federal Cyber Service: Scholarship for Service (SFS).
Their goal is to "increase the number of qualified students entering the fields of information assurance and computer security...". Their "scholarship track" provides "funding to colleges and universities to award scholarships to students in the information assurance and computer security fields. Scholarship recipients shall pursue academic programs in information assurance for the final two years of undergraduate study, or for two years of master's-level study, or for the final two years of Ph.D.-level study. These students will participate as a cohort during their two years of study and activities, including a summer internship in the Federal Government. A limited number of students may be placed in National Laboratories and Federally Funded Research and Development Centers (FFRDCs)."
The problem here is that even though the standard said something, neither kernels nor compiled programs complied with it. There's no need to rush to make this change - current code is working! By rushing to remove this "extraneous" setting, code generated with the new gcc will silently screw up on older kernels. Users often run older kernels, and/or need to revert to them when things go wrong. Suddenly switching, when there's no need to rush the change, is a terrible idea. Especially since there's no real advantage to the change (not even a real performance advantage for real programs under usual usage models).
There's an easy solution: A grace period. Let the kernel developers know (done), let the kernel developers fix their kernels (done), and give time for such fixed kernels to spread. Change the compiler so that it won't generate the "unnecessary" code, but DISABLE that by default for a while. After a long time (two years? More?), switch to enable-by-default. This change has no useful upside for users, and lots of downsides (in terms of broken programs), so there's no reason to hurry it. It's fine to do it, but just do it slowly.
The only reason to run Windows (any version) is to be able to use the hardware and software that is only compatible with Windows. I know of no one who claims that Windows is the "best operating system on Earth", by any measure; people choose Windows for application compatibility, not for its "innovation". A "grossly incompatible Windows" is completely worthless.
Similarly, even if it's in the spec, it's absurd to change a system and make it so user programs just break. Think of the users. Instead, figure out how to make the change WITHOUT harming the users. That user might be you.
The normal meaning of "open source software" is the one given in the Open Source Definition: http://opensource.org/docs/osd
This is the normal, common meaning of the term; a Google search on the term quickly proves this.
Therefore, Singularity is not open source software; please don't confuse people, and submit to the Microsoft marketing engine, by
incorrectly saying otherwise.
Instead, use another term when you mean "you can read the source code". I suggest "source available".
I just entered =850*77.1 into OpenOffice.org, and it gets the correct answer. It's rediculous that a freely-available program can get basic calculations correct, and Excel can't.
If your goal is to maximize the amount of code released back to the project, the BSD license is not the best license to pick. The whole point of the BSD license is to let people do almost anything with the code, including taking it proprietary and never releasing improvements back to anyone. If it's really important to you that people contribute changes back to your project, use the LGPL or GPL; they're designed for that purpose. The BSD-style licenses aren't. Instead, BSD-style licenses were designed to allow anyone to take the code and control the improvements, WITHOUT giving contributions back to anyone.
There are lots of good reasons to release code under the BSD license. For example, getting widespread use of an idea or protocol sometimes works best with BSD-style licenses. Many standards groups try to create at least "sample implementations" using BSD-licensed code, so that anyone can grab the code to put into their programs. But the BSD license isn't the be-all of licenses (nor is the GPL). I (and many others) believe the license difference is one of the main reasons the Linux kernel has completely eclipsed the *BSDs in market share, even though the *BSDs started first. If any company made a real improvement to the *BSDs, they often kept it proprietary, while any improvements to the GPL'ed Linux must not be proprietary, so the *BSDs get very little corporate help, while in the Linux kernel, companies spend real money to contribute code.
I don't want to call it "stupid", but choosing a license that doesn't even slightly meet your goals isn't a good idea. Choose your license for a project based on your goals for that project, and that may be different between different projects.
As noted in LWN, this kerfluffle seems to have been kicked off when "wireless developer Jiri Slaby posted a patch which stripped the ISC and BSD license notices from the source, replacing them with GPLv2 license text. It should be noted that this patch was not accepted into any repository anywhere and never became part of any exported Linux kernel tree. Nonetheless the BSD community exploded in a very public way. It is interesting to compare their public response to this posting with the sort of response they very loudly insisted was their due when they were found to have carried improperly relicensed GPL code in their repository for some time."
The article is misleading. You can take a BSD-licensed program, modify it even slightly, and re-release the COMBINED material (original BSD + the additional modifications) under the GPL, as long your combined work obeys BOTH licenses. The legal issue is that the modified text can be under a different copyright license, and the combined work has to obey BOTH licenses. Since the GPL adds more conditions than the BSD license does (generally), in a combined work it's the GPL conditions that end up dominating the set of conditions. The only issue is whether or not the "small change" could be copyrighted; the U.S., at least, has a very low bar of what is copyrightable, so even small changes are likely to be copyrightable.
Certainly it is NOT okay to remove the copyright notices from BSD material, as long as there's something left in the file that's covered by the BSD license. So, don't do that. But you CAN take a BSD work, combine it with other works, and have the final result as essentially GPL'ed or proprietary.
My FLOSS license slide even helps you figure out when you can do that, and when you can't.
But that only covers the legal issues. If there's an existing project that releases something under an OSS license, it's usually better to continue to use their license than to fork off another project under a new license, especially if you're not making many changes. For a lot of reasons.
The Pottersville/Vendor lock-in Anti-pattern documentation illustrates the whole problem with software-as-a-service when the service is controlled by someone else.
In particular, look at their picture of some future screen:
Dear Friend,
Your platform license... has expired....
You have 123 Gigabytes of storage in Database49...
To renew your monthly license, please click "Yes to pay", to submit your payment of US $152,042.00 or "No to delete" to remove all of your accounts and data.
Allowing someone else to control all of your information has always been a foolish decision.
I agree, watermarking is WAY better than DRM. It means I can use any player - my Linux systems, desktop players, ones in my car, etc. I can transfer files between my players, too. Perhaps most importantly: It no longer gives Microsoft and the audio companies a reason to collude to try to take control of my computers away from me.
If the DRM identifies individuals, then there's certainly a big risk of loss of privacy. Putting your name, credit card number, and expiration date is kindof cutesy.... it certainly gives you an incentive to not give a copy to everyone else:-). But there are too many ways for the files to get "stolen" by others. Computers get broken into all the time. Heck, someone could just walk into a room where you're playing a song, record it, and send it to a million people... and it'd get identified as "yours". So while for a little while the courts might pretend that it's always the buyer's fault, that won't last... even if the courts really enforced it, the result would be that no one would buy music. After all, pirated songs would be WAY less dangerous, since they wouldn't implicate YOU.
But watermarks that only identifies "what song is this" is actually pretty reasonable. Some countries (like Canada) have imposed a repay scheme; the idea of monitoring "which songs are most copied" and then compensating that way has SOME merit, at least. Beats DRM.
Of course, throwing away all that stuff, and just selling basic songs at a reasonable price, in open formats that aren't patent-encumbered and EVERYONE can use, would be frankly the best. Why bother with a complicated technical system - why not just sell the customer what they wanted in the first place?
If they made it easy for customers to buy what they actually wanted, they wouldn't have been training up a generation of pirates.
[once] this kind of thing breaks loose and populates the seas and the oceans with itself by outcompeting the normal algae (the kind that produces Oxygen,)....
Never mind "outcompete" in terms of reducing the number of oxygen-producing algae. Worldwide ocean fires will eliminate a lot more than the algae.
I actually _use_ atime values, directly.... because sometimes I really do want to know when something was last accessed. This is as a human, not a program, so saying "well fix the program" isn't helpful. And it's been built into Unix from the beginning, so it's not like it's some amazing new capability. But I agree that I typically don't need fine-grained knowledge of when something was last used; I'm usually looking to see what is old cruft, etc. Some programs only need "was it accessed after modification", and certainly there's a performance hit for atime. So this "relatime" looks great to me.... I get my "cruft" information, and existing programs work, without the performance hit of traditional atime. As long as there's a WAY to force the traditional atime to be supported (via some mount-time option), I think relatime (even as a default) is a reasonable compromise. Relatime gives higher performance in exchange for a poorer quanta on atime, and for many, that's probably a worthy trade.
I like the idea of writing the "more accurate" atime when it's "for free". I don't see the big advantage of ALWAYS being a day late... I think it's better to say "at worse, it's a day late, but it MIGHT be better".
That project needs to be stopped right away. What's the use of just temporarily incapacitating people? We need to make sure that anyone on the other end of the gun is dead, dead, dead, so we can forever enjoy the sorrow of their wives, children, and parents! Weeee! (boggle!)
For the sarcasm-impaired: The previous paragraph is obviously lunacy. Since it's lunacy, I think having non-lethal alternatives is a GOOD idea. Foes of yesterday may be friends tomorrow (think Japan of WW II, etc.), so even if you're in a war, you may NOT need to kill your foe. It'd be great to avoid killing in many cases. Wouldn't it be great if there were LESS carnage in the future, not MORE? Wouldn't it be great if after a confrontation, most wives / children / parents got their loved ones back?!?
Now this particular approach may not be very effective; maybe another one needs to be investigated instead. The term "non-lethal" is misleading; they DO kill occasionally (they just kill less often), and since they kill sometimes, they need to be reserved for serious situations the way lethal approaches are. That said, if you do not NEED to kill all your foes, having a "mostly non-lethal" alternative would be WAY better than the "mostly lethal" approach we have now.
Yes, there's a risk that non-lethal approaches would be employed to create a police state. But you can have police states with lethal approaches too, and in fact, I'd argue that lethal approaches are more effective at countering civilians. Dead civilians don't try again. If there's a non-lethal approach, the civilians can try again later, something you can't say about lethal approaches.
The GPL doesn't limit USE of the software, so in that very narrow sense it doesn't matter to users. But that's such a narrow sense as to be meaningless.
If you want to use software, you must have software to use. If you want to have software to use, there must be a way to develop it. The GPL has been the "Constitution" enabling the development of a vast amount of really useful software; indeed, the majority of Free-libre / open source software (FLOSS) uses the GPL. And people are finally realizing that most FLOSS is commercial software; it's no longer exclusively "just a hobby". Before the GPL, the only ways of creating software were complete proprietary control (often by a company intent on preventing you from switching) or public domain/BSDish licenses (which sometimes works very well, but sometimes get sucked into proprietary projects often enough to die or live only on life support). So yes, if you wish to be able to use software in the future, the GPL is important; it establishes a viable method of making the software that people would like to use. In fact, it's been extraordinarily effective at doing so.
Even you don't write code yourself, you can still hire someone to write or change code. So the GPL provides additional capabilities to users, even if the user can't write code him/herself. And even if you use proprietary software, GPL'ed software has had a profound impact on limiting the costs of much of that software, which is also great for end-users (and again matters to them).
Here's an analogy - that statement is like saying that agriculture doesn't matter because many people aren't farmers. But non-farmers must eat too! Having viable methods to grow food - and a competitive system to lower costs and raise quality - are still of vital interest to the users of products from farmers. Unless you want to stop eating.
No, no, you want to keep up the format war until all the DRM mechanisms on all of them are thoroughly and completely destroyed... so that the folly of DRM will be obvious to all, quickly, instead of having a long-drawn-out waste of time.
Then whatever format wins will be actually useful by real people, so they can see the movies on any computer or TV they own, using any display they choose, and using any operating system. So they can back up their media (which always gets scratched or otherwise destroyed). And so they can view only the portions THEY want to see, and under "fair use" can create new works based on those products.
Copyright was created as a balance between the needs of initial authors vs. the needs of later authors and users, and DRM is trying to circumvent the law to upset the balance. With a little time, the balance should be restored.
Slashdot Mirror
I have this bumpersticker posted on my office wall: "Building the Legacy Systems of Tomorrow". I'm not sure who created that phrasing - or the bumper sticker - but I like it.
In short: if it runs, it's a legacy system.
You're quite right, it's perfectly secure if the client systems have the .gov TLD public key. And almost no one does, today. Of course, no one will bother trying to get DNSSEC or these keys until there's something to verify.
.gov keys.
This is a classic chicken-and-egg problem. The good news is that the U.S. government _CAN_ require that its OWN sites implement DNSSEC - and once that's done, people who deal with those sites (most U.S. citizens) will have a reason to install DNSSEC and the relevant
What will probably happen is that there will be a Firefox plug-in (if there isn't already) that supplies these keys, and slowly browsers will add support for all this. The result: Accessing these sites will become more secure, over time. Good thing.
This won't solve all the problems of the universe, but this is a GOOD THING. Securing DNS is absolutely critical to making the Internet a safer place. If I type in "irs.gov", I want to go to "irs.gov", not some spam site, and this helps me get there. DNSSEC can provide IP addresses with a strong guarantee that the IP addresses are actually correct. DNSSEC can even provide other keys, and make it possible to EASILY send secure emails without having to do a key exchange ahead-of-time. See, for example: http://www.dwheeler.com/essays/easy-email-sec.html
This page includes a list of FLOSS automated theorem provers. Fedora 10 adds several of these tools, so you'll be able to easily install and try out some of them.
Yes, it's Java-heavy. The study author sells a proprietary static analysis tool for Java. So the Java bias is understandable, but their title should have made it clear that they were only analyzing a few Java programs, and not a representative sample of major OSS projects. They also ignored the enterprise support options for these programs, which is completely unjustifiable.
I think its Java bias matters. Until very recently, most Java programs required Sun's proprietary Java implementation. The FSF and others warned of the Java Trap - so a very large proportion of the FLOSS community has actively ignored these Java programs. Sun has recently released most of its Java implementation as FLOSS, and the most recent versions of Fedora and Ubuntu have now integrated it (through Debian hasn't), so I think we'll start to see more cooperation in Java projects.
They made three claims, let's take a look at them...
"Failure to Provide Access to Security Expertise... [aka] documentation that covers the security implications and secure deployment of the software they develop, a dedicated email alias for users to report security vulnerabilities, or easy access to internal security experts to discuss security issues". Odd, they seem to be ignoring the enterprise versions (e.g., Red Hat sells JBOSS support); that doesn't seem to be a fair methodology. Their demand for a "dedicated email alias" and "easy access to internal security experts" shows that they fail to understand that some people want totally open discussions, which these projects do support. They may not LIKE that, and actually I'd agree with them, but claiming that there's NO way to report vulnerabilities or to talk with developers seems fundamentally mistaken. I agree with them that documentation about security needs improvement, though I don't see any evidence that FLOSS is worse than proprietary on that count.
"Failure to Adopt a Secure Development Process... In virtually every project analyzed, there were a significant number of security issues that went unaddressed over three generations of releases...". It's not clear what these "issues" were. Were these REAL issues, or just reports from a static analysis tool? I wish they'd gone more into this, it's hard to say this is really true or not given their report. Often static analysis tools' reports have LOADS of false positives. As a result, it's hard to see if this is real or not.
"Failure to Leverage Technology to Uncover Security Vulnerabilities: The number of security issues identified in the study - especially in the most popular open source packages - was surprising...". Again, not surprising if what is being measured is raw unanalyzed tool output. It could be that every single "vulnerability" is a false positive (not an uncommon result, unfortunately). I would agree with them that I'd like to see more projects use more tools, but a lot of FLOSS projects do use tools. For example, the Linux kernel developers ended up creating their own static analysis toolsuite because tools are normally designed to analyze applications, not kernels.
The claim that this is representative of FLOSS is unfounded, since it only considers a few Java programs and ignores their enterprise support options (which is what you'd use for an enterprise!). I really wish they'd explained what they meant by issues; the problem of tool false positives is very well known, and I don't see that they really addressed that.
The original said: "Government and commercial organizations that leverage open source should use open source applications with great caution. Risk analysis and code review should be performed on any open source code running in business-critical applications...". Um, let's try: "Government and commercial organizations that leverage software should use software with great caution. Risk analysis and code review should be performed on any software running in business-critical applications..."
I propose Offset 2000 version numbers, i.e., "(y-2000).mm[.dd]". The first number is the year minus 2000, followed by "." and a two-digit month, optionally followed by "." and a two-digit day when there's more than one release in a month. So version 8.07 would be the first release in July 2008. If you made a later release on July 17, it'd be 8.07.17 (so if a project makes many releases in a month, you can again determine how old yours is).
Date-based version numbers have a lot going for them, because at a glance you know when it was released (and thus you can determine how old something is). If you choose the ISO order YYYY.MM.DD, the numbers sort very nicely; Debian packages often use YYYYMMDD for versioning. But there's a problem: full year numbers, or full dates in this format, are annoyingly large. For example, version numbers 2008.07.16 and 20080716 are painfully long version numbers to remember. That's not necessary.
So, use dates, but shorten then. Since nothing today can be released before 2000, shorten it by subtracting 2000. Note this is subtracting - there's no Y2K-like rollover problem, because the year 2100 becomes 100 and the year 3000 becomes 1000. The second number is the month; using a two-digit month means you don't have the ambiguity of determining if "2.2" is earlier or later than "2.10" (you would use "2.02" instead). If you need to disambiguate day releases (or you make additional releases in the same month), add "." and a two-digit day.
These version numbers are short, they're easy to compare, and they give you a clue about when it happened. Ubuntu already uses this scheme for the first two parts, so this scheme is already in use and familiar to many.
If you use a time-based release system, using this version numbering system is easy, and you can even talk about future releases the same way. But what if you release software based on when the features are ready, or want to talk about the system under development? You can't easily call it by the version number, since you don't know it yet, but that's not really a problem. In many cases, you can just talk about the "development" version or give a special name to the development version (e.g., "Rawhide" for Fedora). If you need to distinguish between multiple development versions, just give each of them a name (e.g., "Hardy Heron" for Ubuntu); on release you can announce the version number of a named branch (e.g., "Hardy Heron is 8.04"). This is more-or-less what many people do now, but if a lot of us used the same system, version numbers would have more meaning than they do now.
Ada has a lot going for it when it "has to be correct every time"; that is its main purpose. The big advantage is that the language maximally checks everything at compile time - so if it HAS to work correctly every time, that's a big plus. It also has more run-time checks. It even has some extra features that let it be more specific. It has a nearly-unique ability to specify number ranges; if you spec a variable as being in the range 1..100, then any attempt to assign outside that range is immediately detected. That turns out to detect lots of errors before they get out of hand. It's not the best language for EVERY purpose, but it has its place. I have a tutorial here, if you're curious: Lovelace tutorial.
George Packer Berry was the Dean of Harvard Medical School (1949-1965) and had a much wiser approach to information. In an address to students at the Medical School, he said, "Half of what we are going to teach you is wrong, and half of it is right. Our problem is that we don't know which half is which."
You need to check information from any source when it matters to you. You think that published books are always better? Check this one out: Lies My Teacher Told Me: Everything Your High School History Texbook Got Wrong by James W. Loewen. Indeed, according to one study, Most scientific papers are probably wrong. One study found that Wikipedia and Encyclopedia Britannica had similar error rates.
Wikipedia is new, so it's forcing people to notice something that was always true about any information, but that they've been ignoring up to now: You need to check information that's important to you.
If you're looking for "compromises", you should look at OOXML, not ODF. Rob Weir shows that OOXML is full of a massive number of errors - I estimate over 172,000 unresolved errors. These comments about ODF are without merit; OpenDocument can handle change requests (see, for example, section 4.6) and tables in presentations. OpenDocument 1.0 handles tables-in-presentations just fine, they're just encoded differently than you seem to be expecting. Embedded tables are encoded as embedded spreadsheets; this is slightly different than how OOXML encodes it, but all the data and capabilities are there. OpenDocument 1.2 will make the indirection optional, but this is all invisible to end-users anyway. Note that this means that tables CAN be in presentations, but more importantly, they're encoded the same way that they are encoded in other kinds of documents - OpenDocument has a single, clear table model. In contrast, OOXML has multiple incompatible table models. OpenDocument is remarkably consistent, as well as building on well-established standards - which is why it can be so much smaller, and so much more capable, at the same time.
Sure, many office suites will implement some subset of OOXML. But it would be wise to view it as a temporary transition format, so that you can escape from vendor-specific formats to an open standard like ODF. Yes, it's convenient to have it as a "published standard", but Ecma is enough for that; there's no reason to have an ISO stamp on it. OOXML is essentially the proprietary format of a single vendor. There's no reason to confuse anyone into thinking it's some sort of universal format, and the ISO stamp is likely to cause that kind of confusion.
The format for documents should not be controlled by any single office document supplier. That is a key reason why OOXML should be rejected by ISO, and published only by Ecma as some sort of interim format (to enable people to move off it). OOXML is also so error-ridden that it should have been laughed out of the fast track process.
It's a really bad spec, and should never have been submitted to the "fast track" process. Rob Weir analyzed OOXML using a sampling technique, and found that the ISO process found 1.5% or less of the errors in the spec. That suggests there are at least 172,000 errors in the spec that were not even NOTED in the last gathering for ISO's fast track. Inigo Surguy's "Technical review of OOXML" also found a massive number of errors. It's hard to express how warped the process has become. In a five-day meeting, they couldn't address almost all the errors (because there were too many) - instead, they did a block vote, and I know of no one who really even understood what had been accepted by the vote. The countries "approving" the spec don't even have a final spec to approve - instead, it's an original document with a bunch of text describing the kinds of changes to be made to it.
It's not EXACTLY what you asked for, but another alternative is Federal Cyber Service: Scholarship for Service (SFS). Their goal is to "increase the number of qualified students entering the fields of information assurance and computer security...". Their "scholarship track" provides "funding to colleges and universities to award scholarships to students in the information assurance and computer security fields. Scholarship recipients shall pursue academic programs in information assurance for the final two years of undergraduate study, or for two years of master's-level study, or for the final two years of Ph.D.-level study. These students will participate as a cohort during their two years of study and activities, including a summer internship in the Federal Government. A limited number of students may be placed in National Laboratories and Federally Funded Research and Development Centers (FFRDCs)."
There's an easy solution: A grace period. Let the kernel developers know (done), let the kernel developers fix their kernels (done), and give time for such fixed kernels to spread. Change the compiler so that it won't generate the "unnecessary" code, but DISABLE that by default for a while. After a long time (two years? More?), switch to enable-by-default. This change has no useful upside for users, and lots of downsides (in terms of broken programs), so there's no reason to hurry it. It's fine to do it, but just do it slowly.
Vista complaints have nothing to do with "too much backwards compatibility"; one of the key Vista problems is a LACK of adequate backwards compatibility: http://www.iexbeta.com/wiki/index.php/Windows_Vista_Software_Compatibility_List#Heavy_Problems.2C_Currently_Incompatible http://www.pcmag.com/article2/0,1759,2104022,00.asp
The only reason to run Windows (any version) is to be able to use the hardware and software that is only compatible with Windows. I know of no one who claims that Windows is the "best operating system on Earth", by any measure; people choose Windows for application compatibility, not for its "innovation". A "grossly incompatible Windows" is completely worthless.
Similarly, even if it's in the spec, it's absurd to change a system and make it so user programs just break. Think of the users. Instead, figure out how to make the change WITHOUT harming the users. That user might be you.
Instead, use another term when you mean "you can read the source code". I suggest "source available".
I just entered =850*77.1 into OpenOffice.org, and it gets the correct answer. It's rediculous that a freely-available program can get basic calculations correct, and Excel can't.
OpenOffice.org doesn't require Sun's JVM. I believe the OpenOffice.org implementation on Fedora is compiled with gcj.
There are lots of good reasons to release code under the BSD license. For example, getting widespread use of an idea or protocol sometimes works best with BSD-style licenses. Many standards groups try to create at least "sample implementations" using BSD-licensed code, so that anyone can grab the code to put into their programs. But the BSD license isn't the be-all of licenses (nor is the GPL). I (and many others) believe the license difference is one of the main reasons the Linux kernel has completely eclipsed the *BSDs in market share, even though the *BSDs started first. If any company made a real improvement to the *BSDs, they often kept it proprietary, while any improvements to the GPL'ed Linux must not be proprietary, so the *BSDs get very little corporate help, while in the Linux kernel, companies spend real money to contribute code.
I don't want to call it "stupid", but choosing a license that doesn't even slightly meet your goals isn't a good idea. Choose your license for a project based on your goals for that project, and that may be different between different projects.
Yeah, Theo is younger and fitter, but Stallman has a katana in imitation of this xkcd cartoon :-).
A little lightening up would be good, frankly.
As noted in LWN, this kerfluffle seems to have been kicked off when "wireless developer Jiri Slaby posted a patch which stripped the ISC and BSD license notices from the source, replacing them with GPLv2 license text. It should be noted that this patch was not accepted into any repository anywhere and never became part of any exported Linux kernel tree. Nonetheless the BSD community exploded in a very public way. It is interesting to compare their public response to this posting with the sort of response they very loudly insisted was their due when they were found to have carried improperly relicensed GPL code in their repository for some time."
Certainly it is NOT okay to remove the copyright notices from BSD material, as long as there's something left in the file that's covered by the BSD license. So, don't do that. But you CAN take a BSD work, combine it with other works, and have the final result as essentially GPL'ed or proprietary. My FLOSS license slide even helps you figure out when you can do that, and when you can't.
But that only covers the legal issues. If there's an existing project that releases something under an OSS license, it's usually better to continue to use their license than to fork off another project under a new license, especially if you're not making many changes. For a lot of reasons.
LWN's article "Relicensing: what's legal and what's right" is worth a look.
Allowing someone else to control all of your information has always been a foolish decision.
If the DRM identifies individuals, then there's certainly a big risk of loss of privacy. Putting your name, credit card number, and expiration date is kindof cutesy.... it certainly gives you an incentive to not give a copy to everyone else :-). But there are too many ways for the files to get "stolen" by others. Computers get broken into all the time. Heck, someone could just walk into a room where you're playing a song, record it, and send it to a million people... and it'd get identified as "yours". So while for a little while the courts might pretend that it's always the buyer's fault, that won't last... even if the courts really enforced it, the result would be that no one would buy music. After all, pirated songs would be WAY less dangerous, since they wouldn't implicate YOU.
But watermarks that only identifies "what song is this" is actually pretty reasonable. Some countries (like Canada) have imposed a repay scheme; the idea of monitoring "which songs are most copied" and then compensating that way has SOME merit, at least. Beats DRM.
Of course, throwing away all that stuff, and just selling basic songs at a reasonable price, in open formats that aren't patent-encumbered and EVERYONE can use, would be frankly the best. Why bother with a complicated technical system - why not just sell the customer what they wanted in the first place? If they made it easy for customers to buy what they actually wanted, they wouldn't have been training up a generation of pirates.
Never mind "outcompete" in terms of reducing the number of oxygen-producing algae. Worldwide ocean fires will eliminate a lot more than the algae.
I actually _use_ atime values, directly.... because sometimes I really do want to know when something was last accessed. This is as a human, not a program, so saying "well fix the program" isn't helpful. And it's been built into Unix from the beginning, so it's not like it's some amazing new capability. But I agree that I typically don't need fine-grained knowledge of when something was last used; I'm usually looking to see what is old cruft, etc. Some programs only need "was it accessed after modification", and certainly there's a performance hit for atime. So this "relatime" looks great to me.... I get my "cruft" information, and existing programs work, without the performance hit of traditional atime. As long as there's a WAY to force the traditional atime to be supported (via some mount-time option), I think relatime (even as a default) is a reasonable compromise. Relatime gives higher performance in exchange for a poorer quanta on atime, and for many, that's probably a worthy trade.
I like the idea of writing the "more accurate" atime when it's "for free". I don't see the big advantage of ALWAYS being a day late... I think it's better to say "at worse, it's a day late, but it MIGHT be better".
For the sarcasm-impaired: The previous paragraph is obviously lunacy. Since it's lunacy, I think having non-lethal alternatives is a GOOD idea. Foes of yesterday may be friends tomorrow (think Japan of WW II, etc.), so even if you're in a war, you may NOT need to kill your foe. It'd be great to avoid killing in many cases. Wouldn't it be great if there were LESS carnage in the future, not MORE? Wouldn't it be great if after a confrontation, most wives / children / parents got their loved ones back?!?
Now this particular approach may not be very effective; maybe another one needs to be investigated instead. The term "non-lethal" is misleading; they DO kill occasionally (they just kill less often), and since they kill sometimes, they need to be reserved for serious situations the way lethal approaches are. That said, if you do not NEED to kill all your foes, having a "mostly non-lethal" alternative would be WAY better than the "mostly lethal" approach we have now.
Yes, there's a risk that non-lethal approaches would be employed to create a police state. But you can have police states with lethal approaches too, and in fact, I'd argue that lethal approaches are more effective at countering civilians. Dead civilians don't try again. If there's a non-lethal approach, the civilians can try again later, something you can't say about lethal approaches.
If you want to use software, you must have software to use. If you want to have software to use, there must be a way to develop it. The GPL has been the "Constitution" enabling the development of a vast amount of really useful software; indeed, the majority of Free-libre / open source software (FLOSS) uses the GPL. And people are finally realizing that most FLOSS is commercial software; it's no longer exclusively "just a hobby". Before the GPL, the only ways of creating software were complete proprietary control (often by a company intent on preventing you from switching) or public domain/BSDish licenses (which sometimes works very well, but sometimes get sucked into proprietary projects often enough to die or live only on life support). So yes, if you wish to be able to use software in the future, the GPL is important; it establishes a viable method of making the software that people would like to use. In fact, it's been extraordinarily effective at doing so.
Even you don't write code yourself, you can still hire someone to write or change code. So the GPL provides additional capabilities to users, even if the user can't write code him/herself. And even if you use proprietary software, GPL'ed software has had a profound impact on limiting the costs of much of that software, which is also great for end-users (and again matters to them).
Here's an analogy - that statement is like saying that agriculture doesn't matter because many people aren't farmers. But non-farmers must eat too! Having viable methods to grow food - and a competitive system to lower costs and raise quality - are still of vital interest to the users of products from farmers. Unless you want to stop eating.
Then whatever format wins will be actually useful by real people, so they can see the movies on any computer or TV they own, using any display they choose, and using any operating system. So they can back up their media (which always gets scratched or otherwise destroyed). And so they can view only the portions THEY want to see, and under "fair use" can create new works based on those products.
Copyright was created as a balance between the needs of initial authors vs. the needs of later authors and users, and DRM is trying to circumvent the law to upset the balance. With a little time, the balance should be restored.