Cingular mostly still uses TDMA, as does AT&T. Both are in the process of migrating to GSM, but coverage is not available everywhere yet. Sprint/Verizon are CDMA only. The only GSM-only carrier is T-Mobile. T-Mobile has the best data service (at least in Florida, AT&T/Cingular/Sprint/Verizon are only about the speed of dial-up), but has horrible coverage. If you're more than 20 miles from an interstate, don't expect coverage. Make a point to try before you commit to a contract, since some of the contracts (especially Verizon) are nearly impossible to get out of, even if the service doesn't work.
now where did I put that telegraph plug-in for exchange? No, seriously, you could do that (at the low end-dit-dah), or something like uucp (which is probably the more traditional way of non-internet email)
Third, if you ever really tried to meet HIPAA requirements, you would either: a) need DNA samples of every person in the world, and physically meet with, swab, DNA compare, have a judge verify the DNA results with a court order, and perform all interactions with the patient in a sound-proof chamber. Also, don't even write the patient's name down, that could be considered insecure. Any results you receive must not identify the patient (and ideally would not identify the results, either; in fact, you're better off just handing the patient a blank piece of paper and collecting for the office visit), just in case they fall into the wrong hands. You should bill the insurance company, using the same meet, swap, test, sound-proof method as with the patient, only you shouldn't tell them what you did, or how much you charge. Note that no law requires them to pay you for your trouble. You shouldn't use a computer to document any of this, or document this in any way; in fact, you probably shouldn't even know that you're doing this. If the computer (or paper, or you) were to fall into the wrong hands, the patient's privacy could be compromised.
Alternatively, you could: b) let the patient die, walk it off, take 2 aspirin and leave you alone. But don't let the patient identify themselves, or identify what is wrong with them, since that would be PHI (Personal Health Information), which is protected by HIPAA, and it's just to dangerous for the patient if you know about it.
Basically, the key part for us is the security rule, which pretty much says "if you know it, make sure nobody else could possibly find out about it from you, or you're #@!*ed". They then go on to suggest proper PHI security methods, such as "unplug your computers, cut the microphone wires from your telephones, remove all ink/toner from printers, and mind-wipe all employees at 15-minute intervals" (no, not really, but eerily close, you really are screwed if even the most trivial thing COULD be disclosed, they do in-fact specify that all transmissions between computers must be encrypted, even within networks which are not accessible from the outside, though without specification as to what encryption must be used, just that it better not be broken).
It actually makes the gov'ts job harder when they want to find information about someone's healthcare history
Umm, no... If they want to know, they just ask. Often when a Medicare/Medicaid claim is filed, they will ask the provider for more information, not to mention the fact that the state will come in to inspect you, and look at several patient's information, every year. Refusal of either of these means that you either won't get paid, or you lose your license.
Also, be aware that for many infectious diseases, both the laboratory and the physician are REQUIRED by law to report positive results to the local health department, which means that if you got a "confidential" HIV test, it's really only confidential if it's negative. In fact, the state asked us last year for a list of all HIV positive test results for the year (just screens, not viral loads for people who already knew they had it), because they expected us to have more than what we had reported. Same goes for Hepatitis, Chlamydia, HPV, Herpes, etc. Uncle Sam may not know what your triglyceride level is, but that's only because they don't care....yet. To practice medicine in the US means you have to play by their rules, whether that screws the patient or not (and the rules are always a moving target, but rarely move towards privacy).
3ware is definitely the way to go. We use them exclusively where I work for SATA RAID, and Adaptec for SCSI. Works in Linux, FreeBSD, and Windows, has REAL hardware RAID (unlike the Promise cards), and gives you great management tools, both in firmware and software. The only possible issue you might have is that they are certainly not the cheapest solution. Then again, how much is it worth to you not to be called about an array failure at 4 AM?
Also, since you're using SATA, why only 4 drives? Even with the Raptors, that doesn't seem like a high-performance setup. The minimum we have in a more than RAID 1 (simple mirror) setup is 6 drives, and those are 15k U320 drives, for SATA we have at least 8 drives. If you're going to eat the time on rotational latency, at least make it up with more spindles, and don't forget to have at least one hot-standby drive (which would also require you to have a decent card/software RAID setup, cheap cards don't do hot-standby).
The motive is simple, really. We have virtually no control over the systems once they are set up, since they are at client locations anywhere from 1 to 300 miles away. Having a system that is set up to do hardware detection at boot means that we can use the same image on all machines, and in combination with our own scripts, we can make the system like-new at every boot, so that even if a user manages to break something (which of course we change to avoid the problem on that and the master image for new releases), simply turning the computer off and back on will fix it. We do install to hard drives, since there are always differences between locations (either network setup, proxies, or printer differences), but we can set the machines up once, lock them down, and automatically restore the known-good settings at each boot. For clients that need more than just a kiosk, a simple script executed as root unlocks the browser (replacing browser.xul in browser.jar) and gives them a full-featured but still reasonably idiot-safe KDE/OpenOffice desktop. Another script does the exact opposite, putting in the locked-down browser.xul, and starting FireFox in full-screen mode as the only application.
In short, we COULD base it on something else, but then we'd need to install Knoppix-like startup scripts and utilities, or we can just use Knoppix, remove what we don't need through APT, install about 5 of our custom scripts and be done. Also, one key point is that this is not a large network, the most machines we have in a single facility is 4, it's just that we have them in dozens of facilities spread out over hundreds of miles. Oh, and we don't control the networks, or the employees that use them, or the physical security of the machines. Try supporting Windows machines like that, where every right-click brings disaster, especially when you get to things like Acrobat, or people moving the icon for your page off the screen, then calling you because they can't find it. (Funny point though, I do have one known-issue with FireFox that could give more access than desired, but you'll need an 8-button mouse to do it. [Can't turn off a feature, just move it to a button that doesn't exist])
Healthcare Industry. 'nuff said? Mostly older PIIIs picked up in lots of 50-100 on eBay. We put these kiosks in our client's facilities. If we spend $200 on each system (which is about right, counting printer), we MIGHT earn that money back in 2 months, not counting the time it takes to install it. It's volume business, not at all high-profit.
Also, these are field machines, usually without CD or DVD drives. Having an image that can be downloaded over a DSL or Cable modem quickly makes it easier to do field upgrades or re-image machines.
Seriously who worries about that on a reasonably modern desktop?
Klaus Knopper (Knoppix), or any other Live-CD maintainer, and me (have 50+ Knoppix-based kiosk/office systems to maintain, and like being able to keep the system images under 350MB compressed [current setup is about 320MB compressed, 1.1GB uncompressed, and contains both a kiosk mode and a normal OpenOffice/FireFox/KDE/Evolution mode], plus all of the network and printer drivers from Knoppix). Small but useful components means that a system can be booted from the network and setup with the latest image in 20 minutes. We use Acrobat 4, since it's reasonably current for our uses, loads quickly on older hardware, and keeps the image size down. As I mentioned in another thread, if I can read the splash screen, it's too damn slow.
No, 3 takes it, remember when the splash screen for startup just flashed up for a split second, not even long enough to read "Adobe"? On your 486? I still don't get the point in adding "features" to a product if it means that 99.9% of the things you do with the product take twice as long.
Aside from very simple website applications, the only situations where this migration makes sense are (required) 1) Don't want to use pgSQL, (optional) 2) Can't afford MSSQL, and (optional) 3) Have a middleware app (SOAP maybe) that handles all logic, security, and auditing.
Wait, I thought you were being sarcastic! Or were you just testing us for "which one of these is not like the others?" Seriously, have you tried Peachtree? Had to delete lock files 10 times a day? Had it crash and destroy all your data? Had it create an incomplete backup? I mean, GnuCash isn't even the same product family. GnuCash actually works. Peachtree is more closely related to the Vaporware family, since it makes all sorts of claims about how well it works, then the features disappear the first time you run it, taking half your data with it.
Agreed, actually we're considering a move from MSSQL to pgSQL at work, because we have data that would benefit from bitmap indexes (and we prefer to split our DB into several DBs, which makes Oracle/MSSQL expensive very quickly). MySQL is good for small databases, but it's certainly not enterprise ready. Stored procedures, triggers (or at least stored procedures), advanced indexes, and proven storage techniques are REQUIRED. Load up a billion records from one of your big tables, see what happens with MySQL. Now figure out how you can track who changed record #325782910, when they changed it, and what program changed it. On tables of that size, MSSQL blows, but if you're going to do all that work, at least move to something better!
Yeah, you're right, for local workstation installations, but I was thinking more for the remote/thin clients, and using something like NX, which might still have advantages even on local networks. I do know that running X sessions over slow links is not great for modeling apps, but I'm not sure if NX is really any better. Another difficult program is EtherApe, since the display will get so far behind actual events due to constant changes (on busy networks). I have used both IDEAS (modeling program) and EtherApe through an SSH tunnel, but found both to be too slow to work. Simple apps where latency isn't as obvious work well, but apps that produce complex graphics or change frequently do not. This probably has more to do with SSH than X, but a lightweight X protocol couldn't hurt. Has anyone tried these apps with NX? Is it any better?
Ok, let's say you're running something like a high-end engineering/modeling program (like IDEAS, etc.), and need the computing power of a large system (or cluster). Then you can use a terminal server to connect, and have a speed that wouldn't be possible with a single workstation. While this might be a good scenario for grid computing, not all applications are grid-based, and some network architectures just don't accommodate a grid well.
I know, see above post. Basically, my point was, for small projects, this will happen, for companies or groups that allowed this to happen for major projects (like your operations management system), basically deserve it. Little things will continue to work, or can at least be quickly rewritten. Software that is in use that is unsupportable should not be in use, whether it is due to the original author leaving (should have fired him/her for no documentation before it became a problem anyways), or a closed-source vendor going out of business or EOL'ing your product (why did you agree to those terms to begin with?). Too many companies don't read the fine print on software contracts, and I'd venture to say that less than 1% have actually read their license agreements. I mean, if I felt that I had a choice (I don't, as much as I dislike it, I have to support it), I wouldn't allow a single installation of any MS product in the building, because your mortal enemy wouldn't make you agree to a more restrictive contract. So basically, yeah, if you used MS products for all this time and didn't expect this to happen, you deserve the extra costs you'll incur when it's EOLd. One of the cardinal rules of Technology has to be: "If your [hardware/software] vendor can force you to upgrade, they will, and will do so at the greatest cost to you, and the greatest profit to themselves."
Flamebait, but I'll bite anyways. The "real world" contains plenty of organizations that don't have design documents (at least not updated ones), follow proper software engineering procedures, etc, etc... I'm not talking about them, though. Those companies/groups will have problems later, supported language or not. Any code monkey can write a piece of software that "works", it's the successful ones that can demonstrate that it works because they have an approved design, and they can demonstrate that the delivered software is a complete implementation of that design. Software without a design document is untested software, since there is no way to test without knowing WHAT the software is supposed to do, and exactly HOW it is supposed to do it. Those two elements ARE the design document, and when something changes and breaks 5 years from now, that document is what will tell you or your successor what it is that the software is supposed to do, so that you can find what part it's NOT doing correctly. If you write things that "work", you'll probably just have to rewrite them when they stop working later, since you'll have no idea what it's supposed to do.
It's a new language, that's true, and for VB6 script kiddies it might be difficult, but for people who are familiar with several languages (i.e. "Good" programmers, the ones who, given a choice, will base their choice of language based on the strengths and weaknesses of the language for the specific task they are doing, not their own strengths and weaknesses), in this case particularly those familiar with Java, VB6 to VB.Net is not that complicated. VB6 is basically a trimmed-down version of the C MS API calls with Basic syntax, and VB.Net is basically Java with Basic syntax, with the Swing classes replaced with System.Windows equivalents.
My personal favorite gripe from the VB groups, though, is the ones that complain about finding exactly what they need in C#, and can't figure out how to port it, when the only difference is syntax and a few keywords. Half of the snippets I've seen them complain about could be fixed by removing the ";"s, and using [If/Sub/Function/etc] End [If/Sub/Function/etc] instead of "{}" pairs.
Here's the solution: do what some hotels do to get you to agree to terms of service, only taken a bit further. Allow any device to connect (no WEP, just an open AP, keep it simple). Allow only DNS queries from anyone. Set up either a proxy or use a packet rewriting algorithm (like the "forward" command in FreeBSD's ipfw firewall) to redirect all outbound web traffic from source IPs/MACs (remember not to use NAT on the AP, you need the unique addresses, or use MAC addresses [better] if the firewall/proxy is the AP) that are not in a valid table or list (like one table for each hour, half hour, etc, I'm using table because that would follow with a FreeBSD ipfw2 firewall). Drop packets for any ports other than 80 (and 53, of course) for any host not in the valid list. Redirect them to a server that serves up the same single page for any requested page (they could have specified a path other than "/"). This single page should redirect them to your authentication server (this will most likely all be on the firewall, just an aliased IP that answers anything for the first page).
The authentication server gets some sort of confirmation number from the user. (printed on the reciept, insert your own clever algorithm for unique, difficult-to-guess numbers here [even better if the time can be determined by the number, or if the numbers are saved to a database somewhere]). Using the (valid) confirmation number from the receipt, the firewall/proxy adds the source IP or MAC to the valid source address table, and if you want to be really nice, you could have passed the original requested url through from the initial page that redirected them to the authentication site, and now redirect them to that page.
Set up a cron script to clean out the tables for tickets that have expired (this is why it would be easier to have your tables named for the time they expire), and you're done. Once a source IP or MAC is removed from the table, all further traffic will send them back to your authentication page, which can inform them that purchases are required for access, and the cycle can repeat. It would be best to use the firewall as the access point (put in a wireless card that is capable of being an AP), so that you can use MAC addresses to filter, and avoid the possibility that someone could leave while they have time left and have another person get the same IP, but as a minimum, you should do the DHCP from the firewall, and must do NAT from the firewall for outbound (validated) connections.
But you missed the point, partially. Rewriting a product in a new language from existing code costs very little, and rewriting from the design document (you DO have an accurate design document, right?), also costs very little, and will probably create a better final product (depending on the quality of the design document). Transposing code from one language to another simply requires a person or team of people that are familiar with both languages (which for VB and VB.NET won't be difficult, or expensive. VB/VB.NET developers are cheap, for a transition like this, freshman comp sci students will probably do, at $10-$15/hr). Creating a project from a final, up-to-date design document requires fewer people, and they only need to be familiar with the target language and your design standards. (Maybe sophomore/junior CS students, but fewer man-hours of them). The design phase of your project should be the most expensive, if it's not, you didn't do it correctly. Once the design is complete, implementation and testing are cheap.
Yeah, the major problem we have though is that our particular class A SprintLink subnet is pretty dirty, so I probably see a larger than usual number of attacks from worms with subnet affinities, like Blaster, Slammer, etc. I used to log them all, but it just got so rediculous that I couldn't even read the logs for important information. About the only things I look for on a regular basis are odd UDP attacks and access to critical public servers (which we do anyways to know exactly where our employees are when they check in, you'd be amazed how many clock in for their first stop at a location 50 miles away). Everything else is blocked, with the backend stuff all on a separate physical circuit.
Partially true. Some components of IE run in user mode, but IE uses several kernel mode parts, for doing things like installing plugins or browser helper objects, modifying registry entries, and doing abstract syntax notation (ASN.1) parsing. Sort of like running an application in Linux in user mode, as a user that has the ability to use sudo. It's a false sense of security to say it runs in user mode, because while that's true, the only real difference is that one will happily run 'rm -rf/*', and the other will need 'sudo rm -rf/*'. Browsers probably should be jailed, but I'm not aware of any that do this (could easily be done in Un*x though).
Running that on the few 5.3 systems I've had will put the mail in the send queue, sure, but it won't send it. Once you tailor the configs, it will work, but out of the box your mail just sits there in the queue until it expires. It's partially the config, and partially a bug (ahem, I mean "feature"), but it won't send. It may work if the machine is the MX for the recipient domain, haven't tried that (I would assume it would work), but it won't work if it's not, the sendmail with 5.3 has some nasty DNS issues (It will find the name of the MX for the domain, but won't resolve it).
I never did solve that issue, since I didn't need sendmail on any of the machines, so I found ssmtp.
Slashdot Mirror
Cingular mostly still uses TDMA, as does AT&T. Both are in the process of migrating to GSM, but coverage is not available everywhere yet. Sprint/Verizon are CDMA only. The only GSM-only carrier is T-Mobile. T-Mobile has the best data service (at least in Florida, AT&T/Cingular/Sprint/Verizon are only about the speed of dial-up), but has horrible coverage. If you're more than 20 miles from an interstate, don't expect coverage. Make a point to try before you commit to a contract, since some of the contracts (especially Verizon) are nearly impossible to get out of, even if the service doesn't work.
now where did I put that telegraph plug-in for exchange? No, seriously, you could do that (at the low end-dit-dah), or something like uucp (which is probably the more traditional way of non-internet email)
First of all, it's HIPAA.
Second, HIPAA requirements are never met. Ever.
Third, if you ever really tried to meet HIPAA requirements, you would either:
a) need DNA samples of every person in the world, and physically meet with, swab, DNA compare, have a judge verify the DNA results with a court order, and perform all interactions with the patient in a sound-proof chamber. Also, don't even write the patient's name down, that could be considered insecure. Any results you receive must not identify the patient (and ideally would not identify the results, either; in fact, you're better off just handing the patient a blank piece of paper and collecting for the office visit), just in case they fall into the wrong hands. You should bill the insurance company, using the same meet, swap, test, sound-proof method as with the patient, only you shouldn't tell them what you did, or how much you charge. Note that no law requires them to pay you for your trouble. You shouldn't use a computer to document any of this, or document this in any way; in fact, you probably shouldn't even know that you're doing this. If the computer (or paper, or you) were to fall into the wrong hands, the patient's privacy could be compromised.
Alternatively, you could: b) let the patient die, walk it off, take 2 aspirin and leave you alone. But don't let the patient identify themselves, or identify what is wrong with them, since that would be PHI (Personal Health Information), which is protected by HIPAA, and it's just to dangerous for the patient if you know about it.
Basically, the key part for us is the security rule, which pretty much says "if you know it, make sure nobody else could possibly find out about it from you, or you're #@!*ed". They then go on to suggest proper PHI security methods, such as "unplug your computers, cut the microphone wires from your telephones, remove all ink/toner from printers, and mind-wipe all employees at 15-minute intervals" (no, not really, but eerily close, you really are screwed if even the most trivial thing COULD be disclosed, they do in-fact specify that all transmissions between computers must be encrypted, even within networks which are not accessible from the outside, though without specification as to what encryption must be used, just that it better not be broken).
It actually makes the gov'ts job harder when they want to find information about someone's healthcare history
Umm, no... If they want to know, they just ask. Often when a Medicare/Medicaid claim is filed, they will ask the provider for more information, not to mention the fact that the state will come in to inspect you, and look at several patient's information, every year. Refusal of either of these means that you either won't get paid, or you lose your license.
Also, be aware that for many infectious diseases, both the laboratory and the physician are REQUIRED by law to report positive results to the local health department, which means that if you got a "confidential" HIV test, it's really only confidential if it's negative. In fact, the state asked us last year for a list of all HIV positive test results for the year (just screens, not viral loads for people who already knew they had it), because they expected us to have more than what we had reported. Same goes for Hepatitis, Chlamydia, HPV, Herpes, etc. Uncle Sam may not know what your triglyceride level is, but that's only because they don't care....yet. To practice medicine in the US means you have to play by their rules, whether that screws the patient or not (and the rules are always a moving target, but rarely move towards privacy).
3ware is definitely the way to go. We use them exclusively where I work for SATA RAID, and Adaptec for SCSI. Works in Linux, FreeBSD, and Windows, has REAL hardware RAID (unlike the Promise cards), and gives you great management tools, both in firmware and software. The only possible issue you might have is that they are certainly not the cheapest solution. Then again, how much is it worth to you not to be called about an array failure at 4 AM?
Also, since you're using SATA, why only 4 drives? Even with the Raptors, that doesn't seem like a high-performance setup. The minimum we have in a more than RAID 1 (simple mirror) setup is 6 drives, and those are 15k U320 drives, for SATA we have at least 8 drives. If you're going to eat the time on rotational latency, at least make it up with more spindles, and don't forget to have at least one hot-standby drive (which would also require you to have a decent card/software RAID setup, cheap cards don't do hot-standby).
The motive is simple, really. We have virtually no control over the systems once they are set up, since they are at client locations anywhere from 1 to 300 miles away. Having a system that is set up to do hardware detection at boot means that we can use the same image on all machines, and in combination with our own scripts, we can make the system like-new at every boot, so that even if a user manages to break something (which of course we change to avoid the problem on that and the master image for new releases), simply turning the computer off and back on will fix it. We do install to hard drives, since there are always differences between locations (either network setup, proxies, or printer differences), but we can set the machines up once, lock them down, and automatically restore the known-good settings at each boot. For clients that need more than just a kiosk, a simple script executed as root unlocks the browser (replacing browser.xul in browser.jar) and gives them a full-featured but still reasonably idiot-safe KDE/OpenOffice desktop. Another script does the exact opposite, putting in the locked-down browser.xul, and starting FireFox in full-screen mode as the only application.
In short, we COULD base it on something else, but then we'd need to install Knoppix-like startup scripts and utilities, or we can just use Knoppix, remove what we don't need through APT, install about 5 of our custom scripts and be done. Also, one key point is that this is not a large network, the most machines we have in a single facility is 4, it's just that we have them in dozens of facilities spread out over hundreds of miles. Oh, and we don't control the networks, or the employees that use them, or the physical security of the machines. Try supporting Windows machines like that, where every right-click brings disaster, especially when you get to things like Acrobat, or people moving the icon for your page off the screen, then calling you because they can't find it. (Funny point though, I do have one known-issue with FireFox that could give more access than desired, but you'll need an 8-button mouse to do it. [Can't turn off a feature, just move it to a button that doesn't exist])
ultra-low budget stuff
Healthcare Industry. 'nuff said? Mostly older PIIIs picked up in lots of 50-100 on eBay. We put these kiosks in our client's facilities. If we spend $200 on each system (which is about right, counting printer), we MIGHT earn that money back in 2 months, not counting the time it takes to install it. It's volume business, not at all high-profit.
Also, these are field machines, usually without CD or DVD drives. Having an image that can be downloaded over a DSL or Cable modem quickly makes it easier to do field upgrades or re-image machines.
Seriously who worries about that on a reasonably modern desktop?
Klaus Knopper (Knoppix), or any other Live-CD maintainer, and me (have 50+ Knoppix-based kiosk/office systems to maintain, and like being able to keep the system images under 350MB compressed [current setup is about 320MB compressed, 1.1GB uncompressed, and contains both a kiosk mode and a normal OpenOffice/FireFox/KDE/Evolution mode], plus all of the network and printer drivers from Knoppix). Small but useful components means that a system can be booted from the network and setup with the latest image in 20 minutes. We use Acrobat 4, since it's reasonably current for our uses, loads quickly on older hardware, and keeps the image size down. As I mentioned in another thread, if I can read the splash screen, it's too damn slow.
No, 3 takes it, remember when the splash screen for startup just flashed up for a split second, not even long enough to read "Adobe"? On your 486? I still don't get the point in adding "features" to a product if it means that 99.9% of the things you do with the product take twice as long.
Aside from very simple website applications, the only situations where this migration makes sense are (required) 1) Don't want to use pgSQL, (optional) 2) Can't afford MSSQL, and (optional) 3) Have a middleware app (SOAP maybe) that handles all logic, security, and auditing.
Peachtree Accounting --> GnuCash
Wait, I thought you were being sarcastic! Or were you just testing us for "which one of these is not like the others?" Seriously, have you tried Peachtree? Had to delete lock files 10 times a day? Had it crash and destroy all your data? Had it create an incomplete backup? I mean, GnuCash isn't even the same product family. GnuCash actually works. Peachtree is more closely related to the Vaporware family, since it makes all sorts of claims about how well it works, then the features disappear the first time you run it, taking half your data with it.
No, it doesn't. MSDN will give you single seat licenses to test OS releases, but does not give you free upgrades for your 5,000 users.
Agreed, actually we're considering a move from MSSQL to pgSQL at work, because we have data that would benefit from bitmap indexes (and we prefer to split our DB into several DBs, which makes Oracle/MSSQL expensive very quickly). MySQL is good for small databases, but it's certainly not enterprise ready. Stored procedures, triggers (or at least stored procedures), advanced indexes, and proven storage techniques are REQUIRED. Load up a billion records from one of your big tables, see what happens with MySQL. Now figure out how you can track who changed record #325782910, when they changed it, and what program changed it. On tables of that size, MSSQL blows, but if you're going to do all that work, at least move to something better!
Yeah, you're right, for local workstation installations, but I was thinking more for the remote/thin clients, and using something like NX, which might still have advantages even on local networks. I do know that running X sessions over slow links is not great for modeling apps, but I'm not sure if NX is really any better. Another difficult program is EtherApe, since the display will get so far behind actual events due to constant changes (on busy networks). I have used both IDEAS (modeling program) and EtherApe through an SSH tunnel, but found both to be too slow to work. Simple apps where latency isn't as obvious work well, but apps that produce complex graphics or change frequently do not. This probably has more to do with SSH than X, but a lightweight X protocol couldn't hurt. Has anyone tried these apps with NX? Is it any better?
Ok, let's say you're running something like a high-end engineering/modeling program (like IDEAS, etc.), and need the computing power of a large system (or cluster). Then you can use a terminal server to connect, and have a speed that wouldn't be possible with a single workstation. While this might be a good scenario for grid computing, not all applications are grid-based, and some network architectures just don't accommodate a grid well.
I know, see above post. Basically, my point was, for small projects, this will happen, for companies or groups that allowed this to happen for major projects (like your operations management system), basically deserve it. Little things will continue to work, or can at least be quickly rewritten. Software that is in use that is unsupportable should not be in use, whether it is due to the original author leaving (should have fired him/her for no documentation before it became a problem anyways), or a closed-source vendor going out of business or EOL'ing your product (why did you agree to those terms to begin with?). Too many companies don't read the fine print on software contracts, and I'd venture to say that less than 1% have actually read their license agreements. I mean, if I felt that I had a choice (I don't, as much as I dislike it, I have to support it), I wouldn't allow a single installation of any MS product in the building, because your mortal enemy wouldn't make you agree to a more restrictive contract. So basically, yeah, if you used MS products for all this time and didn't expect this to happen, you deserve the extra costs you'll incur when it's EOLd. One of the cardinal rules of Technology has to be: "If your [hardware/software] vendor can force you to upgrade, they will, and will do so at the greatest cost to you, and the greatest profit to themselves."
Flamebait, but I'll bite anyways. The "real world" contains plenty of organizations that don't have design documents (at least not updated ones), follow proper software engineering procedures, etc, etc... I'm not talking about them, though. Those companies/groups will have problems later, supported language or not. Any code monkey can write a piece of software that "works", it's the successful ones that can demonstrate that it works because they have an approved design, and they can demonstrate that the delivered software is a complete implementation of that design. Software without a design document is untested software, since there is no way to test without knowing WHAT the software is supposed to do, and exactly HOW it is supposed to do it. Those two elements ARE the design document, and when something changes and breaks 5 years from now, that document is what will tell you or your successor what it is that the software is supposed to do, so that you can find what part it's NOT doing correctly. If you write things that "work", you'll probably just have to rewrite them when they stop working later, since you'll have no idea what it's supposed to do.
It's a new language, that's true, and for VB6 script kiddies it might be difficult, but for people who are familiar with several languages (i.e. "Good" programmers, the ones who, given a choice, will base their choice of language based on the strengths and weaknesses of the language for the specific task they are doing, not their own strengths and weaknesses), in this case particularly those familiar with Java, VB6 to VB.Net is not that complicated. VB6 is basically a trimmed-down version of the C MS API calls with Basic syntax, and VB.Net is basically Java with Basic syntax, with the Swing classes replaced with System.Windows equivalents.
My personal favorite gripe from the VB groups, though, is the ones that complain about finding exactly what they need in C#, and can't figure out how to port it, when the only difference is syntax and a few keywords. Half of the snippets I've seen them complain about could be fixed by removing the ";"s, and using [If/Sub/Function/etc] End [If/Sub/Function/etc] instead of "{}" pairs.
Here's the solution: do what some hotels do to get you to agree to terms of service, only taken a bit further. Allow any device to connect (no WEP, just an open AP, keep it simple). Allow only DNS queries from anyone. Set up either a proxy or use a packet rewriting algorithm (like the "forward" command in FreeBSD's ipfw firewall) to redirect all outbound web traffic from source IPs/MACs (remember not to use NAT on the AP, you need the unique addresses, or use MAC addresses [better] if the firewall/proxy is the AP) that are not in a valid table or list (like one table for each hour, half hour, etc, I'm using table because that would follow with a FreeBSD ipfw2 firewall). Drop packets for any ports other than 80 (and 53, of course) for any host not in the valid list. Redirect them to a server that serves up the same single page for any requested page (they could have specified a path other than "/"). This single page should redirect them to your authentication server (this will most likely all be on the firewall, just an aliased IP that answers anything for the first page).
The authentication server gets some sort of confirmation number from the user. (printed on the reciept, insert your own clever algorithm for unique, difficult-to-guess numbers here [even better if the time can be determined by the number, or if the numbers are saved to a database somewhere]). Using the (valid) confirmation number from the receipt, the firewall/proxy adds the source IP or MAC to the valid source address table, and if you want to be really nice, you could have passed the original requested url through from the initial page that redirected them to the authentication site, and now redirect them to that page.
Set up a cron script to clean out the tables for tickets that have expired (this is why it would be easier to have your tables named for the time they expire), and you're done. Once a source IP or MAC is removed from the table, all further traffic will send them back to your authentication page, which can inform them that purchases are required for access, and the cycle can repeat. It would be best to use the firewall as the access point (put in a wireless card that is capable of being an AP), so that you can use MAC addresses to filter, and avoid the possibility that someone could leave while they have time left and have another person get the same IP, but as a minimum, you should do the DHCP from the firewall, and must do NAT from the firewall for outbound (validated) connections.
But you missed the point, partially. Rewriting a product in a new language from existing code costs very little, and rewriting from the design document (you DO have an accurate design document, right?), also costs very little, and will probably create a better final product (depending on the quality of the design document). Transposing code from one language to another simply requires a person or team of people that are familiar with both languages (which for VB and VB.NET won't be difficult, or expensive. VB/VB.NET developers are cheap, for a transition like this, freshman comp sci students will probably do, at $10-$15/hr). Creating a project from a final, up-to-date design document requires fewer people, and they only need to be familiar with the target language and your design standards. (Maybe sophomore/junior CS students, but fewer man-hours of them). The design phase of your project should be the most expensive, if it's not, you didn't do it correctly. Once the design is complete, implementation and testing are cheap.
Why not just use Outlook Web Access from Exchange? Then you get your calendar, too (which is really the only reason left to use Exchange)
Yeah, the major problem we have though is that our particular class A SprintLink subnet is pretty dirty, so I probably see a larger than usual number of attacks from worms with subnet affinities, like Blaster, Slammer, etc. I used to log them all, but it just got so rediculous that I couldn't even read the logs for important information. About the only things I look for on a regular basis are odd UDP attacks and access to critical public servers (which we do anyways to know exactly where our employees are when they check in, you'd be amazed how many clock in for their first stop at a location 50 miles away). Everything else is blocked, with the backend stuff all on a separate physical circuit.
Partially true. Some components of IE run in user mode, but IE uses several kernel mode parts, for doing things like installing plugins or browser helper objects, modifying registry entries, and doing abstract syntax notation (ASN.1) parsing. Sort of like running an application in Linux in user mode, as a user that has the ability to use sudo. It's a false sense of security to say it runs in user mode, because while that's true, the only real difference is that one will happily run 'rm -rf /*', and the other will need 'sudo rm -rf /*'. Browsers probably should be jailed, but I'm not aware of any that do this (could easily be done in Un*x though).
Just to clarify further, sendmail in 4.x works out of the box for me, 5.3 does not, from base or from ports.
Running that on the few 5.3 systems I've had will put the mail in the send queue, sure, but it won't send it. Once you tailor the configs, it will work, but out of the box your mail just sits there in the queue until it expires. It's partially the config, and partially a bug (ahem, I mean "feature"), but it won't send. It may work if the machine is the MX for the recipient domain, haven't tried that (I would assume it would work), but it won't work if it's not, the sendmail with 5.3 has some nasty DNS issues (It will find the name of the MX for the domain, but won't resolve it).
I never did solve that issue, since I didn't need sendmail on any of the machines, so I found ssmtp.