You can see more about Ada 2012 here; the rationale is probably the best place to start.

Yes, this is similar to the assert mechanism of C, Python, etc., but because it's built into the language, it can do some extras. Often these are optimized out, because the compiler can determine that they're always met. You can also define a "Type_Invariant" once, and then the invariant is checked every time the value can be changed from the point of view of a user (e.g., after initialization, conversion, or return of a value of that type). A type_invariant is like inserting C "assert" calls in every call that might return it, but only having to say it once.

Yes, people are using Ada, in fact, it's been making a quiet comeback. Ada is the #16 most popular language according to the TIOBE programming language survey of November and December 2012, an increase from #19 in November 2011. Keller reports that by 2000 Ada use had decreased and then increased again. It's not huge compared to C or Java, of course; its use is focused in certain domains. In certain communities, such as aviation software, it continues to be a popular language and has been credited with helping to produce high-quality software within time and budget.

Historically, Ada was developed by the Department of Defense (DoD), and the DoD tried to make it the one and only universal language . An NRC report on Ada talks about this. Fundamentally, trying to make one language do everything was a bad idea, and predictably failed; there is still no one language that can be all things to all people, even many years later.

Ada isn't a complex language by today's standards, but it has a lot of "pickiness" that means you have to obey more rules. Is that a good thing? Well, you first have to understand what it was designed for - and then decide if that design is what you want.

Ada focuses on software that needs high reliability and yet absolutely no compromise of performance. If reliability isn't really all that important to you, or you can give up a lot of performance, then Ada's trade-offs may not work for you. For reliability, it has a strong typing system, and you have to use generics (etc.) instead of just saying "shut up and trust me" a la C. For performance, it doesn't mandate automatic garbage collection (as compared to Java or Python). Ada shines when you're writing programs that will could un-intentionally kill people if the program is wrong or takes too long. Think airplane flight controls, train systems, medical systems, that sort of thing. A lot of Slashdot readers have never tried to write software that could accidentally kill people, and thus can't understand why you might want a "picky" language like Ada. If your response to "it has a bug" is just "install this patch" maybe another language would be fine. But when mistakes can kill, having a language that helps prevent them can be literally a lifesaver.

I disagree. You don't wait to build a fire escape until the building is on fire. Similarly, we need a good alternative hash algorithm now, not when disaster strikes.

I believe that, in general, we should always have two widely-implemented crypto algorithms for any important purpose. That way, if one breaks, everyone can just switch their configuration to the other one. If you only have one algorithm... you have nothing to switch to. It can take a very long time to deploy things "everywhere", and it takes far longer to get agreement on what the alternatives should be. Doing it in a calm, careful way is far more likely to produce good results.

The history of cryptography has not been kind, in the sense that many algorithms that were once considered secure have been found not to be. Always having 2 algorithms seem prudent, given that history. And yes, it's possible that a future break will break both common algorithms. But if the algorithms are intentionally chosen to use different approaches, that is much less likely.

Today, symmetric key encryption is widely implemented in AES. But lots of people still implement other algorithms, such as 3DES. 3DES is really slow, but there's no known MAJOR break in it, so in a pinch people could switch to it. There are other encryption algorithms obviously; the important point is that all sending and receiving parties have to implement the same algorithms for a given message BEFORE they can be used.

Similarly, we have known concerns about SHA-2, SHA-256, and SHA-512. Maybe there will never be a problem. So what? Build the fire escape NOW, thank you.

No, you're completely wrong, this is not the current policy of the United Stated federal government.

It's true that when a US government employee develops software, as part of his official duties, it is not subject to copyright in the US (with a few tiny exceptions). But that doesn't mean it actually gets released to the public; in almost all cases it is never released to the public. (Sometimes it does, like expect and Security-Enhanced Linux, but most of the time it doesn't). Even more importantly: most software developed using government funding is developed by contractors, not by government employees, in in most cases the rule about government employees doesn't apply anyway.

For the details of when software funded by the US government can be released as OSS, see this:"Publicly Releasing Open Source Software Developed for the U.S. Government" by Dr. David A. Wheeler (me), Journal of Software Technology, February 2011, Vol. 14, Number 1.

Now it's true that a few small parts of the US government do have such a policy. In particular, the Consumer Financial Protection Bureau's source code policy does share the code with the public at no charge by default.

I do agree that when "we the people" pay for the development of software, then by default "we the people" should get it (unless there's a good reason for an exception, e.g., it's a classified weapon system). Sounds like a good idea. It's even a good idea for the government itself, because it will greatly enable competition for future work (building on past work) and reduce redevelopment (because it'll be easier to find previously-developed stuff). But that's something people need to press for... don't assume it's already happened.

Ask for "release government-funded software as OSS by default" - don't assume it's already happened.

Not quite. It's true that a work of a U.S. federal government employee, performed as part of their official duties, cannot normally have copyright in the U.S. HOWEVER... most software developed for the government is developed by contractors, at least in part, and those parts DO have a copyright. (There are even a few exceptions for government employees, but they practically never apply.) Also, the term "public domain" has multiple meanings, presumably you mean public domain in the copyright sense (not the export control sense, which is different).

To see when contractors or the U.S. government can currently release software as OSS, see Publicly Releasing Open Source Software Developed for the U.S. Government by David A. Wheeler (me), Journal of Software Technology, February 2011. That's the current state of affairs.

I agree with the poster above: When "we the people" pay for software, then by default "we the people" should get it. I even posted an entry about that in 2010. Sure, there need to be exceptions, but they should be exceptions; it's not obvious why accounting software developed by the government is treated this way! I also agree that we should use clearer terms like intellectual rights (and intellectual works) - not "intellectual property" - because "intellectual property" is a fundamentally misleading term.

You might try bitpocket (see https://github.com/sickill/bitpocket or http://ku1ik.com/2011/07/18/bitpocket-as-a-dropbox-alternative.html ) or Unison.

Wikipedia, the source of all possible wisdom, says on http://en.wikipedia.org/wiki/Transporter_(Star_Trek) that "According to The Making of Star Trek, Star Trek creator Gene Roddenberry's original plan did not include transporters, instead calling for characters to land the starship itself. However, this would have required unfeasible and unaffordable sets and model filming, as well as episode running time spent while landing, taking off, etc. The shuttlecraft was the next idea, but when filming began, the full-sized shooting model was not ready. Transporters were devised as a less expensive alternative, achieved by a simple fade-out/fade-in of the subject. Transporters first appear in the original pilot episode "The Cage". The transporter special effect, before being done using computer animation, was created by turning a slow-motion camera upside down and photographing some backlit shiny grains of aluminium powder that were dropped between the camera and a black background." Citation given is Herbert F. Solow and Robert H. Justman, Inside Star Trek the real story, 1996, ISBN 0-671-00974-5.

Another engine option is the Delta3D game engine, which is open source software. The Delta3D project is run by the Naval Postgraduate School (NPS), and maintained just for this sort of thing. I hoped they examined that alternative before spending big bucks for an Unreal Engine license (if not, shame on them, and they need to look next time).

This is excellent news!

In some ways this policy (of the US Federal Consumer Financial Protection Bureau) picks up from the the US Department of Defense (DoD) policies. Unfortunately, the DoD just changed the URLs for some of its information on Open Source Software (OSS), and doesn't (yet) have redirects, making them hard to find and compare. So here are new links to the DoD stuff on open source software, if you want them.

A good place to start is the Department of Defense (DoD) Free Open Source Software (FOSS) Community of Interest page, hosted by the DoD Chief Information Officer (CIO).

From that page, you can reach:

• Clarifying Guidance Regarding Open Source Software (OSS) Memorandum by David M. Wennergren, 16 October 2009 - this is the overall DoD policy on OSS
• Open Technology Development (OTD): Lessons Learned & Best Practices for Military Software - OSD Report, May 2011 - this is guidance on how to develop and use OSS
• DoD Open Source Software (OSS) Frequently Asked Questions (FAQ) - this has lots of answers to questions about OSS, focusing on DoD issues
• Use of Free and Open-Source Software (FOSS) in the U.S. Department of Defense - 2003 Study by MITRE Corporation performed for DoD - a report by MITREs Terry Bollinger showing that the DoD was already using OSS widely in 2002-2003.

If you are interested in the topic of DoD and OSS, you might also be interested in the Military Open Source Software (Mil-OSS) group.

I hope that the IETF group insists on Microsoft's contributing being patent-free or royalty-free. Otherwise, this proposal should be instantly rejected. Same for Google and SPDY.

The sun's energy output will increase until there will be no liquid water on the surface in about 1 billion years (unless there's some kind of intervention). Personally, I think we should plan on moving spaceship Earth before then.

Fun! This 6502-assembler-in-LISP looks similar to Henry G. Baker's "COMFY" 6502 compiler (described in "The COMFY 6502 compiler", SIGPLAN Notices, 1997). You can check out the COMFY-6502 implementation that uses Common Lisp (sadly this appears to be entrapped in the ACM non-commercial-use-only license, though for 6502 code that isn't very limiting). One cool thing about the approach of using LISP as an "assembler" in general is that unlike many traditional macro assemblers, this approach can easily do stuff like choose the optimal instruction set for branches because it can determine if it's in range for a short branch and use them when available. You can do it other ways, of course, but it's pretty elegant in LISP. Those interested in this sort of thing might like my page on 6502 Language Implementation Approaches or my page on making LISP-based languages more readable (especially sweet-expressions).

It's not the same. Obviously, we have to depend on companies every day. But if we don't like a car company, or a traditional ISP, we can switch to another car or ISP. Facebook is different. If you leave, you leave the ability to connect to many of the people that you connected to via Facebook.

I own my own domain name, and use email and blogs to communicate from a site whose name I own. I do depend on companies to support my DNS and webservice. But if I don't like what those companies do, I can switch or do it myself. I have a Facebook account, but I don't normally use it; it just creates too many problems.

We all need suppliers; that's not the problem. The problem is dependency, that is, being (practically) unable to switch. Being dependent on an external company really is a risk.