Its unlikely all the training data for Llama is publicly available, let alone under an open source license. If Llama actually had an open source license (IIRC it doesn't), that would still make it a Toxic Candy model under the Debian Deep Learning Team's Machine Learning policy. That means no-one could replicate it exactly, even if they had the boatloads of cash it would take to buy enough hardware and electricity to do the training. Eventually the community could maybe find or create enough data, but that would be a new different model.
The FSF has moved address at least once, and more recently, now closed their offices entirely. I wonder if the new owners of their old addresses will or did get confused by copy-of-GPL requests.
I used to work at the FSF and one of my jobs was replying to these letters. They would be so infrequent by 2008 that I think I handled less than 10 in my time there. I sent way more copies of books to prisoners who requested them, gave more tours of the office, etc. I also did some other stuff when I worked there but if you were to look at the FSF website today you might think I’m still there as pages often have the name of the person who created the page listed as the author still.
The FSF has moved a few times.
* 675 Mass Ave, Cambridge.
* 59 Temple Place, Boston
* 51 Franklin St, Boston
* 31 Milk Street, Boston
The first address wasn’t around for too long, but does still exist. It’s an office building above a bank in Central Square, Cambridge right above the Red Line stop.
The second address was around for a long, long time. A few years ago, the building was demolished and turned into a hotel. I don’t know if 59 Temple Place is still a valid address or not. For this one, I found many of most frequent places and filed bugs to get it updated. Greg K-H helped me update the kernel and many of the issues I opened got resolved with other projects. Worth noting too that the FSF had two different offices in the same building but mail would go to the building. Mail did forward from here to the next address for a while, but I’m not sure if it’ll forward again to the latest address.
51 Franklin St is just around the corner from 59 Temple Place. When they moved here, many staff were able to walk their stuff over to the new office. This one finally closed last year. I worked here my entire time at the FSF.
The final one is a PO Box but also around the corner from 51 Franklin St.
> The FSF Deluxe Distribution contains the binaries and sources to hundreds of different programs including GNU Emacs, the GNU C Compiler, the GNU Debugger, the complete MIT X Window System, and the GNU utilities.
> You may choose one of these machines and operating systems: HP 9000 series 200, 300, 700, or 800 (4.3 BSD or HP-UX); RS/6000 (AIX); Sony NEWS 68k (4.3 BSD or NewsOS 4); Sun 3, 4, or SPARC (SunOS 4 or Solaris). If your machine or system is not listed, or if a specific program has not been ported to that machine, please call the FSF office at the phone number below or send e-mail to gnu@prep.ai.mit.edu.
> The manuals included are one each of the Bison, Calc, Gawk, GNU C Compiler, GNU C Library, GNU Debugger, Flex, GNU Emacs Lisp Reference, Make, Texinfo, and Termcap manuals; six copies of the manual for GNU Emacs; and a packet of reference cards each for GNU Emacs, Calc, the GNU Debugger, Bison, and Flex.
> In addition to the printed and on-line documentation, every Deluxe Distribution includes a CD-ROM (in ISO 9660 format with Rock Ridge extensions) that contains sources of our software.
I wonder how many (if any?) were sold, it'd be an excellent museum piece.
By the time I joined in 2008, I don't think they were being offered anymore as IIRC the person locally who was handling the compiling and tape archiving didn't have access to the systems anymore.
I think keeping the address up to date makes sense. At the same time the FSF should have gotten a PO BOX in 1985.
When I worked at Creative Commons we closed the office down there too and I got a PO BOX in Mountain View where the office was at the time and that seemed to work out okay.
Postman probably just redirects, with a business or institution it's easy to just have the Post Office direct all mail addressed to "Free Software Foundation" to the current address.
For a few months. The post office will do it for anyone for a few months, but then they stop forwarding mail. Maybe businesses get that treatment longer, but when people move they only get a few months.
Standard mail forwarding is one year, and you can extend that for an additional 18 months. I don't know of any reasonable person who would call that "a few months"
I don't disagree, but without some sort of formal or official support from the distribution, I think this is a tall ask. Some vendors have shipped Ubuntu and Fedora on laptops, but not many. If they were going to truly do this, I think it's reasonable for them to expect a minimum level of support from the parent company behind the operating system. Even just for training and bug purposes, people could easily end up getting an OS they aren't comfortable with and complaining at the laptop vendor for it.
That is definitely the wrong approach with the Linux ecosystem, and any other open source ecosystem. Not all distros actually have a single parent company, or any parent company, many are volunteer only but accept donations.
The right approach would be for the laptop vendor to test their laptops with distros requested by their customers, and to contribute new drivers and fixes to the mainline Linux kernel and other upstream projects, and to require their chip suppliers to do the same. The revenue sharing could be via an official partnership, or conference/etc sponsorship arrangements or even just regular donations.
The OS selection would probably have to be hidden behind an "advanced community supported options" area, to reduce the confusion you mention.
Surely the government should be running their own hardware and doing their own software updates. Lots of governments in Europe have had success with using Linux to do this.
We already have all of those things as open source projects, just get them to fund the existing solutions to get them functionally better than Apple/Microsoft.
I don't understand this discussion. What I said was that for our big projects internally, we keep them warning-free, and -Werror obviously helps tremendously with that. Nobody said you need to ship externally with -Werror, or anything about external libraries the project may be using.
By keeping your own project warning-free in your environment, you are doing a service to everyone.
Sounds like you are doing the right thing (-Werror internally, not externally). So this discussion is probably just based on a miscommunication. Happens pretty often on HN unfortunately.
https://salsa.debian.org/deeplearning-team/ml-policy
reply