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.
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).
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.
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).
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.
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.
Looks like Henry G. Baker's COMFY 6502 compiler
on
Hacking the NES With Lisp
·
· Score: 3, Interesting
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.
I disagree regarding reusing search engines. A government agency can simply allow all search engines to scan their public files, and then anyone can choose any search engine they want to (and find what they need). There's no law that the government has to FORBID access to public data from search engines; that would be a stupid thing to do. In fact, it's usually a bad idea for the government to provide their own search engine. Governments should not pay for a special search engine for publicly-available documentation, unless they're providing some unique extra capability not provided by commercial search engines.
It's plausible that federal government sites aren't allowed to embed Google (or Bing), because they don't want to prefer a particular search engine. But if you think that they cannot, please quote the federal law or regulation, I'd like to know what that is. For example, the Small Business Administration uses Google site search, see:
http://www.sba.gov/content/search-engine-0.
The Energy department should not have wasted a dime of public money on a specialized search engine built into their website. Yet it looks like they did just that. Government agencies should focus on getting the documents posted in standard formats (e.g., PDF) and then let commercial engines do all the work. You get bonus points if you mark the documents with key metadata (title, authors, abstract, date), but even without that, most commercial search engines can find lots. I'm not the first to note that, several articles have noted this.
If an agency just HAVE to have a search engine on the page, they can just reuse a commercial one. For example, if you want to reuse Google, just follow the instructions here: http://www.google.com/sitesearch/ which just inserts a few lines of HTML. From then on, all done. You can see an example on my website front page at www.dwheeler.com. I don't actually do the searching... I just redirect to Google. And users don't have to use Google, they can use any search engine they find convenient.
Take a look at my book on secure programming: http://www.dwheeler.com/secure-programs/. I wrote it after I saw software getting broken into, again and again, for the same old reasons.
I don't know about German law, but in the US, you're innocent until proven guilty. They *DO* have proof that their music is all CC licensed, but GEMA won't accept the proof. Perhaps this can be brought into the courts and ruled to be an unenforceable law (since it presumes guilt instead of innocence)? Or is that not a basic concept in German law?
Correct, there is no "world" overpopulation issue. For more info, see the Wikipedia page on world population growth. A few areas of the world have a massive growth rate (mainly central Africa, plus a few countries in southwest Asia), and many of those are almost certainly overpopulated (since they cannot really support themselves).
But most of the world is around the replacement rate or lower. In many areas, the current population will go extinct if current rates continue. Even in the U.S., the total fertility rate in the United States estimated for 2009 is 2.01 children per woman, which is below the replacement fertility rate of approximately 2.1 (it's more than 2 due to premature death, etc.). In other words, the current US local replacement rate isn't enough to sustain the current US population. Immigration keeps the US population numbers going up; it's not due to internal replacement. The rates for many other industrialized nations are even lower. So for most countries, there is no explosive growth; instead, they are shrinking. Even if you think world overpopulation is an issue, the birth rate is slowing overall.
Most announcements about the "world population" figures don't make it clear that population growth isn't the same everywhere, and that rapid growth is actually really localized. It'd be just as accurate to say "the US local population is declining" since it is.
Unless the build system is screwed up, recompiling after a change should be relatively fast. Usually source code is stored as lots of smaller files, and each file is compiled separately to produce a separate object file (e.g.,.o). Then next time a rebuild is requested, the system should notice what changed, and only rebuild the needed parts. Some parts take the same time each time (e.g., a final link), but it shouldn't take anywhere near the same amount of time.
There are lots of build tools, including make, cmake, and so on. If you use the venerable "make" tool, you might want to read Miller's "Recursive Make Considered Harmful":
http://aegis.sourceforge.net/auug97.pdf
Cue the lovers and haters of "make", here:-).
The problem here is that someone needs to organize these things.
True, but not relevant. The necessary organization and infrastructure can be done quite cheaply, if organizations are willing to move from the past to the present.
Someone has to pay for the bandwidth, buy and run the servers, spend effort soliciting reviewers, run the reviewing software, respond to questions, request ISBNs, submit the work to indexing sites, etc etc etc..
I think you're grossly overestimating the costs if they switch to an exclusively digital realm, which is where they need to go. Bandwidth and running basic servers (which is all that's needed) are commodities. WebHostGiant will provide bandwidth and basic servers for $2.79/month with no bandwidth maximum. A serious journal will want more than that, yes, and there are other requirements too. For example, you'll need DNS registration (which companies like GoDaddy or 1and1 will do for cheap). But really, these are highly-competed commodities, so we're talking about petty cash budgets in most companies. You could probably set up the technical infrastructure for less than $100/year, plus 20 hours of volunteer time for the initial setup. Just get 5 people to contribute $20/year and you're done. The exact number isn't important; what's important is that it is REALLY REALLY small compared to paper-based publication.
Yes, you need some code to manage reviews, but not much. Existing programs can do the job; you really don't need more than a Wiki or mailing list. You can get some efficiencies using specialized programs, but their development could be amortized across lots of different journals (it's perfect for creating as open source software; there are probably several such programs already). It's clearly possible; Wikipedia's MediaWiki, for examples, wasn't developed by a for-profit organization, and it handles scales far beyond what journals require.
You need an ISSN, not an ISBN, for a magazine, and that's a one-time expense.
The "soliciting reviewers" and so on can be done by volunteers, as is already often done.
The basic problem is that paper publishers haven't noticed that the digital economy is VASTLY cheaper (or they're scared BECAUSE they realize this).
Open access journals address this by having a publication fee, or by advertising, or by seeking volunteers and asking for charity. Paying for publication gets blurry with vanity press, and advertising ends up sucking up to the advertisers.
So stop pushing the paper. Push the bits, and let people print what they want. For academic works, what people (should) want is the information, not the pretty binding.
Volunteering and charity seem wonderful, but have to compete with lots of other worthy causes.
Absolutely true. But if it's easy, it's not too bad. Also, volunteering for journals is considered something valuable in many academic circles, so it's not just charity in many cases.
The paywalled journals depend on volunteerism already, so it's not a change in that respect. And when people don't feel exploited, they're more likely to volunteer.
In CS, most of the major publishers allow you to post a copy of your paper on your personal website (as long as you also link to the official version). Finding papers outside of the paywalls is only difficult when the authors are in industry (but those aren't the publicly funded papers you're talking about anyway).
Fair enough. But typically CS researchers are writing papers because they want to get information out to the widest possible audience that would be interested. Paywalls just get in the way, for reasons that are now obsolete.
This is big. There are a lot of parasitic journals today, that is, journals that take work the public paid for, and lock it behind paywalls. Parasitic journals typically use big-name free labor from to do the peer reviews. If the world removes from the parasites many good peer reviewers, as well as many good papers (through policies like the NIH Public Access policy), then they will have to change or fold. I don't have a problem with organizations paying for work to be done, and then charging for use of the result. For example, most fiction authors get at least some money for their labor (not a lot, but at least some). In contrast, parasitic journals typically take publicly-funded stuff away from the public; time to change.
By the way, there are a number of journals and publications that have always done this, like ACSAC. If authors would simply ONLY submit their works to open access journals and publications, the parasites would disappear.
We're going to see more of this sort of thing. Almost everyone assumes that all software is copyrighted, or that only the copyright holder can release software as free/libre/open source software (FLOSS). Neither are true!! This matters when the US government gets involved, because its "normal" rules are really different from most organization's.
For example, if a government employee develops software as part of his official duties, then in practically all cases that software is NOT subject to copyright in the US (per US law 17 USC 105). It's not just that the author doesn't have copyright; there IS no copyright in the US. Also, when a contractor writes software, the government often receives all the release rights as if it was the copyright holder yet it is not the copyright holder (these are called "unlimited rights"). In this case, the government can release the software as FLOSS, on its own initiative, even though it is NOT the copyright holder. For more details, see: Publicly Releasing Open Source Software Developed for the U.S. Government.
The US government spends billions of dollars each year developing software. It's my hope that, over time, it will release more of the software it develops to the people who paid for it.
I wrote PhD thesis using Open Document Format (ODF) and it worked out very well. I used OpenOffice.org, but I expect that LibreOffice would work at least as well. You can translate to many other formats (e.g., with "Save As" or external tools).
As with any big writing effort, one key is to separate formatting from content. You should FIRST set up a template with that does all the formatting, including all the paragraph types you'll need and the right format for them. Then write your document, selecting the paragraph types for each paragraph as appropriate. Do NOT embed formatting commands in the document itself - paragraphs should NOT have font settings, etc., but instead these should be controlled by the paragraph's paragraph type. In my case, I created an OpenDocument template for George Mason University (GMU), and gave it to GMU so others could share it. If you create a template, please share it with others.
I have paper tape for various programs I wrote for a DEC PDP-8. I've occasionally shown the paper tape, just to show how much better things have gotten since then.
I also have an Apple ][+ and an Apple//e. The Apple ][+ is actually an original Apple ][, but with a new motherboard (due to a blown capacitor that fried the board). I sometimes bring out the Apples and run the games I wrote for them. A number of the disks are still readable, believe it or not.
As far as I'm concerned, what matters for games is if they are FUN. 100 FPS doesn't matter if it's boring. There are games that are text-only, or run on 40x40 pixel blocks, that are lots more fun, and that makes them better games.
Crafty is not open source software, though its license has similarities to an open source software license.
Crafty is for "personal use only", which means that it fails the Open Source Definition criteria "No Discrimination Against Fields of Endeavor".
Crafty's main.c file says: "All rights reserved. No part of this program may be reproduced in any form or by any means, for other than your personal use, without the express written permission of the authors. This program may not be used in whole, nor in part, to enter any computer chess competition without written permission from the authors. Such permission will include the requirement that the program be entered under the name "Crafty" so that the program's ancestry will be known."
Slashdot Mirror
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:
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.
I disagree regarding reusing search engines. A government agency can simply allow all search engines to scan their public files, and then anyone can choose any search engine they want to (and find what they need). There's no law that the government has to FORBID access to public data from search engines; that would be a stupid thing to do. In fact, it's usually a bad idea for the government to provide their own search engine. Governments should not pay for a special search engine for publicly-available documentation, unless they're providing some unique extra capability not provided by commercial search engines.
It's plausible that federal government sites aren't allowed to embed Google (or Bing), because they don't want to prefer a particular search engine. But if you think that they cannot, please quote the federal law or regulation, I'd like to know what that is. For example, the Small Business Administration uses Google site search, see: http://www.sba.gov/content/search-engine-0.
The Energy department should not have wasted a dime of public money on a specialized search engine built into their website. Yet it looks like they did just that. Government agencies should focus on getting the documents posted in standard formats (e.g., PDF) and then let commercial engines do all the work. You get bonus points if you mark the documents with key metadata (title, authors, abstract, date), but even without that, most commercial search engines can find lots. I'm not the first to note that, several articles have noted this.
If an agency just HAVE to have a search engine on the page, they can just reuse a commercial one. For example, if you want to reuse Google, just follow the instructions here: http://www.google.com/sitesearch/ which just inserts a few lines of HTML. From then on, all done. You can see an example on my website front page at www.dwheeler.com. I don't actually do the searching... I just redirect to Google. And users don't have to use Google, they can use any search engine they find convenient.
Take a look at my book on secure programming: http://www.dwheeler.com/secure-programs/. I wrote it after I saw software getting broken into, again and again, for the same old reasons.
I don't know about German law, but in the US, you're innocent until proven guilty. They *DO* have proof that their music is all CC licensed, but GEMA won't accept the proof. Perhaps this can be brought into the courts and ruled to be an unenforceable law (since it presumes guilt instead of innocence)? Or is that not a basic concept in German law?
Correct, there is no "world" overpopulation issue. For more info, see the Wikipedia page on world population growth. A few areas of the world have a massive growth rate (mainly central Africa, plus a few countries in southwest Asia), and many of those are almost certainly overpopulated (since they cannot really support themselves).
But most of the world is around the replacement rate or lower. In many areas, the current population will go extinct if current rates continue. Even in the U.S., the total fertility rate in the United States estimated for 2009 is 2.01 children per woman, which is below the replacement fertility rate of approximately 2.1 (it's more than 2 due to premature death, etc.). In other words, the current US local replacement rate isn't enough to sustain the current US population. Immigration keeps the US population numbers going up; it's not due to internal replacement. The rates for many other industrialized nations are even lower. So for most countries, there is no explosive growth; instead, they are shrinking. Even if you think world overpopulation is an issue, the birth rate is slowing overall.
Most announcements about the "world population" figures don't make it clear that population growth isn't the same everywhere, and that rapid growth is actually really localized. It'd be just as accurate to say "the US local population is declining" since it is.
Unless the build system is screwed up, recompiling after a change should be relatively fast. Usually source code is stored as lots of smaller files, and each file is compiled separately to produce a separate object file (e.g., .o). Then next time a rebuild is requested, the system should notice what changed, and only rebuild the needed parts. Some parts take the same time each time (e.g., a final link), but it shouldn't take anywhere near the same amount of time.
There are lots of build tools, including make, cmake, and so on. If you use the venerable "make" tool, you might want to read Miller's "Recursive Make Considered Harmful":
http://aegis.sourceforge.net/auug97.pdf
Cue the lovers and haters of "make", here :-).
The problem here is that someone needs to organize these things.
True, but not relevant. The necessary organization and infrastructure can be done quite cheaply, if organizations are willing to move from the past to the present.
Someone has to pay for the bandwidth, buy and run the servers, spend effort soliciting reviewers, run the reviewing software, respond to questions, request ISBNs, submit the work to indexing sites, etc etc etc..
I think you're grossly overestimating the costs if they switch to an exclusively digital realm, which is where they need to go. Bandwidth and running basic servers (which is all that's needed) are commodities. WebHostGiant will provide bandwidth and basic servers for $2.79/month with no bandwidth maximum. A serious journal will want more than that, yes, and there are other requirements too. For example, you'll need DNS registration (which companies like GoDaddy or 1and1 will do for cheap). But really, these are highly-competed commodities, so we're talking about petty cash budgets in most companies. You could probably set up the technical infrastructure for less than $100/year, plus 20 hours of volunteer time for the initial setup. Just get 5 people to contribute $20/year and you're done. The exact number isn't important; what's important is that it is REALLY REALLY small compared to paper-based publication.
Yes, you need some code to manage reviews, but not much. Existing programs can do the job; you really don't need more than a Wiki or mailing list. You can get some efficiencies using specialized programs, but their development could be amortized across lots of different journals (it's perfect for creating as open source software; there are probably several such programs already). It's clearly possible; Wikipedia's MediaWiki, for examples, wasn't developed by a for-profit organization, and it handles scales far beyond what journals require. You need an ISSN, not an ISBN, for a magazine, and that's a one-time expense.
The "soliciting reviewers" and so on can be done by volunteers, as is already often done.
The basic problem is that paper publishers haven't noticed that the digital economy is VASTLY cheaper (or they're scared BECAUSE they realize this).
Open access journals address this by having a publication fee, or by advertising, or by seeking volunteers and asking for charity. Paying for publication gets blurry with vanity press, and advertising ends up sucking up to the advertisers.
So stop pushing the paper. Push the bits, and let people print what they want. For academic works, what people (should) want is the information, not the pretty binding.
Volunteering and charity seem wonderful, but have to compete with lots of other worthy causes.
Absolutely true. But if it's easy, it's not too bad. Also, volunteering for journals is considered something valuable in many academic circles, so it's not just charity in many cases. The paywalled journals depend on volunteerism already, so it's not a change in that respect. And when people don't feel exploited, they're more likely to volunteer.
In CS, most of the major publishers allow you to post a copy of your paper on your personal website (as long as you also link to the official version). Finding papers outside of the paywalls is only difficult when the authors are in industry (but those aren't the publicly funded papers you're talking about anyway).
Fair enough. But typically CS researchers are writing papers because they want to get information out to the widest possible audience that would be interested. Paywalls just get in the way, for reasons that are now obsolete.
This is big. There are a lot of parasitic journals today, that is, journals that take work the public paid for, and lock it behind paywalls. Parasitic journals typically use big-name free labor from to do the peer reviews. If the world removes from the parasites many good peer reviewers, as well as many good papers (through policies like the NIH Public Access policy), then they will have to change or fold. I don't have a problem with organizations paying for work to be done, and then charging for use of the result. For example, most fiction authors get at least some money for their labor (not a lot, but at least some). In contrast, parasitic journals typically take publicly-funded stuff away from the public; time to change. By the way, there are a number of journals and publications that have always done this, like ACSAC. If authors would simply ONLY submit their works to open access journals and publications, the parasites would disappear.
We're going to see more of this sort of thing. Almost everyone assumes that all software is copyrighted, or that only the copyright holder can release software as free/libre/open source software (FLOSS). Neither are true!! This matters when the US government gets involved, because its "normal" rules are really different from most organization's.
For example, if a government employee develops software as part of his official duties, then in practically all cases that software is NOT subject to copyright in the US (per US law 17 USC 105). It's not just that the author doesn't have copyright; there IS no copyright in the US. Also, when a contractor writes software, the government often receives all the release rights as if it was the copyright holder yet it is not the copyright holder (these are called "unlimited rights"). In this case, the government can release the software as FLOSS, on its own initiative, even though it is NOT the copyright holder. For more details, see: Publicly Releasing Open Source Software Developed for the U.S. Government.
The US government spends billions of dollars each year developing software. It's my hope that, over time, it will release more of the software it develops to the people who paid for it.
See: http://en.wikipedia.org/wiki/Whitespace_(programming_language)
I wrote PhD thesis using Open Document Format (ODF) and it worked out very well. I used OpenOffice.org, but I expect that LibreOffice would work at least as well. You can translate to many other formats (e.g., with "Save As" or external tools).
As with any big writing effort, one key is to separate formatting from content. You should FIRST set up a template with that does all the formatting, including all the paragraph types you'll need and the right format for them. Then write your document, selecting the paragraph types for each paragraph as appropriate. Do NOT embed formatting commands in the document itself - paragraphs should NOT have font settings, etc., but instead these should be controlled by the paragraph's paragraph type. In my case, I created an OpenDocument template for George Mason University (GMU), and gave it to GMU so others could share it. If you create a template, please share it with others.
I have paper tape for various programs I wrote for a DEC PDP-8. I've occasionally shown the paper tape, just to show how much better things have gotten since then.
I also have an Apple ][+ and an Apple //e. The Apple ][+ is actually an original Apple ][, but with a new motherboard (due to a blown capacitor that fried the board). I sometimes bring out the Apples and run the games I wrote for them. A number of the disks are still readable, believe it or not.
As far as I'm concerned, what matters for games is if they are FUN. 100 FPS doesn't matter if it's boring. There are games that are text-only, or run on 40x40 pixel blocks, that are lots more fun, and that makes them better games.
Crafty is not open source software, though its license has similarities to an open source software license. Crafty is for "personal use only", which means that it fails the Open Source Definition criteria "No Discrimination Against Fields of Endeavor".
Crafty's main.c file says: "All rights reserved. No part of this program may be reproduced in any form or by any means, for other than your personal use, without the express written permission of the authors. This program may not be used in whole, nor in part, to enter any computer chess competition without written permission from the authors. Such permission will include the requirement that the program be entered under the name "Crafty" so that the program's ancestry will be known."
Fruit up to 2.1 is open source software (GPL)
The summary doesn't mention cmake or maven. That's bizarre. I hope the actual book covers those; those are really common and useful.