HN user
Well, there's a lot - a few I happen to be familiar with:
Maxima: https://maxima.sourceforge.io/
Axiom: http://www.axiom-developer.org/
OpenCascade: https://dev.opencascade.org/
BRL-CAD: https://brlcad.org/
GRASS: https://grass.osgeo.org/about/history/
illumos: https://illumos.org/
Docker: https://github.com/docker
Although I personally think matching the OpenBSD libressl license would have been better, I still have to regard the move towards using one of the mainstream, modern standard open source licenses for such a widely used and critical software component a Good Thing. I do, however, also agree with those voicing skepticism about the "silence gives consent" bit - this is important enough to be worth doing without adding a (very) questionable practice like that to the mix. I'd suggest instead setting up some sort of "relicensing coverage" report, and use the yay/nay/no-answer status of various diffs to figure out a price tag for re-writing the bits that can't be relicensed.
I don't suppose the libressl folks could end up creating a 2-clause BSD implementation of the SSL/TLS stack that could divorce itself completely from its openssl origins? (Yes I know that's almost certainly impractical for such a large, complex and thorny code base and problem set, but it's a nice dream... maybe some cryptography researchers/companies/etc. looking to make a name the the industry could target and re-implement specific pieces/algorithms/etc...)
When I was in a hardware store last year, I had a chance to compare a 4k and 5k iMac side by side. IIRC, the size was the same and it came down to PPI.
For casual use 4k was plenty, but where 5k really proved itself for me was small terminal text. I was able to take the font size in terminals down noticeably smaller on the 5k while still having readable text.
That's why the 8k interests me - when doing programming, my particular work-flow usually ends up with lots of open terminals, documents, and web pages as information and source code are woven together into a program. The smaller the readable text, the more I can fit on the screen at once and see at the same time. With 275 PPI and large screen size all in one, this sounds like it might be the dream coding monitor...
The current copyright system is probably inevitable if you view monetization as the sole valid means of creation incentivization. There are also those who want to preserve the "integrity" of their work indefinitely and avoid any risk of what they would consider degrading or inappropriate reuse. If you come at this from either the monetization or the indefinite integrity camps, the public domain is entirely a negative proposition. This is unfortunate, since from a socitial standpoint there are many overall benefits to the public domain (renewal of interest in what would otherwise be lost works and lost effort, lowered barriers to entry for those needing older work on which to base new efforts, etc.) Unfortunately, most of those gains are also net negatives to those working within (and benefiting from) the current system, and consequently the public domain is unlikely to have advocates with the resources to sway the powers that be in its favor. I suppose a sufficiently broad and strong wave of public opinion might do the trick, but I don't know what the prospects of that are (I suspect dim in the short term, more difficult to calculate in the long term if copyright terms keep getting extended indefinitely.)
Wonder if there have been any updates since this:
https://www.reddit.com/r/programming/comments/1a4wvf/kalman_...
I'm quite intrigued by the libfossil project (http://fossil.wanderinghorse.net/repos/libfossil) which attempts to make the core fossil VCS abilities available as a library. To the best of my understanding this is and will remain a "spin-off" project of the main fossil project, but it looks like as of August 2016 there is still active work on it.
The combination of the BSD license and a self-contained C library in the style of sqlite that offers VCS capabilities app developers could build into their applications is extremely enticing. libgit2 (https://libgit2.github.com/) may have matured enough to be viable for that use case if one is comfortable with GPLv2 plus linking exception, but the sqlite-style include one header, build one C file and you're done integration is really really nice.
This is cool, but (as usual with the Smithsonian) they claim copyright and/or commercial usage restrictions on the downloadable data. I wish they wouldn't do that...
Google turns up these:
https://www.google.com/patents/US5628016
https://www.google.com/patents/US6247169
https://patents.google.com/patent/US20070016894A1
I'm not sure about the last one since it's an apparently abandoned application rather than a granted patent...
Interestingly, US6247169 reports "lapsed" on the google page due to non-payment of fees...
I'm really not sure what to make of US5628016 - it's filing date is in 1994, but there's a report of a 2015 "Assignment" legal event.
(edit - fixed links)
From what I can see, if Apache OpenOffice wants to be a viable project with Libreoffice already out there and well ahead from a user perspective, it needs to focus on things that are attractive about it that differentiate it from Libreoffice. Right now, to the best of my admittedly limited knowledge, that's primarily their license. My thought on this is that they need to pick some (fairly radical) directions to take the project in that will provide clear alternatives to LibreOffice. Maybe they could review the ideas here: https://wiki.documentfoundation.org/Development/Crazy_Ideas and pick some of the more ambitious ones that Libreoffice is unlikely to attempt.
I knew it - our brains are written in Lisp!
It lacks a graphical application development framework that's portable and usable. Java eventually solved this problem (more or less) but neither Garnet nor CLIM ever reached a level where most Gtk/Qt/* programmers would seriously consider using them. Web front ends are find for certain things, but for a lot of the application domains where you might consider Lisp you want a proper desktop GUI application. (This would have been especially true in the early years.) The expressiveness and power of Lisp look a lot less attractive when you run headlong into the practical problems of combining that power with a modern GUI.
There are still a few problem domains (like Computer Algebra) where Lisp provides enough benefits to be worth bridging the gap between its world and modern operating system environments, but by and large the inability to be a complete solution I think serves as a disincentive to use Lisp.
Have you ever had to try converting a large pile of pre-existing Tcl/Tk code to L?
Wondering how much work that would be...
What's the license on this project? I'm wondering if it might fit in well with some work Tim Daly has started on the Axiom project hooking up computer algebra to coq et. al.:
https://lists.gnu.org/archive/html/axiom-developer/2015-07/m...
A good point. I didn't specify in my initial comment (and I should have) but one of our other criteria is to be able to build everything with just a C/C++ compiler. So we'd have to bundle/bootstrap Go just to build the editor, which I believe is too heavy to be practical for that (unfortunately).
Close, but it doesn't appear to be active (the version you get from the download link is from 1996?) and it's using the 4 clause BSD license, which (as I understand it) poses GPL compatibility problems.
I note that with the exception of the sam code (which unfortunately uses the Lucent Public License Version 1.02, this editor is very liberally licensed (ISC/MIT/CC0).
If the sam code is optional or easily replaced, this could evolve to become a serious, modern text editor with a truly liberal license (something surprisingly absent from the current landscape, to the best of my knowledge - I've done a couple searches for an editor that could be embedded with an LGPL project, and the choices were pretty limited. This looks quite interesting.
From a portability standpoint, is there any chance of creating a native Windows version using something like http://www.projectpluto.com/win32a.htm ? That was another kicker when I was searching previously - only the really big editors like vim/emacs appear to have Windows ports...
Free open access journals (just two I happen to know of - I'm sure there are more):
That's actually quite interesting - I remember similar comments (Phd required, or Phds aren't able to understand it) cropping up in discussions of the GNU autotools toolchain. (With a fair bit if justification, in my own experience, although I understand the results tended to be better for those who were shell script gurus...)
Everybody hates some aspects of some of them, in my experience. People also tend to have strongly held preferences in the build system department - it's a bit like text editors. I tend to view it as problem-dependent as to which system is better. If you're all java, you probably want a build tool designed for that language (for example.) Lisp has asdf and friends. My focus (cross platform C/C++ building) has led me to deal with autotools and CMake. I prefer CMake for 3 major reasons: 1) self contained - you just install CMake itself and you can handle all sorts of things (tar.bz2 decompression, file copying, directory creation, etc.) automatically and portably. No need to first install Python or Perl or... whatever for Windows. From a Linux/*BSD perspective, developing on Windows is like crossing the Sahara - you need to carry your own supplies. CMake packs a lot into a small, self contained package. 2) Learn one language and you're done. Would it have been better to go with something like lua? Probably, in hindsight (my opinion). However, compared to the mind bending complexity that is sh + m4 + automake + autoconf + ... CMake is (in my experience) quite a lot easier to get a handle on. 3) Wide support for many platforms/tools (Visual Studio, Xcode, ninja, make, Eclipse, etc.) from one common set of build definitions. The maintenance savings really add up if you need to support all those tools - Hunt and Thomas's DRY principle in action.
The other two projects that leap to mind for open source CAD are FreeCAD and BRL-CAD, but I'm not sure either would meet your particular requirements. I'm pretty sure BRL-CAD doesn't offer the sort of parametrics you'd want (the closest thing would probably be writing a procedural generator, which usually means C/C++ or a scripting language). I'm less sure about FreeCAD - they use the OpenCASCADE engine - but if the other commercial systems didn't offer what you want I'd be surprised if FreeCAD had it (not impossible though - it might be worth asking the dev team if your workflow could be realized in FreeCAD.)
Providing the STEP and STL files should cover pretty much what the open source CAD world is prepared to handle - FreeCAD can import STEP and BRL-CAD is working on it, and most 3D printing applications I know of can work with STL just fine. Thank you for taking the trouble to make the extra formats available.
They do have STL files, which I understand are commonly used in 3D printing scenarios. We'll see if they decide to put up STEP and/or IGES files as well - that would be ideal. The Rhino 3dm format might also be a viable option, since openNURBS is available for reading/writing it and is under a very liberal license.