Haven't these people heard about HIPAA? You can't just transmit personal health information over arbitrary text message networks. It doesn't matter if they have a "secure server" somewhere(*). The whole network needs to be secure and auditable. And something tells me that this isn't the case for text messages.
(*) Google can find exactly two mentions of text4baby and HIPAA, both of which just say that there is a secure server.
> if it wasn't for Microsoft, we would probably still be using IBM PC's.
That's just plain wrong. IBM opened up the architecture of the PC, so that anybody could make compatible products. Some engineers at Texas Instruments, frustrated by the shortcomings of the "nearly compatible" TI-PC, started Compaq. THAT is why we've got so much variety in the computer industry. Microsoft was just willing to sell to anybody.
Isn't it obvious? Spammers annoy everybody because they can do so without cost. The police have found a way to cost them money, which may actually result in less (sticker) SPAM.
The logical extension is to apply the concepts of open source collaboration for email SPAM. Today a shady business can pay $5000 to a spammer to send 10,000,000 emails, and they get a profit because of the 0.01% response rate. Wouldn't it be a lot more fun if they got 10,000,000 emails and 10,000,000 web hits? Then let them try to sort the wheat from the chaff.
Should end users set up their SPAM filters to bounce the offending messages, or should they just get quitely filed into the SPAM folder?
I used Mailwasher for a while, which gives users the options of generating bounce messages while filtering. There is some personal gratification in making it look like my email address doesn't exist. But does it actually help, or does it just add to the ISP's bandwidth requirements?
Try the solution that has been successful for most of the GNU projects. Take a careful look at GNU's automake and autoconf packages. You'll find them at the Program Build Automation section of the GNU software directory. In addition to the reference manuals from GNU, you'll want to read through the book Autoconf, Automake, and Libtool
which is the only book I've found on the subject.
I've just started using these tools in the last couple of months, replacing a complex and brittle hand-coded multi-platform makefile system. To be perfectly honest, there isn't enough tutorial information for setting up a new project. But once you figure out the magic incantations that your software needs, autoconf seems to do a nice job of detecting incompatibilities and passing them through the make system to your code. Automake generates the thousand-line makefiles replete with targets for all, clean, install, etc. All I have to do is list the source code files for a given module or library. These tools will do the rest.
That isn't to say that my code became instantly portable. After we got a small application working on HP-UX, we just configure/make'd on Windows. Everything compiled under mingw, but the Windows crtl has different ideas about little posixy things like user names. So we had to add some portability code based on the checks that configure performs for us.
Overall, I'm looking forward to not messing around with makefile systems much any more, and concentrating on the more interesting bits of software development.
Rogue Wave changed its licensing scheme a year or so back. It used to be that you could buy a developer license for a few kilobucks and you were all set. But they changed their revenue model to include a per-deployment fee. That's right. Every person running your software has to pony up for a run-time license. Some folks can just add a few bucks to the sale price. Others have to look for an alternative to Rogue Wave.
The Tcl C library has rock-solid support for serial and network I/O for both Unix and Windows. You language buffs may recall that John Ousterhout first created the Tool Command Language (TCL) as a C library supporting electronic CAD applications. You can check out the interface for I/O channels in the online man pages.
Tcl's thread support is a little more limited. There is a thread extension which is supposed to be pretty good. (I haven't personally used it.) But unless your application is running on multiprocessors, you probably don't need threads and should consider an event-based model. (see "Why Threads Are A Bad Idea" PowerPoint only, sorry.) Events are just plain easier to program and support than threads. And Tcl's event support is excellent.
As a side benefit, you'd get a free scripting environment to prototype your application's communications subsystem.
A method using electronic mail or similar technology to disseminate advertising materials or other information to many different computer users who have not specifically requested the information, and including procedures to "harvest" target electronic mail addresses from public message forums and directories, and online registrations that include fields similar to "Uncheck this box if you do not want SPAM" where the user is required to take extra action to avoid being the target of SPAM.
Slashdot Mirror
Haven't these people heard about HIPAA? You can't just transmit personal health information over arbitrary text message networks. It doesn't matter if they have a "secure server" somewhere(*). The whole network needs to be secure and auditable. And something tells me that this isn't the case for text messages.
(*) Google can find exactly two mentions of text4baby and HIPAA, both of which just say that there is a secure server.
> if it wasn't for Microsoft, we would probably still be using IBM PC's.
That's just plain wrong. IBM opened up the architecture of the PC, so that anybody could make compatible products. Some engineers at Texas Instruments, frustrated by the shortcomings of the "nearly compatible" TI-PC, started Compaq. THAT is why we've got so much variety in the computer industry. Microsoft was just willing to sell to anybody.
Isn't it obvious? Spammers annoy everybody because they can do so without cost. The police have found a way to cost them money, which may actually result in less (sticker) SPAM.
The logical extension is to apply the concepts of open source collaboration for email SPAM. Today a shady business can pay $5000 to a spammer to send 10,000,000 emails, and they get a profit because of the 0.01% response rate. Wouldn't it be a lot more fun if they got 10,000,000 emails and 10,000,000 web hits? Then let them try to sort the wheat from the chaff.
Stop filtering, and just hit REPLY
Should end users set up their SPAM filters to bounce the offending messages, or should they just get quitely filed into the SPAM folder?
I used Mailwasher for a while, which gives users the options of generating bounce messages while filtering. There is some personal gratification in making it look like my email address doesn't exist. But does it actually help, or does it just add to the ISP's bandwidth requirements?
Try the solution that has been successful for most of the GNU projects. Take a careful look at GNU's automake and autoconf packages. You'll find them at the Program Build Automation section of the GNU software directory. In addition to the reference manuals from GNU, you'll want to read through the book Autoconf, Automake, and Libtool
which is the only book I've found on the subject.
I've just started using these tools in the last couple of months, replacing a complex and brittle hand-coded multi-platform makefile system. To be perfectly honest, there isn't enough tutorial information for setting up a new project. But once you figure out the magic incantations that your software needs, autoconf seems to do a nice job of detecting incompatibilities and passing them through the make system to your code. Automake generates the thousand-line makefiles replete with targets for all, clean, install, etc. All I have to do is list the source code files for a given module or library. These tools will do the rest.
That isn't to say that my code became instantly portable. After we got a small application working on HP-UX, we just configure/make'd on Windows. Everything compiled under mingw, but the Windows crtl has different ideas about little posixy things like user names. So we had to add some portability code based on the checks that configure performs for us.
Overall, I'm looking forward to not messing around with makefile systems much any more, and concentrating on the more interesting bits of software development.
Rogue Wave changed its licensing scheme a year or so back. It used to be that you could buy a developer license for a few kilobucks and you were all set. But they changed their revenue model to include a per-deployment fee. That's right. Every person running your software has to pony up for a run-time license. Some folks can just add a few bucks to the sale price. Others have to look for an alternative to Rogue Wave.
The Tcl C library has rock-solid support for serial and network I/O for both Unix and Windows. You language buffs may recall that John Ousterhout first created the Tool Command Language (TCL) as a C library supporting electronic CAD applications. You can check out the interface for I/O channels in the online man pages.
Tcl's thread support is a little more limited. There is a thread extension which is supposed to be pretty good. (I haven't personally used it.) But unless your application is running on multiprocessors, you probably don't need threads and should consider an event-based model. (see "Why Threads Are A Bad Idea" PowerPoint only, sorry.) Events are just plain easier to program and support than threads. And Tcl's event support is excellent.
As a side benefit, you'd get a free scripting environment to prototype your application's communications subsystem.
A method using electronic mail or similar technology to disseminate advertising materials or other information to many different computer users who have not specifically requested the information, and including procedures to "harvest" target electronic mail addresses from public message forums and directories, and online registrations that include fields similar to "Uncheck this box if you do not want SPAM" where the user is required to take extra action to avoid being the target of SPAM.