This makes no sense. If you want to search for code, the obvious way to do it today is use Google or some other search engine. Tomorrow, the obvious way to do it... will be to use Google or some other search engine. You don't need a "federated search", you just need a good search engine. There are a number of code-specific search engines that already work today too, again, there's no need for one system to rule them all.
I think there's great advantage in having an OSS management system for managing OSS projects.
This is very common in the military and in defense contractors, and it happens elsewhere too. There is a reason for it. Many of these organizations are worried about malicious stuff going in and/or exfiltration of non-public data going out. Employer MITM makes it easy to examine every packet for these kinds of things (to counter them). In the US, at least, it's generally accepted that employer equipment is owned by the employer, and thus they expressly have the authority to examine what goes over their own network... and as a condition of employment or computer use you probably signed something agreeing to this. I'm not a fan of this approach, but it certainly happens.
Open source software that implements crypto protocols (e.g., SSL or SSH) will (correctly!) report that there's a MITM attack. So if you want to actually *use* the software in such settings, someone has to configure the software to trust the MITM. Some admins will do this automatically. If not, you may need to do it yourself. E.G., on Firefox, install the organization's certificate.
You configure Linux systems to work in these environments, but since the certs are often files in Windows aka DOS aka CP/M format, you need to convert the files as well as put the into somewhere useful. Here's one way to deal with it.
On Fedora, given a bunch of
dos2unix *.crt ; cat *.crt >>
On Ubuntu, you can do this given a bunch of
dos2unix *.cer ;
rename 's/.cer$/.crt/' *.cer ;
ca=/usr/share/ca-certificates ;
mkdir -p $ca/MYORG ;
cp *.crt $ca/MYORG ;
cd $ca ;
ls MYORG/* >>
You could avoid appending to the file if you want to, but I'll leave that as an exercise for the reader.
This is a good start. If "we the people" pay to develop software, then it makes sense to ensure that "we the people" can use it, improve it, and distribute those improvements by default. See http://freethecode.org/ for others who think that makes sense too.
The URL http://www.dwheeler.com/govern... has a longer list of software released by US governments (federal, state, or local) as open source software. It even identifies a few meta-lists like this one. I'm sure it's incomplete, but it shows that US governments do release open source software. I'd love to hear of other examples of such software (with URLs that prove that the government paid to develop or improve it).
GNU guile's built-in reader includes support for SRFI-105, so you can use infix expressions directly. In particular, you can use {...} instead of (...) and put the operator in the EVEN position, e.g., {n https://www.gnu.org/software/guile/manual/html_node/SRFI_002d105.html
If you want to eliminate more of the parens, you can use guile with SRFI-110, which provides support for indentation-sensitive semantics. An implementation is available with an MIT license. See more here: http://readable.sourceforge.net/
It's not complicated. It's simple. Upgrading a production system is a *big deal*, and in many places there is a long delay between updates. Enterprises will often pay big $$$ to NOT upgrade (other than security patches), because they want rock-solid stability much more than the latest hotness.
E.G., RHEL 5 and CentOS 5 are widely deployed, and will be used for some time to come as production systems. They only support older versions of Python2. Therefore, *useful* programs that need to run on these widely-used systems must be written to run on these older systems.
The IAU has decided that a planet - at least around our Sun - has to "clear the neighbourhood" around its orbit. There will always be objects we can detect, without being able to detect if the neighbourhood is cleared (currently is all so-called exoplanets).
One solution is that "planet" has a different definition between our Solar System and everywhere else. But that is inconsistent. What we should do is have the same definition everywhere; I suggest "orbiting star" and "so massive it's round". If that means Pluto and Ceres are planets, well, that's just fine.
But how, exactly, were going to use those alternative compilers? If you just use an alternative compiler executable, maybe the original executable was okay and the alternative was subverted - so now you have introduced corruption into the compiler executable you cared about. Just using a different compiler in the obvious way simply moves the problem somewhere else, it doesn't actually solve anything. In DDC, you have to subvert both compiler executables, which is significantly harder.
Ken Thompson's trusting trust paper didn't describe how to solve the problem. The only proposed approach is to rewrite everything yourself, which is impractical.
I've noticed several design suggestions in your code.