Check this out: Digiportal's innovative new ChoiceMail program means the end of spam. I really don't like the idea of using someone else's server to manage my white-list, but all someone needs to do is publish an open-source CGI script to do this... integrated with qmail.
Great beer and a traditional environment. Good choice.
I've been using Subversion for three months...
on
Subversion Hits Alpha
·
· Score: 4, Interesting
... and have been really happy with it. Setting it up is a thesis project (the most common problem with software that's free) but once that was done, it works beautifully.
SCC works well for several purposes:
Backup--I save everything in a personal 'svndocs' directory; including stuff like quicken databases, word documents, all that stuff. Just 'svn commit' (or in my previous life, 'cvs commit') and you have your backup stored on another computer. I had a laptop die at a customer's site, and it took downloading the client and 20 minutes to resume development on another computer. My brownie point score soared.
Share files with customers which are far away. SCC acts like a low-bandwidth file server. There are suddenly no hassles putting together installers and such; so the rate at which you can deploy updates greatly increases. CVS really sucks when it comes to directory versioning, that's why I switched to SVN. I can now configure the whole deployment tree on my side, and don't have to start e-mails with 'well, because CVS can't do this, you need to delete the whole project and check out over again.' Monkeying around with directories is much more important, considering the way that ant relies on java files being in directories which correspond to their package names.
As a long time RTOS programmer, and being a contributor to the ECOS project, I think that this is a terrible blow for the open source community. Is open source (and LGPL) viable? This decision suggests not.
The best thing about open source is that you don't have to rely on an inept customer service person to figure out that they in fact have problems in their system. I've spent weeks asking a large closed source and very expensive RTOS vendor to fix some of the dumbest OS bugs (admittedly in a new JVM product they'd hardly released yet)--they still don't believe the one page test programs I send them; in fact, I've just been simply astounded at the dumb things I've been told to do. There's nothing worse than knowing that if you had the source, you'd just simply fix the problem, submit the change, and move on. And you know what's worst? The development tools for this expensive RTOS were cygnus anyway.
The eCos source code was very well written, it's confiuration understandable (and scriptable!), and all in all, a very well concieved project. I will do a CVS update now; and hang on tight to that system... it will be well worth it.
The problem is that security though obscurity merely shifts the problem from one place to another: it's guranteed that someone at some point in the future will figure it out and take advantage of it. Then we get to wait for someone to fix it; which is homework they should have done in the first place. We have a precedent in cases like this; product liability lawsuits are the only real check against products with problems which manufacturers would rather hide.
Yup, I'd suggest the s-corp as well. A few more benefits:
1) Since you issue stock, you can use it to lure more good people in as partners or to generate capital from outside parties. If you sell stock carefully, you can still keep control of your company.
2) The IRS has been really tough on companies that hire software contractors--they really have to be prepared to be audited for hiring hourly software people who are only filing schedule Cs. Every contract I've worked on got this complaint, which is completely solved by being either LLC or incorporated.
Don't forget that for people who don't understand how computing tools work, Unix kinda doesn't make much sense regardless of how it's taught. Pipes and filters really only make sense when you're filtering down large lists of information... and this kind of information pretty much only happens in system administrative contexts.
There is a real lack of recourse for us end-users. It seems like the ones most unable to actually solve electronic security problems are the ones who get left with the responsibility for dealing it. How about incentives for insurance companies and credit card companies to help audit elecronic security, like some sort of government mandated identity theft insurance that companies should have.
There is a bunch of work available at www.opencores.org, which I would guess is a really good place to get some ideas. It's rare that these things will just work out of the box; but it seems like the point here is personal education, not agressive schedules, customers, and deadlines. I always find good value in seeing how others have written their designs; whether those designs are good or bad. Experience is always the best teacher!
Seems to me that credit card companies need to start suing websites which jeopardize the integrity of credit card numbers-- that until online merchants feel a real monetary incentive to get their security right, there will be no incentive at all. Courts, credit card companies, and insurance companies are the ones who really need to step up to the plate here. I firmly believe that a big part of the failure of online commerce has to do with the negative press which these compromises create...
Check this out:
Digiportal's innovative new ChoiceMail program means the end of spam. I really don't like the idea of using someone else's server to manage my white-list, but all someone needs to do is publish an open-source CGI script to do this... integrated with qmail.
Great beer and a traditional environment. Good choice.
SCC works well for several purposes:
As a long time RTOS programmer, and being a contributor to the ECOS project, I think that this is a terrible blow for the open source community. Is open source (and LGPL) viable? This decision suggests not.
The best thing about open source is that you don't have to rely on an inept customer service person to figure out that they in fact have problems in their system. I've spent weeks asking a large closed source and very expensive RTOS vendor to fix some of the dumbest OS bugs (admittedly in a new JVM product they'd hardly released yet)--they still don't believe the one page test programs I send them; in fact, I've just been simply astounded at the dumb things I've been told to do. There's nothing worse than knowing that if you had the source, you'd just simply fix the problem, submit the change, and move on. And you know what's worst? The development tools for this expensive RTOS were cygnus anyway.
The eCos source code was very well written, it's confiuration understandable (and scriptable!), and all in all, a very well concieved project. I will do a CVS update now; and hang on tight to that system... it will be well worth it.
The problem is that security though obscurity merely shifts the problem from one place to another: it's guranteed that someone at some point in the future will figure it out and take advantage of it. Then we get to wait for someone to fix it; which is homework they should have done in the first place. We have a precedent in cases like this; product liability lawsuits are the only real check against products with problems which manufacturers would rather hide.
Check out Analog devices; their 2181 demo has echo cancellation as a part of the included software; source included.
Yup, I'd suggest the s-corp as well. A few more benefits:
1) Since you issue stock, you can use it to lure more good people in as partners or to generate capital from outside parties. If you sell stock carefully, you can still keep control of your company.
2) The IRS has been really tough on companies that hire software contractors--they really have to be prepared to be audited for hiring hourly software people who are only filing schedule Cs. Every contract I've worked on got this complaint, which is completely solved by being either LLC or incorporated.
Don't forget that for people who don't understand how computing tools work, Unix kinda doesn't make much sense regardless of how it's taught. Pipes and filters really only make sense when you're filtering down large lists of information... and this kind of information pretty much only happens in system administrative contexts.
There is a real lack of recourse for us end-users. It seems like the ones most unable to actually solve electronic security problems are the ones who get left with the responsibility for dealing it. How about incentives for insurance companies and credit card companies to help audit elecronic security, like some sort of government mandated identity theft insurance that companies should have.
There is a bunch of work available at www.opencores.org, which I would guess is a really good place to get some ideas. It's rare that these things will just work out of the box; but it seems like the point here is personal education, not agressive schedules, customers, and deadlines. I always find good value in seeing how others have written their designs; whether those designs are good or bad. Experience is always the best teacher!
Seems to me that credit card companies need to start suing websites which jeopardize the integrity of credit card numbers-- that until online merchants feel a real monetary incentive to get their security right, there will be no incentive at all. Courts, credit card companies, and insurance companies are the ones who really need to step up to the plate here. I firmly believe that a big part of the failure of online commerce has to do with the negative press which these compromises create...