I'm curious why Debian created the DFSG when the FSD already existed. There are some differences (conflicts) of course, but was that the main motivation?
Debian – Why did Debian create the DFSG
debianhistory
Related Solutions
IIRC, Jigdo allows you to break out the files within an ISO and pull the individual files from other servers.
Case in point: Jigdo used to be the preferred way to get Debian ISO files. The Jigdo config file you downloaded would direct the Jigdo client to download all of the files from the regular distribution servers/mirrors, using FTP or HTTP protocols. Then, it would build the ISO client-side. It could start with an existing ISO and "update" it or add stuff which you didn't have time to download and add in, earlier. However, if one of the .deb files (which are compressed) in the ISO changed, you had to download the entire .deb file to rebuild the ISO.
RSync looks at what you have downloaded and what is "current" on the server, downloads the diffs and patches the file(s). Consequently, if you have 650 MB ISO file downloaded, running RSync against it and a server-side version of the ISO file will only download what changed. That allows you to "maintain" a folder or file, relative to another server. That server, however, needs to support the RSync protocol and it will have a pretty high CPU load anytime someone wants to sync with it. Finally, it doesn't work so well for compressed files, because a small change to the uncompressed version can cascade to some VERY significant changes to the compressed version. Consequently, changing a couple files within a .deb file in the ISO will result in downloading the entire new .deb file, not unlike with Jigdo.
ZSync works over HTTP, so no special protocol support is needed. ZSync pushes the CPU load down to the client, instead of the server, so it works better when you have large numbers of users syncing against a centralized server. Finally, small changes to the uncompressed versions of files will result in very small downloads over ZSync, even if the resulting, compressed file has significant changes. If you have an ISO containing thousands of .deb files and you change a few files within one of the .deb files, ZSync would a download just enough information to patch the out-of-date .deb file and re-compress it as needed, then verify the CRC or MD5 signatures, and be done with it. Less bandwidth used, less server-side CPU used, no special protocols needed.
When they can merge all of this with BitTorrent, they've got a winner. When that happens:
- syncing with the server will tell you what changes you need
- peers will provide all of the data, served up in parallel, ensuring maximum speed on the total download
- checksums and hashes from the server will ensure that no peers provide bogus data
That would use even less bandwidth on the server and result in even faster updating. Does anyone know of a protcol/system like that? Last I checked, BitTorrent doesn't allow you to "update" an existing copy of a file.
Apt started its life around 1997 and entered Debian officially around 1999. During its early days, Jason Gunthorpe was its main maintainer/developer. Well, apparently Jason liked cows. I don't know if he still does. :-) Anyway, I think the apt-get moo thing was added by him as a joke. The corresponding aptitude easter eggs (see below) were added later by Daniel Burrows as a homage, I think.
If there is more to the story, Jason is probably the person to ask. He has (likely in response to this question) written a post on Google+. A small bit of it:
Once a long time ago a developer was known for announcing his presence on IRC with a simple, to the point 'Moo'. As with cows in pasture others would often Moo back in greeting. This led to a certain range of cow based jokes.
Also:
$ aptitude moo
There are no Easter Eggs in this program.
$ aptitude -v moo
There really are no Easter Eggs in this program.
$ aptitude -vv moo
Didn't I already tell you that there are no Easter Eggs in this program?
$ aptitude -vvv moo
Stop it!
$ aptitude -vvvv moo
Okay, okay, if I give you an Easter Egg, will you go away?
$ aptitude -vvvvv moo
All right, you win.
/----\
-------/ \
/ \
/ |
-----------------/ --------\
----------------------------------------------
$ aptitude -vvvvvv moo
What is it? It's an elephant being eaten by a snake, of course.
Best Answer
The early definition of free software (set forth in the GNU’s Bullentin Volume 1, Number 1 in 1986) was unknown to the authors of the Debian Free Software Guidelines in 1997. This early definition was much weaker than the DFSG and it seems that The Free Software Definition had not yet been published as such.
Here is an excerpt from a comment by Bruce Perens (the primary author of DFSG) (found as a reference in Wikipedia’s Debian Free Software Guidelines article):
In fact, the 1986 GNU’s Bulletin definition was not the modern “Four Freedoms”, but a simplified version that focuses on the abilities to redistribute and change programs (but not specifically the ability to redistribute changed programs!). This early definition is close to the “modern” freedoms two and one.
The DFSG were first published in the July 1997 announcement of the Debian “Social Contract”. It explicitly mentions the ability to redistribute modified source code (or at least “original plus patches”). This was not explicit in the early GNU’s Bulletin definition, though it is related to “modern” freedom three.
archive.org’s http://www.gnu.org/philosophy/free-sw.html