Do you mean the issue of Mozillas restrictions on the "Firefox" name, which the FSF/GNU think are at odds with their notion of "Free Software"? Do you mean you are annoyed with the FSF for their entire purpose in this world?
He's recently been asking me for advice about packaging node.js desktop apps, which I've been discussing with him. Does anyone else have any advice or opinions or corrections to add, please?
RMS> The questions I'm concerned with are very limited: they have to do with how node applications fit into the existing and general framework of GNU/Linux. If I can install them with apt-get, start them with a shell command or from a menu, and use them to operate on ordinary files in my file system with no Internet connection, then they're just as good as C or Python or Lisp programs. So I don't need to know any more -- I can conclude "there's no problem here, everything's ok," and move on to other issues.
RMS> Can you confirm for me whether this is possible?
RMS> If not, then they have a problem and I'd like to know more about the problem.
Don> Yes, I think node will suit your needs quite nicely.
Don> So yes I think you can conclude that there is no problem and it's ok to use it!
Don> Node has its own package manager called "npm" that might be more appropriate to use than apt-get, since it knows a lot more about what is going on with node, and solve the problem of dependencies in a much nicer way than apt-get can.
Don> For example, you can install packages in the system globally to share with other users, or locally in a project to isolate projects from each other and make them independent.
Don> I believe you could still package node software up so it can be installed by apt-get of course, but it would be more monolithic and system wide, and not be able to take advantage of all the things you npm can do because it knows it is dealing with node, instead of trying to solve a much more general problem of linux software installation.
Don> Also, it is a much fresher simpler approach to some of the problems that gnu configure solves, since it abstracts a lot of the system dependencies, so there is no need for the artificial intelligence layer that is implemented by shell scrips, and all the guessing and probing and syntactic backflips to maintain compatibility with old versions of Xenix for ZX80 and AT&T answering machine cassette tape drivers and stuff like that.
Don> So I think using the node/npm ecosystem instead of the older stuff would make installation and configuration about four to five orders of magnitude simpler and more elegant.
Don> Definitely there is no problem using it for what you want the same way as python or whatever scripting language.
Don> Not only is node.js useful for implementing servers of all persuasions, but you can also use it to develop local desktop applications with or without user interfaces,
RMS> Can you tell me more about this possibility? Perhaps tell me the specific URLs I can fetch to read about it? I don't browse sites unrelated to me from my own computer, but I can fetch a specific article by sending mail to a demon.
Don> Here is one alternative that uses built-in WebKit to do the user interface: https://github.com/rogerwang/node-webkit
Don> Here is another alternative, that uses QT instead of WebKit, which is what you should use if for some perverse reason you want to severely limit the scope of people who know how to or are willing to program the user interface, and also severely narrow the scope of what you can do with the user interface and which libraries and frameworks you can use: https://github.com/arturadib/node-qt
Don> And somewhere in-between, but hardly as effective as simply using a real web browser like WebKit to do real web things, and certainly not stable or mature: https://github.com/arturadib/node-five
Don> And of course if you're happy using a separate stand-alone browser as the user interface (and don't need the high bandwidth direct access in-memory single-threaded bi-directional function calling interface between node and the user interface), you can simply run any old web server module in node (there are lots to choose from), and run node in the background on your desktop computer, and talk to it via https and localhost sockets.
Don> Node has full access to your local computer, including accessing local files, calling native code, etc.
Don> I presume that WebKit can run sandboxed JavaScript code, but I don't know how WebKit's JS interpreter relates to node's JS interpreter, if they're different or one and the same, or how they're isolated from each other (or how it's isolated from itself ;).
Don> I'm not familiar with what work has been done on sandboxing JavaScript directly in node.js, but you might start looking here: https://www.npmjs.org/package/sandbox
Don> Once you've installed node and npm, you can get it and look at the source by going "npm install sandbox".
Don> This one looks like it sandboxes JavaScript code in a sub-process, which is probably even safer but terribly non-optimal if you've already got two other JavaScript interpreters hanging around in the same process after linking node and WebKit together. https://www.npmjs.org/package/node-sandbox
RMS> One specific question: can these applications read and write files in the local file system? If so, is it normal for them to do so?
Don> Good question. Yes you can store a certain amount of stuff in the web browser's "local storage", and certainly a remote server or local server. But the JavaScript code would have to be running in some kind of privileged shell or context, such as a Firefox or Chrome extension in a normal web browser, or the desktop equivalent of "PhoneGap" that wraps a web browser in a mobile app and exposes apis to privileged functions like file system access. Or of course the aforementioned node.js + webkit application.
Don> There is a great tool for node/npm called "Browserify", kind of like a linker for JavaScript source code modules, which itself is a nicely factored flexible set of node modules, that lets you take a bunch of node modules and package them together to run in the web browser, substituting shims that implement nice asynchronous node apis by wrapping nasty browser based apis, so you can write portable code that runs in the browser or server without any modification!
RMS> If you "browserify" an application in this way, where and how does it store data? Does it store data in files in the local system? Or does it have to store them somewhere else, such as Local Storage Objects or a remote server?
Don> That enables you to achieve the holy grail of re-using the same code and data without modification, on both the client and the server and embedded devices and whatever!
RMS> My holy grail is that we could install these Javascript packages through the GNU/Linux distro's package system, run them in the same ways we run C programs, and have them operate on local files just like C programs.
Don> I don't see why not! If you don't need a sandbox, then it should be a piece of cake that you can both have and eat too, which is not a lie. http://knowyourmeme.com/memes/the-cake-is-a-lie
RMS> But there's one other thing that would be very useful to help this case:
RMS> * There is a server that sends nonfree JS code to the user's machine and won't run without it.
RMS> * We ask them to fix this.
RMS> * If node.js makes it easy for them to fix it by running their _existing_ JS code on the server side, that would be a big help.
Don> I don't quite understand what you mean or what your motivations are (aside from your usual well known motivations), but it sounds possible.
Don> It's probably somewhere between "it's only an awk script away" (which means it's possible, but at the cost of losing your soul), and "a simple matter of programming" (which mean trivially technically possible except for all the difficult non-technical parts like asking nicely and getting along with people who hold different beliefs, goals, and priorities, and getting users to press the "any" key, stop trying to photocopy CD-ROMS, etc). ;)
Don> So if you're using aptitude to snapshot the binary platform specific results of doing an npm install and compiling native code modules, then users installing the software with apt-get won't need to have npm compile the code, or even need to have compilers installed.
RMS> That is a fine way of doing it. Or, alternatively, running apt-get on that package could do the npm install. How it works is NOT THE ISSUE. The point is to offer users a single uniform UI for installing all the packages in the system.
RMS> When a programming platform comes with its own "convenient" way of installing packages, it is convenient for hackers who develop things in that language, but it's nothing but trouble for users that want to install a package and not have to know what language it is written in.
RMS> And that includes people like me, who know how to program, but don't program in that particular language.
RMS> Thus, I think one thing that every programming platform ought to have is a convenient way to generate a .deb.
