Re:Electronic Health Records is very hard
on
IT and Health Care
·
· Score: 3, Interesting
It means you don't get to see the physician twice, and learn about each other so they can tell when you're lying and you can tell when they're full of horse pucks. And it means that you can't organize your visits to arrange for expensive, long-term treatments for those chronic conditions like sleeplessness, work-related stress and RSI, diet and lifestyle changes. It's also a way to avoid providing mental care, which is very dependent on generating trust and non-verbal communication between a therapist and a patient.
Not much. It's computationally expensive to scan for blacklist based email, accept the deluges of it, and then process it. A small shop might not have the spare horsepower to do sophisticated processing, which takes some knowledge and some negotiation with your clients about how much to block accidentally versus how much to allow.
So SORBS' demise may slow some filtering that previously blocked it at the IP address. But there are at least half a dozen, more legitimate, less offensively capricious blackhole lists that will easily fill the void.
The ability to provide Linux FUD. It's helped them stay funded so far, if you follow the "Microsoft Partnership" sponsorship that kept them alive, and their interference with IBM and Novell and RedHat have been significant.
They aren't producing new usable products, and their old market niche of rock-solid x86 server class UNIX systems has evaporated in the face of Linux and other, more technically progressive and less lawsuit driven companies.
"The C Programming Language" by Kernighan & Richie. Every UNIX and Linux kernel is written in C, not C++: it's a great way to learn how things work with the simpler tools, and avoid the arcane interactions of C++ for your early work.
I don't have similar recommendations for Java or Perl, but would like to hear those of others.
Please do _say_ that you're referring to entry level work, then. I can see some related phenomona to what you describe, but I may be blessed in working among a whole bunch of really intense and creative people, who need to be intense and motivated to do what they do, and we recruit accordingly, and they already have some breadth or we wouldn't hire them. We don't do entry level work, except occasionally to make sure a project is completed on time or properly.
Many managers are very poor about getting that big picture to their staff, and I'll agree that Americans expect to know about the big picture in a way that other countries' engineers do not. I just spent a fascinating half hour with a data center in Asia, trying to get past the claims of their help desk to discuss with the real engineer whether the network problem was one issue, or the other, so that we'd know which solution to apply. They kept insisting that there was no such problem, but obviously had no actual knowledge with which to verify it: I'd left the "script" with which they did their jobs. It drove me _nuts_ to spin my wheels that way.
I don't know where you're working. Such poor work habits have only been the case in one environment I've ever seen, out of many my own job history and the many partners I've worked with, where the manager had frightened and alienated all the staff and they were all job hunting. (All 5 of those engineers resigned within one week of each other: it was frightening to see as a corporate partner, but I gave 2 of them recommendations because they were _good_ at dealing with that mess beyond what I would have tolerated.) One of the reasons those engineers balked was because not only was the product "not perfect" it was demonstrably broken due to the excess "features" added by the manager that were not part of the core requirements, and it simply would not work.
American workers are more willing to question authority. It drives authority nuts, and I've had it happen with international scenarios, where I struggled to be allowed to speak directly with the actual engineers so we could resolve the confusion about the most effective approach. We also loathe the telephone tag of sending our question to a call center or a manager, who rewrite and re-interpret it, then having them talk to a technician, who re-interprets it, and eventually gets to an engineer who wonders why we want to gogo-fratz with the banana puddijng, but does their best to send back an answer. We Americans try to sneak past those layers of management and bureaucracy to find the person who actually knows, and trade notes. (I do, anyway, and try to send them my patches.)
No. One isn't. One is a competent beginning computer scientist. It's a wonderful book for teaching theory and how things really work, but it teaches truly _execrable_ techniques of excessive self reference, excessive and unnecessary recursion, and tail-chasing "elegance" that turn into computational nightmares in the real world. Its models of "levels of abstraction" often contribute to horrible, horrible results in the real world because it actively discourages proper negotiation of the interfaces between the levels.
My anger with that book is based on both reading it and on being old enough to remember when LISP was considered so exciting, and having to clean up after professional colleagues who thought its top down approaches were the right approach everywhere. They're almost as bad as those people who point to "The Cloud" and say "and all our processing occurs out there".
It's spraying little unselectable boxes all over my screen. If you have to use a stylesheet, you're usually doing it wrong. If you have to use Javascript for a pure text based website like Slashdot, you are _definitely_ doing it wrong: it destabilizes your display and multiplies the testing and development cost ridiculously.
LARP's are fun and social, but they can seriously distort your social interactions for the rest of the world (such as meeting girls, of whom there remain very few).
Volunteer work, however, with your local Red Cross, animal shelters, and soup kitchens can't be beat for meeting different _kinds_ of people than just us geeks. They can use your help if you're willing to do the work, and even if you're not making friends as fast as you like, you can feel good about what you're doing for others.
> Clean CentOS 5.2 installs should be made, and the duties transferred to the virtual machine, long before remotely considering porting an ancient RHEL release to a VM.
Oh, my. Oh, dear. You haven't actually tried this much, have you? Rebuilding ancient source code in a modern compiler is difficult enough, due to changes in POSIX over the last 10 years. Capturing their ancient build environment with which someone careless and without tools like "mock" or good build management compiled the code is worse, which makes resolving the dependencies a nightmare. _Finding_ the original source code, or the version used to compile it, its own nightmare: not everyone is good about using CVS or submitting all their changes or keeping the trunk of their source code repository clean. Couple this with fundamental changes in glibc, kernels, databases such as MySQL and Berkeley DB and SQLite, the switch from XFree86 to Xorg, etc.. And then there's the Perl modules. Do you really want to have to backport to old versions of modules for compatibility use, written by people who aren't available anymore? You pontentially multiply the amount of work by a factor of 10 or 20 having to resolve each of these differences, _if you even have the source code_ and _if you have the time to verify that it works _correctly_. That is a stunning waste of engineering time for obsolete or discarded projects which have to be preserved for legal or legacy data access reasons. A clean redesign from scratch is often a good idea, but that means you may not have access to your old data with the new tools. The upgrade tools automatically used with Berkeley DB upgrades, MySQL upgrades, etc. can reveal old bugs which no one can reliably repair without years of development effort and which didn't show up before in use with the old system.
I agree about kernel performance issues, but given that the underlying hardware is often 4 times as fast as the old hardware the old OS was originally running on, and the virtual machine takes a performance hit but should be lightly loaded because it's just for legacy access, it's normally an acceptable performance hit. And it's _cheap_ to run a lightly loaded virtual system.
Also note: I didn't restrict myself to RHEL. I've done this and helped provide resources to do this with OS's all the way back to RedHat 7.1 and several BSD UNIX's, and that kind of code porting is a lot of work. It's why I urge people to have a good general toolchain, like good source control with the actual working code in a clean tag with all the necessary build tools, using GNU autoconf and gcc and GNU make and tar rather than more sophisticated but less stable IDE based systems, keeping their documentation in text files rather than Wiki's, etc.
I agree that virtual machines are wonderful, especially for older, low-usage applications that don't need modern iron to run on, and especially for legacy applications and legacy environments. But if I see one more "Installing VMware Tools" status running for 3 days on the same virtual instance, or another unpatched RHEL security hole in what is essentially a 6 year old RHEL operating system stuffed into a managed environment, and with no RHEL license provided so you don't even get security notices about vulnerabilities in SSH or any other services nor the ability to install usable monitoring tools without grabbing the critical components from a registered ancient RHEL machine or a CentOS repository, I'll need, I'll need, I'll need.
Oh dear. Language escapes me. I've had to run a number of those recently, and it's awkward. I much prefer what RHEL did with Xen, incorporating it into the basic OS and providing good para-virtualization support with a much lighter weight, usable interface and licensing that included numerous virtual instances running on any registered RHEL server.
The owners know that the buyers can put them out of business through changing policies, now that they're interested in the market, by expanding their existing product line slightly, for only slightly more than the cost of buying them out. This has happened repeatedly.
I've been that random employee, several times. It's difficult and painful, and it's often career death to be the one person who can maintain the old system: it interfers with being allowed to work on forward looking projects, and can make you layoff fodder.
Much of such expenses are due to "savings" by refusing to update earlier. Like replacing your teeth with dentures instead of brushing nightly, the refusal to do software or system updates can be far more expensive and disabling than a campaign of small, regular updates. We're about to see a big set of Windows based companies run headlong into this as they jump from Windows XP (which should have been called NT 5) to Windows 7 (which they at least numbered correctly). You can sometimes wisely skip an entire OS, but for a 30 year old code base, I expect some serious record keeping and structural problems.
Really? Sounds cool. That kind of thing can be difficult to test. I remember the last time I reviewed one, explaining the details of the DHCP questions to them and how their answers did not apply to their older but still commercially supported versions of DHCP. So yes, they've used such texts.
I can vouch for this. I've had an absolute blast taking a few work-paid courses. Learning a new language or new skills on out-of-date, familiar equipment was especially fun when the TA and I took apart some of his equipment and I pointed out where the historically bad solder joints on that unit were. (They would eventually fail under power cycling and thermal expansion: the pads were too small to carry that much power supply current.) This fixed the "we don't dare turn it off" problem. It didn't get me an A, but it helped my grade.
Oh, my. RedHat's training is good, although about 1/3 of the tests run to the "petty RedHat buzzword standard answer", as if someone from an MCSE program wrote them, and another 1/6 run to the "their expected answer is, in fact, incorrect, but you have to know of some odd circumstances in which it doesn't apply and it's fun to hand in a separate sheet with the corrections to their answers".
The remaining half of the tested answers are pretty good material. And that's frankly excellent compared to the absolute nonsense in Microsoft Certifed tests.
Oh. You're in the _UK_. Learn Linux: my professional colleague in London is having to beat off recruiters, even in this economy, and they keep trying to hire him for work in Scotland and Geneva as well. The support and systems administration roles available to a someone who can work in a mixed Linux/Windows, or Linux/Windows/Mac environment, are very active as companies try to stretch their finances for new servers and services.
School is great for your resume: but so is experience with fields that are growing and likely to remain in demand.
I see 3 routes: which you choose depends on your style.
* Management - learn to manage a call center, if you like being a manager. Take courses, organize your group, get noticed as a leader, and be ready to jump to another company that hears how well you handle their calls and tries to hire you. It happens to me as a third tier support person all the time. * Document your way out of the mess. Many calls are easily scriptable, and could be walked through by a trained monkey. Learn to write those scripts well. This is a very salable skill, in your company for escalation when the market improves, but it requires real hands-on with the people who do your current job. Review good documentation for guidelines. FAQ's like the Subversion FAQ and book are pretty good, and some well-organized people do very well with Wikis. * Develop an invaluable work-related hobby. Sourceforge is a great place for this, and so are public Wikis. I've got old projects that I contributed to over a decade ago and live over on Slashdot that still get me occasional recruiting calls, or really boost my value in job reviews (and the very rare interview because I hate switching work but things happen). There's nothing quite so helpful as getting an interview question on a subject and saying "Oh, dear. That relates to this work I did on this old environment: look up my name and that subject on Google for pages more than 3 years old.". But having your name in the general discussion groups, or especially making intelligent comments in the developer groups, can pay off down the line.
What you pursue is your own choice: I've seen each of those approaches work. As a Slashdot cranky person and self-avowed technical expert, I prefer the Sourceforge approach.
And you say this because avast doesn't report anything? I'm looking at the Norton report below, which seems prety indicative of precisely the drive-by downloads Norton is reporting.
Thank you, Xiteron, for noticing my careful language. It's been decades since college for me, but I don't remember seeing it in _any_ of the advertising literature nor in the house tours to attract new brothers. I was very careful _not_ to say that it was secret, partly because it wasn't, and partly because it wasn't considered a violation of the school's ethical or legal guidelines.
I'm afraid they don't work as well in the rain. Traction on wet pavement is much trickier on a bike, as are the pitfalls of puddles with debris in them, and the loss of visibility for the bike driver and for cars who need to see bikes add a lot to their danger.
FIRST POST!! Oh, dear, you must have all had a good Friday night.
There's an old practice of fraternities at my college, where they kept file cabinets filled with old homework and course notes of all the classes their members took. I had wondered how some frat boys coasted through so many classes and got so much more sleep than those of us who struggled working to pay for college, paying for food, etc. Then I found out this was one of their most important reasons. It was a known practice, and one of the less publicly mentioned benefits of joining a fraternity.
Since small-scale publication of old hoomework and course notes, such as what I describe above, has been going on for centuries, it seems completely reasonable that larger scale publication be permitted.
The link in the Slashdot abstract, to http://ostatic.com/ causes Norton Security to throw a fit about no fewer than _164_ drive-by downloads on that site.
What an unfriendly link to provide. Serves me right for attempting to actually read the article.
Right: that's the one they had to create because they violated their charter by being Windows only for the original, Bittorrent-like design, the one that sucked so badly.
However, I'm sure the "we will suck your bandwidth like a very, very large tick on your carotid" clause is way, way down about paragraph 37 of the end user agreement for the "download" version of Iplayer.
It's a bit silly: for scalable, cheap, replaceable systems, it makes sense, especially by putting the IO in the front for both systems that are in that box. And it avoids some of the single point of failure and high add-on expenses of blade servers, especially the cost of the multiple internal switches and remote KVM capabilities. (Has anyone else run into the "turn off spashimage in grub" problem to get access to the serial port boot console? That is a royal pain.)
But I'm concerned that people will install both of their "high availability" servers inside their skinless server, not realize this is what their upstream site did, and be screwed when it loses power. And power supplies _do_ fail.
Slashdot Mirror
It means you don't get to see the physician twice, and learn about each other so they can tell when you're lying and you can tell when they're full of horse pucks. And it means that you can't organize your visits to arrange for expensive, long-term treatments for those chronic conditions like sleeplessness, work-related stress and RSI, diet and lifestyle changes. It's also a way to avoid providing mental care, which is very dependent on generating trust and non-verbal communication between a therapist and a patient.
Not much. It's computationally expensive to scan for blacklist based email, accept the deluges of it, and then process it. A small shop might not have the spare horsepower to do sophisticated processing, which takes some knowledge and some negotiation with your clients about how much to block accidentally versus how much to allow.
So SORBS' demise may slow some filtering that previously blocked it at the IP address. But there are at least half a dozen, more legitimate, less offensively capricious blackhole lists that will easily fill the void.
The ability to provide Linux FUD. It's helped them stay funded so far, if you follow the "Microsoft Partnership" sponsorship that kept them alive, and their interference with IBM and Novell and RedHat have been significant.
They aren't producing new usable products, and their old market niche of rock-solid x86 server class UNIX systems has evaporated in the face of Linux and other, more technically progressive and less lawsuit driven companies.
"The C Programming Language" by Kernighan & Richie. Every UNIX and Linux kernel is written in C, not C++: it's a great way to learn how things work with the simpler tools, and avoid the arcane interactions of C++ for your early work. I don't have similar recommendations for Java or Perl, but would like to hear those of others.
Please do _say_ that you're referring to entry level work, then. I can see some related phenomona to what you describe, but I may be blessed in working among a whole bunch of really intense and creative people, who need to be intense and motivated to do what they do, and we recruit accordingly, and they already have some breadth or we wouldn't hire them. We don't do entry level work, except occasionally to make sure a project is completed on time or properly.
Many managers are very poor about getting that big picture to their staff, and I'll agree that Americans expect to know about the big picture in a way that other countries' engineers do not. I just spent a fascinating half hour with a data center in Asia, trying to get past the claims of their help desk to discuss with the real engineer whether the network problem was one issue, or the other, so that we'd know which solution to apply. They kept insisting that there was no such problem, but obviously had no actual knowledge with which to verify it: I'd left the "script" with which they did their jobs. It drove me _nuts_ to spin my wheels that way.
I don't know where you're working. Such poor work habits have only been the case in one environment I've ever seen, out of many my own job history and the many partners I've worked with, where the manager had frightened and alienated all the staff and they were all job hunting. (All 5 of those engineers resigned within one week of each other: it was frightening to see as a corporate partner, but I gave 2 of them recommendations because they were _good_ at dealing with that mess beyond what I would have tolerated.) One of the reasons those engineers balked was because not only was the product "not perfect" it was demonstrably broken due to the excess "features" added by the manager that were not part of the core requirements, and it simply would not work.
American workers are more willing to question authority. It drives authority nuts, and I've had it happen with international scenarios, where I struggled to be allowed to speak directly with the actual engineers so we could resolve the confusion about the most effective approach. We also loathe the telephone tag of sending our question to a call center or a manager, who rewrite and re-interpret it, then having them talk to a technician, who re-interprets it, and eventually gets to an engineer who wonders why we want to gogo-fratz with the banana puddijng, but does their best to send back an answer. We Americans try to sneak past those layers of management and bureaucracy to find the person who actually knows, and trade notes. (I do, anyway, and try to send them my patches.)
No. One isn't. One is a competent beginning computer scientist. It's a wonderful book for teaching theory and how things really work, but it teaches truly _execrable_ techniques of excessive self reference, excessive and unnecessary recursion, and tail-chasing "elegance" that turn into computational nightmares in the real world. Its models of "levels of abstraction" often contribute to horrible, horrible results in the real world because it actively discourages proper negotiation of the interfaces between the levels.
My anger with that book is based on both reading it and on being old enough to remember when LISP was considered so exciting, and having to clean up after professional colleagues who thought its top down approaches were the right approach everywhere. They're almost as bad as those people who point to "The Cloud" and say "and all our processing occurs out there".
It's spraying little unselectable boxes all over my screen. If you have to use a stylesheet, you're usually doing it wrong. If you have to use Javascript for a pure text based website like Slashdot, you are _definitely_ doing it wrong: it destabilizes your display and multiplies the testing and development cost ridiculously.
LARP's are fun and social, but they can seriously distort your social interactions for the rest of the world (such as meeting girls, of whom there remain very few).
Volunteer work, however, with your local Red Cross, animal shelters, and soup kitchens can't be beat for meeting different _kinds_ of people than just us geeks. They can use your help if you're willing to do the work, and even if you're not making friends as fast as you like, you can feel good about what you're doing for others.
> Clean CentOS 5.2 installs should be made, and the duties transferred to the virtual machine, long before remotely considering porting an ancient RHEL release to a VM.
Oh, my. Oh, dear. You haven't actually tried this much, have you? Rebuilding ancient source code in a modern compiler is difficult enough, due to changes in POSIX over the last 10 years. Capturing their ancient build environment with which someone careless and without tools like "mock" or good build management compiled the code is worse, which makes resolving the dependencies a nightmare. _Finding_ the original source code, or the version used to compile it, its own nightmare: not everyone is good about using CVS or submitting all their changes or keeping the trunk of their source code repository clean. Couple this with fundamental changes in glibc, kernels, databases such as MySQL and Berkeley DB and SQLite, the switch from XFree86 to Xorg, etc.. And then there's the Perl modules. Do you really want to have to backport to old versions of modules for compatibility use, written by people who aren't available anymore? You pontentially multiply the amount of work by a factor of 10 or 20 having to resolve each of these differences, _if you even have the source code_ and _if you have the time to verify that it works _correctly_. That is a stunning waste of engineering time for obsolete or discarded projects which have to be preserved for legal or legacy data access reasons. A clean redesign from scratch is often a good idea, but that means you may not have access to your old data with the new tools. The upgrade tools automatically used with Berkeley DB upgrades, MySQL upgrades, etc. can reveal old bugs which no one can reliably repair without years of development effort and which didn't show up before in use with the old system.
I agree about kernel performance issues, but given that the underlying hardware is often 4 times as fast as the old hardware the old OS was originally running on, and the virtual machine takes a performance hit but should be lightly loaded because it's just for legacy access, it's normally an acceptable performance hit. And it's _cheap_ to run a lightly loaded virtual system.
Also note: I didn't restrict myself to RHEL. I've done this and helped provide resources to do this with OS's all the way back to RedHat 7.1 and several BSD UNIX's, and that kind of code porting is a lot of work. It's why I urge people to have a good general toolchain, like good source control with the actual working code in a clean tag with all the necessary build tools, using GNU autoconf and gcc and GNU make and tar rather than more sophisticated but less stable IDE based systems, keeping their documentation in text files rather than Wiki's, etc.
I agree that virtual machines are wonderful, especially for older, low-usage applications that don't need modern iron to run on, and especially for legacy applications and legacy environments. But if I see one more "Installing VMware Tools" status running for 3 days on the same virtual instance, or another unpatched RHEL security hole in what is essentially a 6 year old RHEL operating system stuffed into a managed environment, and with no RHEL license provided so you don't even get security notices about vulnerabilities in SSH or any other services nor the ability to install usable monitoring tools without grabbing the critical components from a registered ancient RHEL machine or a CentOS repository, I'll need, I'll need, I'll need.
Oh dear. Language escapes me. I've had to run a number of those recently, and it's awkward. I much prefer what RHEL did with Xen, incorporating it into the basic OS and providing good para-virtualization support with a much lighter weight, usable interface and licensing that included numerous virtual instances running on any registered RHEL server.
The owners know that the buyers can put them out of business through changing policies, now that they're interested in the market, by expanding their existing product line slightly, for only slightly more than the cost of buying them out. This has happened repeatedly.
I've been that random employee, several times. It's difficult and painful, and it's often career death to be the one person who can maintain the old system: it interfers with being allowed to work on forward looking projects, and can make you layoff fodder.
Much of such expenses are due to "savings" by refusing to update earlier. Like replacing your teeth with dentures instead of brushing nightly, the refusal to do software or system updates can be far more expensive and disabling than a campaign of small, regular updates. We're about to see a big set of Windows based companies run headlong into this as they jump from Windows XP (which should have been called NT 5) to Windows 7 (which they at least numbered correctly). You can sometimes wisely skip an entire OS, but for a 30 year old code base, I expect some serious record keeping and structural problems.
Really? Sounds cool. That kind of thing can be difficult to test. I remember the last time I reviewed one, explaining the details of the DHCP questions to them and how their answers did not apply to their older but still commercially supported versions of DHCP. So yes, they've used such texts.
I can vouch for this. I've had an absolute blast taking a few work-paid courses. Learning a new language or new skills on out-of-date, familiar equipment was especially fun when the TA and I took apart some of his equipment and I pointed out where the historically bad solder joints on that unit were. (They would eventually fail under power cycling and thermal expansion: the pads were too small to carry that much power supply current.) This fixed the "we don't dare turn it off" problem. It didn't get me an A, but it helped my grade.
Oh, my. RedHat's training is good, although about 1/3 of the tests run to the "petty RedHat buzzword standard answer", as if someone from an MCSE program wrote them, and another 1/6 run to the "their expected answer is, in fact, incorrect, but you have to know of some odd circumstances in which it doesn't apply and it's fun to hand in a separate sheet with the corrections to their answers".
The remaining half of the tested answers are pretty good material. And that's frankly excellent compared to the absolute nonsense in Microsoft Certifed tests.
Oh. You're in the _UK_. Learn Linux: my professional colleague in London is having to beat off recruiters, even in this economy, and they keep trying to hire him for work in Scotland and Geneva as well. The support and systems administration roles available to a someone who can work in a mixed Linux/Windows, or Linux/Windows/Mac environment, are very active as companies try to stretch their finances for new servers and services.
School is great for your resume: but so is experience with fields that are growing and likely to remain in demand.
I see 3 routes: which you choose depends on your style.
* Management - learn to manage a call center, if you like being a manager. Take courses, organize your group, get noticed as a leader, and be ready to jump to another company that hears how well you handle their calls and tries to hire you. It happens to me as a third tier support person all the time.
* Document your way out of the mess. Many calls are easily scriptable, and could be walked through by a trained monkey. Learn to write those scripts well. This is a very salable skill, in your company for escalation when the market improves, but it requires real hands-on with the people who do your current job. Review good documentation for guidelines. FAQ's like the Subversion FAQ and book are pretty good, and some well-organized people do very well with Wikis.
* Develop an invaluable work-related hobby. Sourceforge is a great place for this, and so are public Wikis. I've got old projects that I contributed to over a decade ago and live over on Slashdot that still get me occasional recruiting calls, or really boost my value in job reviews (and the very rare interview because I hate switching work but things happen). There's nothing quite so helpful as getting an interview question on a subject and saying "Oh, dear. That relates to this work I did on this old environment: look up my name and that subject on Google for pages more than 3 years old.". But having your name in the general discussion groups, or especially making intelligent comments in the developer groups, can pay off down the line.
What you pursue is your own choice: I've seen each of those approaches work. As a Slashdot cranky person and self-avowed technical expert, I prefer the Sourceforge approach.
And you say this because avast doesn't report anything? I'm looking at the Norton report below, which seems prety indicative of precisely the drive-by downloads Norton is reporting.
Drive-By Downloads (what's this?)
Threats found: 165
Here is a sample:
Threat Name: Process Started
Process name: C:\WINDOWS\system32\cmd.exe
Location: http://ostatic.com/user?destination=feedback
Threat Name: Process Started
Process name: C:\WINDOWS\system32\cmd.exe
Location: http://ostatic.com/searchtag/Linux2/project/1/Alternative/limewire
Threat Name: Process Started
Process name: C:\WINDOWS\system32\cmd.exe
Location: http://ostatic.com/user?destination=gta2%2Fhome%2F1%2Falltopics
Threat Name: Process Started
Process name: C:\WINDOWS\system32\cmd.exe
Location: http://ostatic.com/searchtag/Linux2/project/1/Alternative/winamp
Threat Name: Process Started
Process name: C:\WINDOWS\system32\cmd.exe
Location: http://ostatic.com/searchtag/all/story/1/Tag/mozilla
Threat Name: Process Started
Process name: C:\WINDOWS\system32\cmd.exe
Location: http://ostatic.com/searchtag/all/story/1/Username/Joe+Brockmeier
Threat Name: Process Started
Process name: C:\WINDOWS\system32\cmd.exe
Location: http://ostatic.com/searchtag/ettercap/users
Threat Name: Direct link to Process Started
Location: http://ostatic.com/gta2/home/1/alltopics/
Threat Name: Direct link to Process Started
Location: http://ostatic.com/feedback
Threat Name: Direct link to Process Started
Location: http://ostatic.com/searchtag/all/story
Thank you, Xiteron, for noticing my careful language. It's been decades since college for me, but I don't remember seeing it in _any_ of the advertising literature nor in the house tours to attract new brothers. I was very careful _not_ to say that it was secret, partly because it wasn't, and partly because it wasn't considered a violation of the school's ethical or legal guidelines.
I'm afraid they don't work as well in the rain. Traction on wet pavement is much trickier on a bike, as are the pitfalls of puddles with debris in them, and the loss of visibility for the bike driver and for cars who need to see bikes add a lot to their danger.
FIRST POST!! Oh, dear, you must have all had a good Friday night.
There's an old practice of fraternities at my college, where they kept file cabinets filled with old homework and course notes of all the classes their members took. I had wondered how some frat boys coasted through so many classes and got so much more sleep than those of us who struggled working to pay for college, paying for food, etc. Then I found out this was one of their most important reasons. It was a known practice, and one of the less publicly mentioned benefits of joining a fraternity.
Since small-scale publication of old hoomework and course notes, such as what I describe above, has been going on for centuries, it seems completely reasonable that larger scale publication be permitted.
The link in the Slashdot abstract, to http://ostatic.com/ causes Norton Security to throw a fit about no fewer than _164_ drive-by downloads on that site. What an unfriendly link to provide. Serves me right for attempting to actually read the article.
Right: that's the one they had to create because they violated their charter by being Windows only for the original, Bittorrent-like design, the one that sucked so badly.
However, I'm sure the "we will suck your bandwidth like a very, very large tick on your carotid" clause is way, way down about paragraph 37 of the end user agreement for the "download" version of Iplayer.
It's a bit silly: for scalable, cheap, replaceable systems, it makes sense, especially by putting the IO in the front for both systems that are in that box. And it avoids some of the single point of failure and high add-on expenses of blade servers, especially the cost of the multiple internal switches and remote KVM capabilities. (Has anyone else run into the "turn off spashimage in grub" problem to get access to the serial port boot console? That is a royal pain.)
But I'm concerned that people will install both of their "high availability" servers inside their skinless server, not realize this is what their upstream site did, and be screwed when it loses power. And power supplies _do_ fail.