The problem is, in part, Lisp's syntax. Most people don't want to read code written in lisp, because (+ (* 3 4) 5) is a big pain.
You might look into http://readable.sourceforge.net/ - it extends Lisp s-expressions with additional abbreviations, making it much easier to read.
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.
Oh, and a Bruce Schneier connection: In 2006 Bruce wrote a summary of my ACSAC paper on diverse double-compiling (DDC). Bruce's article is simply titled Countering "Trusting Trust".
Bruce completely understood the approach. He explained it very well in his blog, and he also did a nice job explaining its larger ramifications. His conclusions are still true: the "trusting trust" attack has actually gotten easier over time, because compilers have gotten increasingly complex, giving attackers more places to hide their attacks. Here's how you can use a simpler compiler -- that you can trust more -- to act as a watchdog on the more sophisticated and more complex compiler.
I've gotten a lot of hits, and that's a good thing. As I noted in another post, I got hit by reddit earlier this year. In general people are becoming more interested in protecting and verifying build environments, as this post about Tor demonstrates.
You have to trust some things. But you can work to independently verify those things, to determine if they're trustworthy. I don't always agree with Bruce Schneier, but after watching what's he's done for years, I've determined that he's quite trustworthy. This is the same way we decide if we should trust anyone or any thing. In short: "trust, but verify".
Make scales just fine. Badly using make, through mistakes like using recursive make, causes scalability problems.
The paper "Recursive make considered harmful" by Peter Miller identifies common mistakes in using make, and how to fix them. The biggest mistake is using recursive make; this is a common mistake that is NOT required by make. Once you stop making this mistake, make is suddenly much faster.
Two other issues with standard make were not part of POSIX, but they are now:
Issue 1: Historically, standard make only implements deferred assignment (where values are calculated when referenced, not when set).
This meant that as size grows, there was an exponentially increasing calculation effort (eek). Miller recommends using immediate assignment op, but although GNU make has one (as:=) that wasn't in the POSIX standard. He also suggests using an appending assignment (+=_, which wasn't in POSIX either.
Since then, POSIX has added the immediate-assignment operator::= and the appendix-assignment += (see http://austingroupbugs.net/view.php?id=330). GNU make 4.0 implements "::=", so you can now start using it. This gets rid of a major scalability problem.
Issue 2: The "obvious" ways to implement automatic dependency generation in make require the ability to "include" multiple from one line, and the ability to silently ignore errors when including, and those weren't in POSIX either. These have since been added to POSIX (in http://austingroupbugs.net/view.php?id=333 and http://austingroupbugs.net/view.php?id=518).
Just getting something into the POSIX spec doesn't cause anything magical to happen. But if a capability is in a standard, it's way more likely to be implemented, and people are far more willing to depend on it.
Previous poster: "Being simpler for a computer means it is simpler to write evaluators for LISP expressions. Because of the simplicity of LISP an evaluator + applicator gives you a compiler or runtime environment. That is a huge huge advantage."
Yes, but that doesn't require using the old s-expression notation from the 1950s.
Check out http://readable.sourceforge.net./ This adds additional abbreviations to s-expressions, just like 'x currently means (quote x), so that people can produce much more readable code and data. It's implemented in Scheme and Common Lisp, and is released as open source software using the MIT license.
There are a lot of build systems that provide more built-in features than straight-up make. Heck, GNU make itself has LOTS more features than POSIX make.
But many of those more-automated build systems run on top of... make. In particular, if you use cmake or automake/autotools, they *generate* makefiles, so you still need a capable "make" program. In fact, you *want* a "make" underneath with lots of capabilities, so the tool you use directly can generate better results.
Ant and Maven are nice tools... but usually they're only used with Java. Rake is great, but is typically only used with Ruby. I like Python (the language), but there are several articles showing that at least at the time Scons was *slow* (and thus had trouble scaling). Autoconf's syntax is still baroque, but if you follow certain conventions it's actually not too bad, and it's much easier to use now that a number of annoying bugs have been fixed.
For general-purpose build systems, the autotools or cmake are still reasonable build systems to look at (unless you're using Java or Ruby). And since they generate makefiles, it's important to have a great tool underneath to process the makefile, even if you don't use make directly.
Interactive Fiction is very alive
on
Boot To Zork
·
· Score: 4, Informative
These games are now typically called "Interactive Fiction"; there are LOTS of them, and they are still being developed. It's a small community, but active.
Two good post-Infocom games are Bronze (by Emily Short) and Anchorhead (by Michael Gentry).
Coverity sells software that does static analysis on source code and looks for patterns that suggest defects. E.G., a code sequence that allocates memory, followed later by something that de-allocates that memory, followed later by something that de-allocates the same memory again (a double-free).
The product is not open source software, but a number of open source software projects use it to scan their software to find defects: https://scan.coverity.com/
It's a win-win, in the sense that Coverity gets reports from real users using it on real code, as well as press for their product. The open source software projects get reports on potential defects before users have to suffer with them.
"Unix" - as they define it - is going away.
But what's really happening is that old implementations of Unix are being replaced by modern implementations and re-implementations of Unix.
Servers are increasingly using Red Hat Enterprise Linux, Fedora, Debian, Ubuntu, etc.
On the client side, the #1 smartphone (by popularity) is Android, based on Linux. The #2 smartphone is iOS, based on Unix.
On the desktop, Macs are running MacOS, also based on Unix.
I usually visit "The H" daily (along with sites like lwn.net, Slashdot, and Groklaw), because they had lots of interesting stuff.
Sounds like a lot of people who would have liked them didn't know about them. I don't know if that would have helped with monetization, but it might have.
However, the last point is: "The addition of DirectWrite causes Steam to be unable to display text. This can be fixed either by setting dwrite.dll to disabled for steam.exe using Winecfg, or by running Steam with the -no-dwrite option."
Why the heck does that happen? Will this be fixed soon?
Yes, I know you could (normally) just run the Steam for Linux if you're running Linux, but I would guess that problem would hit other apps too.
This is really good news. Github has started to get seriously polluted with unlicensed software. Since copyright by default gives everyone else NO rights, this should help clean up things. I'm sure there are ways to improve their license info, but making it more obvious that people need to pick licenses is a good first step.
A hack is not a fix, true. The fix (from this viewpoint) is to change all copyright laws, worldwide, so that the default is no copyright. That will not happen in less than 20 years, and I bet it'll take even longer. If it even happens.
Would your users rather you "hack in" a solution now, by adding a license file? Or would your users rather wait 20+ years, with no guarantee it'll ever get fixed, and risk getting sued?
I don't even think it's a hack. All you're doing is making it clear to everyone what they can do. That's making things clearer, not a hack.
The copyright law doesn't have a "use" right per se, but under many US districts making a copy from storage to RAM is considered a copy, and thus running software is forbidden unless specifically permitted by the copyright holder. You can thank the horrifically bad ruling "MAI Systems Corp. v. Peak Computer, Inc., 991 F.2d 511 (9th Cir. 1993)" for this travesty. See my post above for more.
Distribution is only part of the story. IANAL, but let's focus on US law, starting with the software-relevant portions of 17 USC 106:
"The owner of copyright under this title has the exclusive rights to do and to authorize any of the following:
(1) to reproduce the copyrighted work in copies or phonorecords;
(2) to prepare derivative works based upon the copyrighted work;
(3) to distribute copies or phonorecords of the copyrighted work to the public by sale or other transfer of ownership, or by rental, lease, or lending;"
A common interpretation is that copies from storage to RAM are copies, and thus, you have to get a copyright holder's permission to run the software. I HATE this interpretation, I think it's a vile distortion of the original intent. However, it was upheld in "MAI Systems Corp. v. Peak Computer, Inc., 991 F.2d 511 (9th Cir. 1993)". For more about this controversial but widespread interpretation, see A new perspective on temporary copies: The Fourth Circuit's Opinion in Costar v. Loopnet (Band and Marcinko). After the MAI decision, Congress then added 17 USC 117: "it is not an infringement for the owner of a copy of a computer program to make or authorize the making of another copy or adaptation of that computer program provided: (1) that such a new copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine and that it is used in no other manner,..." Basically, Congress said that even if copying to RAM would be considered a copyright violation (which it pointedly did not rescind), there's a special exception that it's okay to do if you're the owner of a copy of a computer program.
But wait! That means you have to be the "owner of a copy of a computer program" to use the program (or get the owner's permission). Did github say you were the owner of a copy? No, it said that you could "view" and "fork". "View" sure isn't "owner of a copy", and it's dubious that "fork" means that either. Note that the github TOS doesn't define "fork", so it has no clear legal definition. Yes, technically there's no "use" right in copyright law, but under at least some common US law interpretations you can't use the software in US if the code is just posted on github. Many software EULAs claim you aren't the owner, and then grant you permission to run the program through contracts, but if there's no license you can't claim that a license gave you such permission.
If you don't clearly give a right in a copyrighted work you create, then some judge gets to decide what rights (if any) are granted to users. You will probably not like what the judge says, especially since most judges don't understand software at all (there are glorious exceptions, but they're exceptional). Maybe "fork" gives users enough rights... but I wouldn't count on it. And since legal cases cost a lot of money, wise users will avoid software without licenses; they're not worth the legal risk. I hope that the "RAM copy as copy" interpretation is completely overturned someday, but that has not yet happened, and I wouldn't count on it happening soon.
Lots of people have worked out software licenses for sharing software. Just pick a common open source software license (MIT, BSD 3-clause, Apache 2.0, LGPL 2.1 or 3, GPL 2+ or 3+).
We can thank the RIAA and MPAA for the contempt many people have for copyright law. And I agree that copyright law needs a serious overhaul.
But releasing code without a copyright license isn't "sticking it to the man", it's polluting the world with software that is not legal for users to use. Even if YOU won't sue, no one can be sure of that. If you die (see: Seth Vidal), whoever controls your estate can sue your users.
Releasing software without a license is just another way of setting up an extortion scam. It may be unintentional, but that's still the effect. We already have patent trolls, porn trolls, and so. Really, we have enough extortion scams, thank you.
Lisps, like Scheme and Harlan, can be made readable.
Look at the Readable Lisp S-expressions Project, which extends traditional Lisp notation and adds capabilities such as infix and traditional f(x) style formatting. We provide open source software (MIT license) implementations, including one that can be used as a preprocessor. So, you can have your Harlan and stuff like infix too.
Without these syntax improvements you're right. Very few developers will be happy writing complicated math expressions without infix. And a lot of code that uses GPUs will have significant math expressions.
Slashdot Mirror
The problem is, in part, Lisp's syntax. Most people don't want to read code written in lisp, because (+ (* 3 4) 5) is a big pain. You might look into http://readable.sourceforge.net/ - it extends Lisp s-expressions with additional abbreviations, making it much easier to read.
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.
Oh, and a Bruce Schneier connection: In 2006 Bruce wrote a summary of my ACSAC paper on diverse double-compiling (DDC). Bruce's article is simply titled Countering "Trusting Trust".
Bruce completely understood the approach. He explained it very well in his blog, and he also did a nice job explaining its larger ramifications. His conclusions are still true: the "trusting trust" attack has actually gotten easier over time, because compilers have gotten increasingly complex, giving attackers more places to hide their attacks. Here's how you can use a simpler compiler -- that you can trust more -- to act as a watchdog on the more sophisticated and more complex compiler.
I've gotten a lot of hits, and that's a good thing. As I noted in another post, I got hit by reddit earlier this year. In general people are becoming more interested in protecting and verifying build environments, as this post about Tor demonstrates.
So please take a look at my Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) page!
Thanks for pointing out my Diverse Double-Compiling (DDC) paper!
My page on Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) has more details, including detailed material so you can duplicate the experiments and re-verify the proofs. Note that you do not have to take my word for it.
You have to trust some things. But you can work to independently verify those things, to determine if they're trustworthy. I don't always agree with Bruce Schneier, but after watching what's he's done for years, I've determined that he's quite trustworthy. This is the same way we decide if we should trust anyone or any thing. In short: "trust, but verify".
Make scales just fine. Badly using make, through mistakes like using recursive make, causes scalability problems.
The paper "Recursive make considered harmful" by Peter Miller identifies common mistakes in using make, and how to fix them. The biggest mistake is using recursive make; this is a common mistake that is NOT required by make. Once you stop making this mistake, make is suddenly much faster.
Two other issues with standard make were not part of POSIX, but they are now:
Issue 1: Historically, standard make only implements deferred assignment (where values are calculated when referenced, not when set). This meant that as size grows, there was an exponentially increasing calculation effort (eek). Miller recommends using immediate assignment op, but although GNU make has one (as :=) that wasn't in the POSIX standard. He also suggests using an appending assignment (+=_, which wasn't in POSIX either.
Since then, POSIX has added the immediate-assignment operator ::= and the appendix-assignment += (see http://austingroupbugs.net/view.php?id=330). GNU make 4.0 implements "::=", so you can now start using it. This gets rid of a major scalability problem.
Issue 2: The "obvious" ways to implement automatic dependency generation in make require the ability to "include" multiple from one line, and the ability to silently ignore errors when including, and those weren't in POSIX either. These have since been added to POSIX (in http://austingroupbugs.net/view.php?id=333 and http://austingroupbugs.net/view.php?id=518).
Just getting something into the POSIX spec doesn't cause anything magical to happen. But if a capability is in a standard, it's way more likely to be implemented, and people are far more willing to depend on it.
Previous poster: "Being simpler for a computer means it is simpler to write evaluators for LISP expressions. Because of the simplicity of LISP an evaluator + applicator gives you a compiler or runtime environment. That is a huge huge advantage."
Yes, but that doesn't require using the old s-expression notation from the 1950s.
Check out http://readable.sourceforge.net./ This adds additional abbreviations to s-expressions, just like 'x currently means (quote x), so that people can produce much more readable code and data. It's implemented in Scheme and Common Lisp, and is released as open source software using the MIT license.
There are a lot of build systems that provide more built-in features than straight-up make. Heck, GNU make itself has LOTS more features than POSIX make.
But many of those more-automated build systems run on top of... make. In particular, if you use cmake or automake/autotools, they *generate* makefiles, so you still need a capable "make" program. In fact, you *want* a "make" underneath with lots of capabilities, so the tool you use directly can generate better results.
Ant and Maven are nice tools... but usually they're only used with Java. Rake is great, but is typically only used with Ruby. I like Python (the language), but there are several articles showing that at least at the time Scons was *slow* (and thus had trouble scaling). Autoconf's syntax is still baroque, but if you follow certain conventions it's actually not too bad, and it's much easier to use now that a number of annoying bugs have been fixed.
For general-purpose build systems, the autotools or cmake are still reasonable build systems to look at (unless you're using Java or Ruby). And since they generate makefiles, it's important to have a great tool underneath to process the makefile, even if you don't use make directly.
These games are now typically called "Interactive Fiction"; there are LOTS of them, and they are still being developed. It's a small community, but active. Two good post-Infocom games are Bronze (by Emily Short) and Anchorhead (by Michael Gentry).
More info: http://en.wikipedia.org/wiki/Interactive_fiction
A gentle intro: http://emshort.wordpress.com/how-to-play/
Coverity sells software that does static analysis on source code and looks for patterns that suggest defects. E.G., a code sequence that allocates memory, followed later by something that de-allocates that memory, followed later by something that de-allocates the same memory again (a double-free).
The product is not open source software, but a number of open source software projects use it to scan their software to find defects: https://scan.coverity.com/ It's a win-win, in the sense that Coverity gets reports from real users using it on real code, as well as press for their product. The open source software projects get reports on potential defects before users have to suffer with them.
Just get your Adaptation Demotivator from Despair, Inc. (I don't work for them, but I love their posters.)
"Unix" - as they define it - is going away. But what's really happening is that old implementations of Unix are being replaced by modern implementations and re-implementations of Unix.
Servers are increasingly using Red Hat Enterprise Linux, Fedora, Debian, Ubuntu, etc. On the client side, the #1 smartphone (by popularity) is Android, based on Linux. The #2 smartphone is iOS, based on Unix. On the desktop, Macs are running MacOS, also based on Unix.
Ah, that makes sense. Thanks for the answer.
I'm really sad to see them go.
I usually visit "The H" daily (along with sites like lwn.net, Slashdot, and Groklaw), because they had lots of interesting stuff.
Sounds like a lot of people who would have liked them didn't know about them. I don't know if that would have helped with monetization, but it might have.
Overall looks really promising!
However, the last point is: "The addition of DirectWrite causes Steam to be unable to display text. This can be fixed either by setting dwrite.dll to disabled for steam.exe using Winecfg, or by running Steam with the -no-dwrite option."
Why the heck does that happen? Will this be fixed soon?
Yes, I know you could (normally) just run the Steam for Linux if you're running Linux, but I would guess that problem would hit other apps too.
This is really good news. Github has started to get seriously polluted with unlicensed software. Since copyright by default gives everyone else NO rights, this should help clean up things. I'm sure there are ways to improve their license info, but making it more obvious that people need to pick licenses is a good first step.
A hack is not a fix, true. The fix (from this viewpoint) is to change all copyright laws, worldwide, so that the default is no copyright. That will not happen in less than 20 years, and I bet it'll take even longer. If it even happens.
Would your users rather you "hack in" a solution now, by adding a license file? Or would your users rather wait 20+ years, with no guarantee it'll ever get fixed, and risk getting sued?
I don't even think it's a hack. All you're doing is making it clear to everyone what they can do. That's making things clearer, not a hack.
US law, as interpreted by many courts.
The copyright law doesn't have a "use" right per se, but under many US districts making a copy from storage to RAM is considered a copy, and thus running software is forbidden unless specifically permitted by the copyright holder. You can thank the horrifically bad ruling "MAI Systems Corp. v. Peak Computer, Inc., 991 F.2d 511 (9th Cir. 1993)" for this travesty. See my post above for more.
Distribution is only part of the story. IANAL, but let's focus on US law, starting with the software-relevant portions of 17 USC 106:
A common interpretation is that copies from storage to RAM are copies, and thus, you have to get a copyright holder's permission to run the software. I HATE this interpretation, I think it's a vile distortion of the original intent. However, it was upheld in "MAI Systems Corp. v. Peak Computer, Inc., 991 F.2d 511 (9th Cir. 1993)". For more about this controversial but widespread interpretation, see A new perspective on temporary copies: The Fourth Circuit's Opinion in Costar v. Loopnet (Band and Marcinko). After the MAI decision, Congress then added 17 USC 117: "it is not an infringement for the owner of a copy of a computer program to make or authorize the making of another copy or adaptation of that computer program provided: (1) that such a new copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine and that it is used in no other manner, ..." Basically, Congress said that even if copying to RAM would be considered a copyright violation (which it pointedly did not rescind), there's a special exception that it's okay to do if you're the owner of a copy of a computer program.
But wait! That means you have to be the "owner of a copy of a computer program" to use the program (or get the owner's permission). Did github say you were the owner of a copy? No, it said that you could "view" and "fork". "View" sure isn't "owner of a copy", and it's dubious that "fork" means that either. Note that the github TOS doesn't define "fork", so it has no clear legal definition. Yes, technically there's no "use" right in copyright law, but under at least some common US law interpretations you can't use the software in US if the code is just posted on github. Many software EULAs claim you aren't the owner, and then grant you permission to run the program through contracts, but if there's no license you can't claim that a license gave you such permission.
If you don't clearly give a right in a copyrighted work you create, then some judge gets to decide what rights (if any) are granted to users. You will probably not like what the judge says, especially since most judges don't understand software at all (there are glorious exceptions, but they're exceptional). Maybe "fork" gives users enough rights... but I wouldn't count on it. And since legal cases cost a lot of money, wise users will avoid software without licenses; they're not worth the legal risk. I hope that the "RAM copy as copy" interpretation is completely overturned someday, but that has not yet happened, and I wouldn't count on it happening soon.
Lots of people have worked out software licenses for sharing software. Just pick a common open source software license (MIT, BSD 3-clause, Apache 2.0, LGPL 2.1 or 3, GPL 2+ or 3+).
We can thank the RIAA and MPAA for the contempt many people have for copyright law. And I agree that copyright law needs a serious overhaul.
But releasing code without a copyright license isn't "sticking it to the man", it's polluting the world with software that is not legal for users to use. Even if YOU won't sue, no one can be sure of that. If you die (see: Seth Vidal), whoever controls your estate can sue your users.
Releasing software without a license is just another way of setting up an extortion scam. It may be unintentional, but that's still the effect. We already have patent trolls, porn trolls, and so. Really, we have enough extortion scams, thank you.
Nope, github by default lets you "view" and "fork" the code. No "use" rights were granted.
Lisps, like Scheme and Harlan, can be made readable.
Look at the Readable Lisp S-expressions Project, which extends traditional Lisp notation and adds capabilities such as infix and traditional f(x) style formatting. We provide open source software (MIT license) implementations, including one that can be used as a preprocessor. So, you can have your Harlan and stuff like infix too.
Without these syntax improvements you're right. Very few developers will be happy writing complicated math expressions without infix. And a lot of code that uses GPUs will have significant math expressions.
I want to see the Pitcairn Islands. It's notorious hard to get to, and it ensures that the sun never sets on the British empire.
Be sure to the subject line on posters...!