Viewing profile — arglwarg

> By not hiring a JavaScript developer. aka "the lisp curse": http://www.winestockwebdesign.com/Essays/Lisp_Curse.html

> While possibly a highly unpopular opinion, this is where I think solutions like Electron/Node Webkit fit perfectly. Well ...: https://twitter.com/jacobrossi/status/85199264615127…

This one goes to eleven: 11. "On some setups, clients get a corrupted stack when swapped back in from kernel." ( https://bugs.launchpad.net/ubuntu/+source/linux/+bug/745836 )

Nope (also that would imply there is not functional difference between non-reciprocal licenses like MIT/BSD and a reciprocal one like MPLv2). The original article highlights LibreO…

> That's the first type I think. The second type is the more HN-style professional programmer. nah > As a small P.S. to this, I think the middle ground is using the GPL for actual …

sed is maximum viable perl. Well maybe awk, but that is pushing it.

Even with the "Crazy Ideas" there currently is no reason to assume they would be blocked from being implemented, if only the resources for that were available. So, once the hard pa…

> That's basically quibbling, though the OP did err in his history a bit. AOO existed before that point too, it just wasn't called AOO and it wasn't part of Apache; it was run by O…

... as we would have needed for CMake or Autotools. It might have worked with the former for something as complex as LibreOffice, but GNU make being so simple/basic and stable over…

Even at the time of donation, LibreOffice had already gained a substantial set of the former Sun/Oracle developers: Stephan Bergmann (to Red Hat), Bjoern Michaelsen (to Canonical),…

... and autotools is actively hate-inducing if you have to debug it.

The LibreOffice build system (which is plain GNU Make, without generated unreadable intermediate build files) does all these and more. Doing the same with autotools would be a nigh…