I have questions myself. What is the best way to form a VPN?
MS makes their own PPTP VPN fairly easy to work with. But it isn't well-supported on other platforms (things like poptop work OK) & the encryption they use has known weaknesses (though, I don't think there are any exploits out there). I would never use it.
IPSec is probably the "standard." Most hardware implementations use this. There are client/servers on all platforms & encryption doesn't have the same weaknesses. Depending on the implementation, this can be either tedious or non-free to setup.
I like OpenVPN, which uses SSL, is VERY portable, and very easy to use. Plays well with both NAT and dynamic addresses. The only reason to use IPSec, in my opinion, is if there are hardware devices in the way. But OpenVPN is beginning to be found on some devices too.
SSH, VPN, VNC, Remote Desktop, and FreeNX oh my!
on
Easy Remote Access?
·
· Score: 1
First, my universal advice: DON'T get in the habit of fixing remote systems for free. It is a huge time-sink & it would be better if you don't foster that dependence. I sometimes fix problems over email or in person for friends/family, but I also usually weasel some free beer out of the deal.
That being said, many have to remotely administer machines for OTHER reasons. Oftentimes, a shell is all that is needed & having OpenSSH is good enough. It is available for win32 too. This can also be used for port forwarding if other daemons are needed.
If you don't need SSH/SFTP & do need a secure connection, setup a VPN. OpenVPN is great:cross-platform, secure, and easy to install. IPSec is still the standard, but I don't bother with it unless I have to (like when my company would buy a hardware implementation). I try to avoid PPTP. It works OK on windows. Not so well on other platforms (poptop does a pretty fair job, though). It also believe it has some known (but, I again believe, still unexploited) security weaknesses.
You hooked on the GUI? I use VNC over VPN or stunnel. I don't really like remote desktop, but if you have to support it put RDesktop on your *nix box. FreeNX is, in many ways, better than both. I like it a lot, but I haven't used it under windows (it can be done & someone might have made it quick-and-easy, but I try to avoid supporting windows machines).
My system would fail without any complaints (and not remake until the next file change), so sometimes I didn't get around it. I also normally used the system when most dependent files were already written & I was just refining them.
However, I also used simple auto-dependency generation for projects where I was also making new files. I suspect this is the particular detail you were interested in & would advise you to check outa few tutorials on GNU make if you want to implement a similar system.
I might be able to dig out my old scripts, but the only thing I currently do that is even close is to automatically recompile my LaTeX files, which is usually much simpler.
Background/predictive compilation isn't too novel or unique either. I used to hack it with scripts and makefiles--they'd basically watch for file writes. I didn't actually use it to catch bugs, as you apparently can in eclipse & xcode now--I just did it so I wouldn't have to wait at the shell when I needed to test. I now use python & can get feedback quickly enough if I use some sort of interactive mode (I am partial to ipython).
From their FAQ, it sounds like eclipse does exactly what my old scripts and makefiles did--compile on file saves. They also call it "incremental." Any eclipse fans out there want to clear this up?
An officemate tells me that Visual Studio also has some sort of background compilation.
The first thing you'll notice is the incremental compilation. Sounds an awful lot like Xcode. Wonder who had it first? I think the first version of Xcode with predictive compilation was released in the summer of 2003.
Incremental compilation dates back to the early 60s with LISP.
Keep in mind that the legislation is for PUBLIC purchases, not what you can get. The government often prevents PUBLIC funds from buying things like alcoholic beverages. Even if something is legal, it might not be the best way to spend tax dollars.
I think the government should mandate that output from any software be an open standard format (XML or whatever) and then they choose, based on a competative bid process like they are supposed to do, the software that will do what they want (which may include adding features at some point). If some OSS group wins, so be it. If some proprietary group wins, so be it.
Making the software open source and/or otherwise MORE available to taxpayers seems like a very valid criteria to put in a for-bid contract.
1. It is straight against capitalist economy to require one business/development model. In capitalism, you specify the product and whoever can do it best/cheapest/easiest wins. Only an OSS zealot would think that OSS would always win.
But if it is unwritten comissioned software, the promise of source code and an open would make it better. If it is for software that has already been made, it may be very difficult to say that F/OSS won't be cheaper in the long run (at the very least, it offers GREATER competition for both maintenance and support contracts).
I didn't even realize that Enigmail allows you to create keys (I actually created mine on the CLI) & the only complaint that is left is the quote-unquote difficulty of installing GPG under windows (it isn't hard--there are installers, such as the one for WinPT).
I have used both. If you only want worj with e-mail use Thurderbird and Enigmail on Windows. You won't be sorry. WinPT is bothersome with e-mail
The OP complained about the difficulty of installing GPG & generating a key to use with Enigmail. WinPT is a solution. I was not advocating using it instead of Enigmail.
If the format is open, then an open sourced solution could be developed to deal with any issues with the proprietary software.
And, rather than throwing good money after bad to upgrade and maintain closed source software, public agencies should fund efforts to bring free open source software to the public. Perhaps they should keep proprietary software that has already been paid for, but as a taxpayer I want the most bang for my buck. This would be a strong argument against any commercial product that could charge a lot of money to MA & then to IL & so on, when a Free (in both senses of the word) program could be used instead.
If the file formats used are truly open (as in a decent standard that's well documented and actually works as it's described, which allows other applications to read and write in the same format without legal encumbrance), then the customer can take their data and have a new application or data converter written, allowing them to easily migrate to a new platform.
So why not do it now? The argument against doing it later will be "we've already invested so much money and time in closed product X from company Y, that it would cost an unreasonable amount to build F/OSS program Z from scratch."
These are limited by the fact that the customer can now walk away. Something they cannot easily do if they were locked into Word's *.doc format or such. If the proprietary vendor tried strong-arm tactics or charged too much, the customer could simply write, or have written, a replacement application (or a file converter to convert the data files to a format used by another application).
This is short-sighted. First of all, the vendors can charge much more than an upgrade is worth--they just have to keep it cheaper than a replacement. Furthermore, the "annual upgrade tax" to the company will add up quicker than F/OSS over the lifetime the files need to be read.
Well, only with regards to the application itself. The data, properly documented and open, could easily be handled by any competent programmer.
And how often do you suppose problems are with the file format? Support is almost always inherently for the particular product.
What architecture lock in? Vendor screwing you over? Take your data and walk away. Have someone else write a replacement. Write it yourself! Use Y or Z's product! Suddenly Corp X decides that the 3.2 update will NOT cost a trillion dollars, afterall.
Why should the government feed Corp X if this is a for-seeable problem?
Bug fixes to the original application would depend on the vendor. New features, however, could be implemented by utilties that work with the data created by the application.
So you have a dozen applications to do what you thought the one you first bought should have done? End users will love that.
And if the original application was too buggy to work with at all, why was it purchased to begin with?
The bugs might not have been discovered. What if a gaping security hole is discovered in your closed source application after you bought it? It also doesn't have to be "too buggy to work at all." Any discovered bugs should be fixed if possible. A patch to a minor bug can prevent major headaches.
Open sourced solutions can be costly to bugfix as well. If your package is abandoned, you'd have to _hire_ people to fix it.
I agree that specific applications can be more expensive, but with open source you'd ALWAYS have the option of hiring someone to fix it. Not so with closed source--the vendor has a monopoly on the ability to fix things. Good luck trying to negotiate with them by saying you'll hire someone else who is cheaper.
Basically, having open file formats is like a foot in the door for open source software: If free/open source software can work with the same d
One of the main complaints about closed source software is that the proprietary, closed file formats keep you locked in
Other valid complaints are the per-seat costs, upgrade costs, limited effectiveness of outside support, architecture lock-in, and a slow, costly route to get bug-fixes and new features implemented. And, of course, the threat of being left out-in-the-cold if the company stops offering the proprietary program (or if said company collapses).
Mandating open source software, while appearing good, would be a bad thing. Software should be used based on fitness for purpose; if the open source solution is superior, then use it. But don't use an inferior open source app just because it's open source if a superior closed source one is available and affordable.
Mandating open source software is a very good thing for governments to do. If open source solutions aren't available for some needs, the government would be able to reassess the need. If it was sufficiently strong, they should want an open source solution. This would address the other problems with closed-source software. It would be better and ultimately cheaper for taxpayers in many cases if they sponsored the development of an open source replacement.
I think OpenDX is a bit more than just a tool-kit. It also has a great GUI for doing visualization, without the need for too much coding (somewhat analagous to LabView, I suppose). I have found I really like MayaVI, which is a GUI for VTK. MayaVI/VTK are python scriptable, which is great.
X.org was forked from XFree86. That wasn't TOO long ago & Apple X11 has been around for a while, so it really doesn't matter much.
XFree86 and X.org are certainly fairly compatible. (The benefits of having a well-designed, open protocol). I've found more things incompatible with either GNU Emacs or XEmacs. But, like this famous fork, I'm sure that the X-related forks will squash incompatibility bugs that pop up for popular apps.
One of the freedoms is the freedom to share. This is what inherently makes a lot of F/OSS free-as-in-beer. But if there was so little demand for a F/OSS that few people bothered to share it, & you are one of the few who desperately need it, would it not be worth paying for?
You said elsewhere that your sofware will have about a dozen customers. This might as well be a custom app that you do for a single customer. You can probably get money out of the customers--they are unlikely to share it with one another & only are allowed to do so (not forced).
Similarly, you should still be able to demand a cut of support fees: the support people will probably have to talk to the developers & may even ask them for maintenance releases. If you have a low demand product, no one will understand your work better than you & your time will be worth money.
Re:There's a missing fifth fundamental freedom
on
Being Free is Hard to Do
·
· Score: 2, Insightful
(or sell said improvements to the public for profit)"
To be more accurate: the GPL DOES allow this...it just forces you to make that software you sell Free (as in Freedom). But this wasn't the kind of thing you were arguing about the right for.
Re:There's a missing fifth fundamental freedom
on
Being Free is Hard to Do
·
· Score: 4, Insightful
"The freedom to improve the program, and not release your improvements to the public"
The GPL allows this.
(or sell said improvements to the public for profit)"
But not this. What incentive do people who believe in the GPL for letting you get a jump-start on a closed commercial product. Strategically useful tools are often placed under an LGPL or BSD-type license if their wide-spread adoption will help the community. But for some things, GPL authors are rightfully greedy. If I developed a free end-user application, I would very much resent it if I couldn't take advantage of someone else's improvements. No one is writing GPLed software to make it easier for you to personally make a buck off it.
The obligation [e.g. lack of freedom] to integrate GPL code with [often immense] business-owned closed code serves on one hand to spur [few, IMHO] businesses to go opensource
If businesses have immense closed code, they have the resources to generate more of it themselves. How would GPLed code help both them and the F/OSS community?
What you see as lack of freedom I see as freedom: users are GUARANTEED the improvements made by others!
but since the original dev never considered this and just slapped the GPL on his work, and you can't use it (whereas had he done so with LGPL, you would be able to do so).
Contact the developer. He may relicense it to you. Since you are selling it, you might want to/have to compensate him financially for a license.
A dozen posts & already many that confuse no-cost software with software that you can do anything with, including viewing & modifying the source & sharing it with others.
A love for zero-cost software isn't bad. I see a lot of people coming to the F/OSS movement because of it. They could run a warez copy of Photoshop, but then they discover the GIMP. After a while, they may discover the fantastic quality of software available & may try more of it. They might discover how wonderfully helpful and intelligent the community is--they are eager to help & are eager to have you contribute back.
I probably wouldn't have started to use F/OSS if it was priced unreasonably. But now I find the other parts of freedom to be much more important. It is frustrating to find commercial software that is stagnant. Bugs are always present in any software (some of which are security vulnerabilities, some of which are just annoyances that I have run into). But with F/OSS, I can usually see if a bug has already been reported, look for solutions, or report it & wait for insight from others. I'm not much of a programmer, but I can also sometimes discover a fix myself. The frustration of not being able to have this basic ability with some nonfree software is horrid.
I recently started to contribute a small amount of money each month to software which I use every day--which I depend on for entertainment and to get my work done. Paying for free software?! Well, at least it is tax deductible & it does make me feel good.
I would definitely say that the four freedoms are more important than zero-cost.
Many people do get paid making F/OSS. Furthermore, the freedoms have little to do with price. While having the source code and being able to share software might mean that a lot of people use it & don't pay for it, that doesn't mean there won't be people who do pay for it. This is especially true of custom-software.
Thank you for your post. Please see my previous post which I made after research this secific grie a bit more.
Your reason does apply to some programs. A custom piece of software littered c:\ (Not even %SYSTEMROOT% (or whatever the relative name for it is)), and c:\windows (even less excuse for that one!) with temp files.
The argument of requiring each user to have their own set of plugins & wating time/space is a poor one. Most modern OSs have user home directories & directories which can be used for system-wide files. It is definitely NOT the case for Mozilla: they store extensions and themes under a user's home directory just fine. And the search plugins which we gripe about are TINY. They consist of an icon-sized image (almost always less than 1 K) & a short XML file (almost always less than 2 K & often less than 1 K).
You are absolutely wrong. The location of search plugins and extensions is distribution-secific. On my distro you can install extensions to:
~/.mozilla/firefox/default.{profile}/extensions
which means individual users can install their own extensions (which I believe is what you refer to).
Search plugins, which the story refers to on win32 & which I refer to in my response, are installed to the installation folder. On the box I'm currently on, that is:
/usr/lib/MozillaFirefox/searchplugins
you have to install as root with the default permissions.
Very interesting point. Most people also consider 'martini' to refer to the style of drink and now even to the glass it is served in. So a variant like a "gibson" is still considered a "martini," even if it has the cocktail onion garnish instead of traditional olives or twists (anyone know if there is a different name denoting these two variants (Dickens is used for one with no garnish)?). I would assume the same was true for "Bradford."
This is really a good point. We do have every right to deride MS for the tools the windows install cd is missing (I really miss grep sometimes), but most tools to be used on the CLI can be added quite easily.
If we are going to criticize cmd, we should criticize it for not being very configurable (unless someone else has figured out how to make a.cmdrc;-)) and not very feature rich (i.e. ANSI support and forms of piping are non-existant or broken).
cmd+DOSKEY being "quite reasonable" is a matter of personal taste. It is certainly no good for what I get done, but at least it does exist for when I need it. I will say with out ANY doubt that it is the single worst default CLI on any modern OS.
Now type the first 3 letters of a command and press tab.
Right you are, windows tab-completion does not completes executable names in the path.
It also lacks an extremely cool feature of modern shells, which is context-sensitive completion. The best example being command line completion. The combo of bash and bash-completion or using zsh allows you to only complete pdfs in the current directory if you have started your command with acroread or xpdf. You can program them to know the command line switches used by the programs as well.
Completion behavior in these fine shells can also be changed in both shells: to not complete if there is ambiguity, to complete up to the ambiguity, to list the possible completions, to cycle through the different possible completions, and even to base the decision on the number of possible completions.
but every unix user I have ever met cannot do all of the things that I do.
I have run 4NT and 4DOS. They do add a lot of things MS should have had for the CLI in the beginning. (But then MS doesn't really see the value in the CLI--they've taken away features--cmd doesn't support ANSI (you can usually still run command, but it is slow & buggy & discouraged) and many CLI apps they've included don't have useful command line switches, such as ones to reveal version and help.)
But what, exactly, do you feel that you can do on your multiple versions of a win32 CLI that *nix users can't do?
Slashdot Mirror
IPSec is probably the "standard." Most hardware implementations use this. There are client/servers on all platforms & encryption doesn't have the same weaknesses. Depending on the implementation, this can be either tedious or non-free to setup.
I like OpenVPN, which uses SSL, is VERY portable, and very easy to use. Plays well with both NAT and dynamic addresses. The only reason to use IPSec, in my opinion, is if there are hardware devices in the way. But OpenVPN is beginning to be found on some devices too.
First, my universal advice: DON'T get in the habit of fixing remote systems for free. It is a huge time-sink & it would be better if you don't foster that dependence. I sometimes fix problems over email or in person for friends/family, but I also usually weasel some free beer out of the deal.
That being said, many have to remotely administer machines for OTHER reasons. Oftentimes, a shell is all that is needed & having OpenSSH is good enough. It is available for win32 too. This can also be used for port forwarding if other daemons are needed.
If you don't need SSH/SFTP & do need a secure connection, setup a VPN. OpenVPN is great:cross-platform, secure, and easy to install. IPSec is still the standard, but I don't bother with it unless I have to (like when my company would buy a hardware implementation). I try to avoid PPTP. It works OK on windows. Not so well on other platforms (poptop does a pretty fair job, though). It also believe it has some known (but, I again believe, still unexploited) security weaknesses.
You hooked on the GUI? I use VNC over VPN or stunnel. I don't really like remote desktop, but if you have to support it put RDesktop on your *nix box. FreeNX is, in many ways, better than both. I like it a lot, but I haven't used it under windows (it can be done & someone might have made it quick-and-easy, but I try to avoid supporting windows machines).
My system would fail without any complaints (and not remake until the next file change), so sometimes I didn't get around it. I also normally used the system when most dependent files were already written & I was just refining them.
However, I also used simple auto-dependency generation for projects where I was also making new files. I suspect this is the particular detail you were interested in & would advise you to check outa few tutorials on GNU make if you want to implement a similar system.
I might be able to dig out my old scripts, but the only thing I currently do that is even close is to automatically recompile my LaTeX files, which is usually much simpler.
Background/predictive compilation isn't too novel or unique either. I used to hack it with scripts and makefiles--they'd basically watch for file writes. I didn't actually use it to catch bugs, as you apparently can in eclipse & xcode now--I just did it so I wouldn't have to wait at the shell when I needed to test. I now use python & can get feedback quickly enough if I use some sort of interactive mode (I am partial to ipython).
From their FAQ, it sounds like eclipse does exactly what my old scripts and makefiles did--compile on file saves. They also call it "incremental." Any eclipse fans out there want to clear this up?
An officemate tells me that Visual Studio also has some sort of background compilation.
I didn't even realize that Enigmail allows you to create keys (I actually created mine on the CLI) & the only complaint that is left is the quote-unquote difficulty of installing GPG under windows (it isn't hard--there are installers, such as the one for WinPT).
And, rather than throwing good money after bad to upgrade and maintain closed source software, public agencies should fund efforts to bring free open source software to the public. Perhaps they should keep proprietary software that has already been paid for, but as a taxpayer I want the most bang for my buck. This would be a strong argument against any commercial product that could charge a lot of money to MA & then to IL & so on, when a Free (in both senses of the word) program could be used instead.
So why not do it now? The argument against doing it later will be "we've already invested so much money and time in closed product X from company Y, that it would cost an unreasonable amount to build F/OSS program Z from scratch."
This is short-sighted. First of all, the vendors can charge much more than an upgrade is worth--they just have to keep it cheaper than a replacement. Furthermore, the "annual upgrade tax" to the company will add up quicker than F/OSS over the lifetime the files need to be read.
And how often do you suppose problems are with the file format? Support is almost always inherently for the particular product.
Why should the government feed Corp X if this is a for-seeable problem?
So you have a dozen applications to do what you thought the one you first bought should have done? End users will love that.
The bugs might not have been discovered. What if a gaping security hole is discovered in your closed source application after you bought it? It also doesn't have to be "too buggy to work at all." Any discovered bugs should be fixed if possible. A patch to a minor bug can prevent major headaches.
I agree that specific applications can be more expensive, but with open source you'd ALWAYS have the option of hiring someone to fix it. Not so with closed source--the vendor has a monopoly on the ability to fix things. Good luck trying to negotiate with them by saying you'll hire someone else who is cheaper.
For the windows impaired, there is WinPT, which is both easy to install & has a GUI for key management.
I think OpenDX is a bit more than just a tool-kit. It also has a great GUI for doing visualization, without the need for too much coding (somewhat analagous to LabView, I suppose). I have found I really like MayaVI, which is a GUI for VTK. MayaVI/VTK are python scriptable, which is great.
X.org was forked from XFree86. That wasn't TOO long ago & Apple X11 has been around for a while, so it really doesn't matter much.
XFree86 and X.org are certainly fairly compatible. (The benefits of having a well-designed, open protocol). I've found more things incompatible with either GNU Emacs or XEmacs. But, like this famous fork, I'm sure that the X-related forks will squash incompatibility bugs that pop up for popular apps.
One of the freedoms is the freedom to share. This is what inherently makes a lot of F/OSS free-as-in-beer. But if there was so little demand for a F/OSS that few people bothered to share it, & you are one of the few who desperately need it, would it not be worth paying for?
You said elsewhere that your sofware will have about a dozen customers. This might as well be a custom app that you do for a single customer. You can probably get money out of the customers--they are unlikely to share it with one another & only are allowed to do so (not forced).
Similarly, you should still be able to demand a cut of support fees: the support people will probably have to talk to the developers & may even ask them for maintenance releases. If you have a low demand product, no one will understand your work better than you & your time will be worth money.
What you see as lack of freedom I see as freedom: users are GUARANTEED the improvements made by others!Contact the developer. He may relicense it to you. Since you are selling it, you might want to/have to compensate him financially for a license.
A dozen posts & already many that confuse no-cost software with software that you can do anything with, including viewing & modifying the source & sharing it with others.
A love for zero-cost software isn't bad. I see a lot of people coming to the F/OSS movement because of it. They could run a warez copy of Photoshop, but then they discover the GIMP. After a while, they may discover the fantastic quality of software available & may try more of it. They might discover how wonderfully helpful and intelligent the community is--they are eager to help & are eager to have you contribute back.
I probably wouldn't have started to use F/OSS if it was priced unreasonably. But now I find the other parts of freedom to be much more important. It is frustrating to find commercial software that is stagnant. Bugs are always present in any software (some of which are security vulnerabilities, some of which are just annoyances that I have run into). But with F/OSS, I can usually see if a bug has already been reported, look for solutions, or report it & wait for insight from others. I'm not much of a programmer, but I can also sometimes discover a fix myself. The frustration of not being able to have this basic ability with some nonfree software is horrid.
I recently started to contribute a small amount of money each month to software which I use every day--which I depend on for entertainment and to get my work done. Paying for free software?! Well, at least it is tax deductible & it does make me feel good.
I would definitely say that the four freedoms are more important than zero-cost.
Many people do get paid making F/OSS. Furthermore, the freedoms have little to do with price. While having the source code and being able to share software might mean that a lot of people use it & don't pay for it, that doesn't mean there won't be people who do pay for it. This is especially true of custom-software.
Thank you for your post. Please see my previous post which I made after research this secific grie a bit more.
Your reason does apply to some programs. A custom piece of software littered c:\ (Not even %SYSTEMROOT% (or whatever the relative name for it is)), and c:\windows (even less excuse for that one!) with temp files.
The argument of requiring each user to have their own set of plugins & wating time/space is a poor one. Most modern OSs have user home directories & directories which can be used for system-wide files. It is definitely NOT the case for Mozilla: they store extensions and themes under a user's home directory just fine. And the search plugins which we gripe about are TINY. They consist of an icon-sized image (almost always less than 1 K) & a short XML file (almost always less than 2 K & often less than 1 K).
Search plugins, which the story refers to on win32 & which I refer to in my response, are installed to the installation folder. On the box I'm currently on, that is:you have to install as root with the default permissions.
This is a known bug: look at bug #232638: (no linky because they don't allow links from slashdot)
Very interesting point. Most people also consider 'martini' to refer to the style of drink and now even to the glass it is served in. So a variant like a "gibson" is still considered a "martini," even if it has the cocktail onion garnish instead of traditional olives or twists (anyone know if there is a different name denoting these two variants (Dickens is used for one with no garnish)?). I would assume the same was true for "Bradford."
This is really a good point. We do have every right to deride MS for the tools the windows install cd is missing (I really miss grep sometimes), but most tools to be used on the CLI can be added quite easily.
.cmdrc ;-)) and not very feature rich (i.e. ANSI support and forms of piping are non-existant or broken).
If we are going to criticize cmd, we should criticize it for not being very configurable (unless someone else has figured out how to make a
cmd+DOSKEY being "quite reasonable" is a matter of personal taste. It is certainly no good for what I get done, but at least it does exist for when I need it. I will say with out ANY doubt that it is the single worst default CLI on any modern OS.
Completion behavior in these fine shells can also be changed in both shells: to not complete if there is ambiguity, to complete up to the ambiguity, to list the possible completions, to cycle through the different possible completions, and even to base the decision on the number of possible completions.
But what, exactly, do you feel that you can do on your multiple versions of a win32 CLI that *nix users can't do?