As I was describing in a side thread, there's a problem of versioning and feature creap. Mono/.Net 2.0 is becoming a pretty solid cross-platform development environment..Net 3.5 is a different story, since there are still API namespaces that need to be ported to Mono. But if you confine yourself to Mono/.Net 2.0, it's becoming pretty darn good.
Exactly. It's particularly useful for those of us who want to port our.Net code library away from Microsoft tools. Having worked in an MS environment for many years, I have tens of thousands of lines of code in various utilities and research projects that I've written in.Net. A few years back, I made the switch to Mac/Linux, and would like to never touch a Windows machine again, if possible. But I still want my code library available. So, this tool works perfectly for my needs. I made a wise decision many years ago to limit my develop to.Net 2.0 libraries only. Because I've exercised self-control in my coding practices, my.Net 2.0 code is now pretty much cross-platform, now that Mono has pretty much implemented the entire 2.0 specifications. And with MonoDevelop, I now have a mostly full featured-replacements for Visual Studio (I'm really only concerned with line numbering, code formatting, intellisense, refactoring, and nUnit testing in my IDE). So, as far as I'm concerned, and I can do cross-platform Mono development on Linux/Mac from here on out.
Of course, if you're trying to write.Net 3.5 or 4.0 code, there will be features not implemented yet, and it will be a pain. But it's great for 2.0 development.
I can assure you that Machiavelli's Discourses on Levi's History of Ancient Rome are a far better account of how to run a republic. All of Obama's actions so far indicate that he's taking his advice from the Discourses, not the Prince.
These reports come out every few years (re: DDT, et al.), and while they're not strictly incorrect, they tend to look at a very incomplete picture of what is going on. To be perfectly blunt, there's sexism going on in that these reports focus on just the environmental impact of chemicals on boys, and don't consider the larger picture of chemical impact on children in general.
Anyhow, if you take a look at the steroidgenesis diagram, you'll notice that testosterone is a precursor of oestrogen by way of aromatase:
Now, for those people who remember their organic chemistry and stoichiometry, rates of conversion reactions are increased with catalysts, and decreased with modulators. So, while aromatase will increase the rate at which testosterone converts into estrogen, an aromatase inhibitor will decrease conversion of testosterone.
So, simply put... what about the environmental chemicals that are masculinizing girls? Is it really just a matter of plastics feminizing boys? Or does it go both ways? Is it a matter of environmental toxicity in general?
Lastly, I'd also bring up the question whether feminization of boys is primarily caused by environmental chemicals, or if it's driven be completely different factors, such as 1) a cultural response to civil rights access for women, 2) decreased opportunities for war caused by nuclear detante, or 3) need for peaceful co-existance due to worldwide population increases a
Rather than responding with name calling, why don't you grow a few neurons and provide an actual counter argument and explain why you don't agree with the GP? Simply calling another post juvenile, with no supporting argument, is trollish.
A better plan would be to create a legislative chamber who's sole responsibility is the repeal of laws. So, the legislative branch would be composed of three chambers: Senate, House of Legislation, and House of Repeals. Or something like that. That would create a better system of checks and balances.
That's one way of looking at it. Another way of looking at it is that we've discovered that segregating an application with it's own operating system is the easiest and most cost effective way of adding standards compliant network, cryptography, and database structures to an application. From the application development perspective, it makes far more sense to bundle an operating system with my application to provide network, crypto, and database functionality, than for me to try to roll my own. I like to think I'm a good programmer, but I'm not *that* good. It turns out that assigning IP addresses and names to applications makes a lot of sense. If you're interested in web services, it's the way to go. So, rather than roll it from scratch, just bundle an OS with the app.
I agree that deduplication is an issue; but in 20/20 highsight, I think we've discovered that application segregation has a lot more benefits than just improved stability.
True. I agree with everything you've said. But if you're doing Agile Development on a web application stack or some other type of complex system, and doing constant deployment, being able to fork the production system is invaluable. What you've written is perfectly accurate for software applications development in the traditional application sense. But it doesn't apply quite so well if one's focus is on systems development. If your coding mostly involves things like installing operating system modules, triggering operating hooks, writing startup scripts, script munching, screen-scraping, and writing to database tables for dynamic page generation... well, that kind of coding and systems design needs something a bit more robust. Something that can save the entire system configuration in one go.
Server automation is an elegant way to do things, no doubt. I find that the machines they build never quite seem to the same though. Repositories get updated, driver versions get updated, different servers have slightly different hardware and driver requirements, and there's often little differences between builds. And that causes configuration drift over time.
Plus, once the machine is in production and real time data is being processed through the database adn application... all bets are off on rebuilding it with server automation. But a VM snapshot of that machine can be used to create an identical copy of that database at that particular point in time.
But hardware overhead is the entire point. Folks who aren't using virtualization tie down their critical applications to individual pieces of hardware that those applications are installed upon. If a disk or chip goes bad, then so does the database and the webserver. If someone forgets to pay a hosting bill, 6 months of web design... gone. If a huricane blows through and floods your datacenter, your apps... gone. All of these disasters arise from the application being tied to the piece of hardware it's installed on.
When I was talking about application portability, I was referring to the idea that an application stack or service need not be tied down to a particular piece of hardware that it's being hosted on. My web servers don't sit on any particular physical machine. I'm not tied to a server, a data center, or a hosting company. I started off on a laptop, have been through four hosting services so far, and haven't had to rebuild my web applications a single time. If I get fed up with a hosting service, I can migrate inside of a couple hours. My production servers are portable and stable through migrations.
Well, yes. There's that. You're absolutely correct about how virtualization can provide all that, and I do all of that kind of application portability testing with my day job.
But in regards to my startup and portability, I was thinking of applications in the sense of web services running on LAMP virtual devices. I bounce my production virtual applications from machine to machine, hosting service to hosting service. I started off on a laptop, and have been through four hosting services so far, and haven't had to rebuild any of my website during the migrations.
When I was talking about application portability, I was referring to the idea that an application or service need not be tied down to a particular piece of hardware. My web servers don't sit on any particular physical machine. Folks who aren't using virtualization tie down their critical applications to individual pieces of hardware. If a disk or chip goes bad, then so does the database and the webserver. If someone forgets to pay a hosting bill, 6 months of web design... gone. Ever build a website and have your hosting company go out of business on you? Or have a server room flooded that you were hosting from? I've had all of these things happen to me over the past 15 years.
I've had it happen to me so many times that I eventually swore I'd never let it happen again. So, I converted all of my development and production systems to virtual machines. I won't work without them now days.
With virtual machines, I'm not locked into a particular hosting provider. I have a working disaster recovery plan. I have portability of my production application stacks. I can be re-hosted on a new hosting provider inside of 4 hours if I get irked by my current host. By creating an abstraction layer between the application and the hardware, I'm able to shuffle my virtual machines around from host to host, and not be affected by hardware failures, business discontinuity, or network outages.
Having been involved in a business start-up for a year or so now, I'd have to disagree. Virtualization is indispensible for QA testing. Being able to run a virtual network on a personal PC lets me design, debug, and do proof-of-concepts without requiring the investment in actual equipment.
Virtualization isn't just about hardware consolidation: it's also about application portability. Small companies have just as much need for QA testing, hardware recycling, and application portability as the large ones.
How the MRI scanner as a "big invention"? Just because a technology is profound, and is revolutionary, doesn't mean that it has to be a consumer commodity.
But if you do want consumer commodities, try the cell phone and the internet protocol.
Actually, we *are* growing synthetic organs although they're still expensive, we now have things like laser optical tweezers and MEMS, we generate electricity from incinerating garbage, we actually have solar panels power all sorts of public works (think emergency phones and deer-sensors on highways); oh, and we have the MRI scanner and the internet, and our robot dinosaurs are starting to work *real* good.
It's just that our technology advancements now come in the form of complex systems. An MRI has a gazillion parts and can't be stored at home, because it uses a superconducting cryomagnet. But it was made in the last 50 years, and has had a profound impact on life expectancy and our understanding of medicine.
We're currently in a period of systems consolidation and preparation for the next big tech paradigm. When it happens, we're going to have humanoid robots walking the streets; we'll have outpatient clinics where people can have synthetic organs grown; and we'll be powering things with a lot more solar/wind/biofuels.
Don't mistake the myths of advance technology for advance technology. The myths of anti-gravity and teleportation are simply human's desire to overcome physical limitations of the physical universe. But they don't necessarily have anything to do with where the tech advancements are actually occurring. The major tech advancements are occurring in biology and systems science nowdays; not in physics and chemistry.
Mod parent up informative. Having done neural MRI research, I think we'll be able to eventually resolve neurons and some of the axons and dendrites for structural MRI images. But the water diffusion limit is a serious issue for fMRI.
Two points: first, research MRI scanners are already routinely scanning at the molecular level. 9 Tesla magnets with 2" bores are routinely used to exam mouse brains at the molcular level. Problem is, they have small bores and are only good for scanning small things. Building a molecular grade scanner that you can fit an entire person into..... that's a bit more tricky.
Second, I think you're absolutely right about diff'ing issue. It creates a classic backup and synchronization problem, if the intent is to virtualize a living person and maintain a classic human experience of life. If, on the other hand, you're willing to fork your consciousness, and live more than one life, then it's a feature, rather than a flaw.
Having done neural MRI research at an ivy league neurology research institute, I'd point out that MRI scanners require higher field strength to get higher resolution; not higher energy, per se. The energy requirements for higher resolution are indirect, in that they're powering a cryomagnet; not being beamed into cellular tissue, as is the case with CT scanners. MRI scanners already get well into the cellular range with high field research magnets (9T magnets, for instance). And since a neuron is a type of cell, I would go so far as to say that getting a MRI magnet to do a 1:1 image at the neuronal synaptic level is really quite feasible. And that's with the same level of energy being beamed into cellular tissue as with current MRI magnets. The limiting factor in creating resolution with an MRI is magnetic field curvature per volumetric space.
As a bioinformaticist, I suspect your analysis may be backwards. We've sequenced the human genome. We have a handle on the genetics component. The difficulty will be in creating an embodied intelligence which can interact with people in the real world, rather than sit in a box in a data center somewhere. The vast bulk of our intelligence is directed at interacting with our environment and with others. If an artificial brain can't be put into a suitable body, it's going to distinctly un-human, in so far as it will lack many of the basic learned experiences that humans have... dealing with gravity, the process of eating and sleeping, interacting with other humans, etc....
Personally, I think that software consciousness will turn out to be quite easy in hindsight,
Agreed. It's going to be an 'everything-and-the-kitchen-sink' kind of problem. Put enough of the right systems together, and it will emerge rather on its own.
The problem isn't going to be creating an artificial intelligence. The problem is going to be in making it an autonomous agent that can be socially integrated into society. Think how long it takes to raise a kid... teaching the kid language, potty training, kindergarten, social skills, job skills, etc... You need to do all of that training with an AI... but it won't necessarily have a body it can move around in and interact with other people with. The first AIs are going to be alien to our experience, unless they're purpose built in android type shells.
I suspect that in 50 years, we'll look back and say 'oh, yeah... the first AIs were waking up 30 years ago, but it took us another 10 years to recognize them for what they were'.
'go forth and multiply' is simply religious speak for 'propagate the species' and 'survival', both of which are fairly standard concept in population biology. I agree with the GP that there is an overpopulation problem as it is; but be careful about conflating it with religious speak. The bible simply expresses in words the biological drive that humans experience every day. Religious wack-jobs aren't responsible for overpopulation because they follow 'go forth and multiply', nor is the religion itself. Overpopulation is just overpopulation. No need to blame the religions for it, or the people following said religions.
Did you know that Cerner has invested over a billion dollars in R&D and is considered by many to have one of the most integrated EMRs out there? It's one of the few systems that can match, feature for feature, what VistA offers.
Having worked as a Cerner analyst for the past 5 years, I can guarantee you that your problem is that you haven't hired enough on-site analysts and programmers to customize the Cerner applications to your on-site workflow. You're just working with the default settings, and haven't used their UI programming kits to develop custom workflows yet.
The problem with Cerner is that it's built on top of an Oracle database, and is simply a little *too* customizable. It can be very intimidating to approach, with literally thousands and thousands of database tables, and hundreds of applications. So, what happens, is that everybody avoids the work of customizing it. And it doesn't get done.
Because Americans have a mentality that they deserve "the best", which includes healthcare. Thus, they demand to take their sniffles and colds and other minor issues to medical doctors. We've systematically devalued any other medical practioner other than the doctor. Physician assistants, paramedics, licensed physicians without medical doctorates.... all of these medical professionals have been removed from the system.
For instance... did you know that in many states you can become a physician with just a Bachelor's of Arts? A physician license is all you need to have to practice medicine. It used to be that a doctorate only indicated that you had extra schooling. Back in the day, physicians without doctorates were common, especially out in the old west. Nowadays, most people can't even conceive of a physician without a doctorate. The military has vestiges of that old practice, though. You can become a medic and practice a much wider range of medicine without a doctoral degree than you can in civilian medicine.
Slashdot Mirror
As I was describing in a side thread, there's a problem of versioning and feature creap. Mono/.Net 2.0 is becoming a pretty solid cross-platform development environment. .Net 3.5 is a different story, since there are still API namespaces that need to be ported to Mono. But if you confine yourself to Mono/.Net 2.0, it's becoming pretty darn good.
Exactly. It's particularly useful for those of us who want to port our .Net code library away from Microsoft tools. Having worked in an MS environment for many years, I have tens of thousands of lines of code in various utilities and research projects that I've written in .Net. A few years back, I made the switch to Mac/Linux, and would like to never touch a Windows machine again, if possible. But I still want my code library available. So, this tool works perfectly for my needs. I made a wise decision many years ago to limit my develop to .Net 2.0 libraries only. Because I've exercised self-control in my coding practices, my .Net 2.0 code is now pretty much cross-platform, now that Mono has pretty much implemented the entire 2.0 specifications. And with MonoDevelop, I now have a mostly full featured-replacements for Visual Studio (I'm really only concerned with line numbering, code formatting, intellisense, refactoring, and nUnit testing in my IDE). So, as far as I'm concerned, and I can do cross-platform Mono development on Linux/Mac from here on out.
.Net 3.5 or 4.0 code, there will be features not implemented yet, and it will be a pain. But it's great for 2.0 development.
Of course, if you're trying to write
I can assure you that Machiavelli's Discourses on Levi's History of Ancient Rome are a far better account of how to run a republic. All of Obama's actions so far indicate that he's taking his advice from the Discourses, not the Prince.
ah... weird coincidence then... interesting to know where that meme came from though...
These reports come out every few years (re: DDT, et al.), and while they're not strictly incorrect, they tend to look at a very incomplete picture of what is going on. To be perfectly blunt, there's sexism going on in that these reports focus on just the environmental impact of chemicals on boys, and don't consider the larger picture of chemical impact on children in general.
Anyhow, if you take a look at the steroidgenesis diagram, you'll notice that testosterone is a precursor of oestrogen by way of aromatase:
http://en.wikipedia.org/wiki/File:Steroidogenesis.svg
http://en.wikipedia.org/wiki/Aromatase
Now, for those people who remember their organic chemistry and stoichiometry, rates of conversion reactions are increased with catalysts, and decreased with modulators. So, while aromatase will increase the rate at which testosterone converts into estrogen, an aromatase inhibitor will decrease conversion of testosterone.
http://en.wikipedia.org/wiki/Aromatase_Inhibitor
And it turns out that Aromatase Inhibitors are naturally occurring:
http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B8JGN-4TWSRR1-1&_user=10&_rdoc=1&_fmt=&_orig=search&_sort=d&_docanchor=&view=c&_searchStrId=1093611464&_rerunOrigin=google&_acct=C000050221&_version=1&_urlVersion=0&_userid=10&md5=2bb4c9b03794595de88508b47078c134
http://images.google.com/imgres?imgurl=http://www.fieldmuseum.org/research_collections/pritzker_lab/pritzker/people/people_images/stilbocarpapolaris.jpg&imgrefurl=http://www.fieldmuseum.org/research_collections/pritzker_lab/pritzker/people/alumni_mitchell.html&usg=__Xc_RyM3WV_KmlfwEp0KCwul_DAk=&h=137&w=200&sz=9&hl=en&start=7&um=1&tbnid=jlXt6kpeBMYsJM:&tbnh=71&tbnw=104&prev=/images%3Fq%3DBrassaiopsis%2Bglomerulata%26hl%3Den%26client%3Dfirefox-a%26rls%3Dorg.mozilla:en-US:official%26sa%3DN%26um%3D1
And there's a growing list of known aromatase inhibitors:
http://en.wikipedia.org/wiki/Exemestane
http://en.wikipedia.org/wiki/Anastrozole
http://en.wikipedia.org/wiki/Letrozole
So, simply put... what about the environmental chemicals that are masculinizing girls? Is it really just a matter of plastics feminizing boys? Or does it go both ways? Is it a matter of environmental toxicity in general?
Lastly, I'd also bring up the question whether feminization of boys is primarily caused by environmental chemicals, or if it's driven be completely different factors, such as 1) a cultural response to civil rights access for women, 2) decreased opportunities for war caused by nuclear detante, or 3) need for peaceful co-existance due to worldwide population increases a
Er, yeah? Do we know each other?
Rather than responding with name calling, why don't you grow a few neurons and provide an actual counter argument and explain why you don't agree with the GP? Simply calling another post juvenile, with no supporting argument, is trollish.
A better plan would be to create a legislative chamber who's sole responsibility is the repeal of laws. So, the legislative branch would be composed of three chambers: Senate, House of Legislation, and House of Repeals. Or something like that. That would create a better system of checks and balances.
That's one way of looking at it. Another way of looking at it is that we've discovered that segregating an application with it's own operating system is the easiest and most cost effective way of adding standards compliant network, cryptography, and database structures to an application. From the application development perspective, it makes far more sense to bundle an operating system with my application to provide network, crypto, and database functionality, than for me to try to roll my own. I like to think I'm a good programmer, but I'm not *that* good. It turns out that assigning IP addresses and names to applications makes a lot of sense. If you're interested in web services, it's the way to go. So, rather than roll it from scratch, just bundle an OS with the app.
I agree that deduplication is an issue; but in 20/20 highsight, I think we've discovered that application segregation has a lot more benefits than just improved stability.
True. I agree with everything you've said. But if you're doing Agile Development on a web application stack or some other type of complex system, and doing constant deployment, being able to fork the production system is invaluable. What you've written is perfectly accurate for software applications development in the traditional application sense. But it doesn't apply quite so well if one's focus is on systems development. If your coding mostly involves things like installing operating system modules, triggering operating hooks, writing startup scripts, script munching, screen-scraping, and writing to database tables for dynamic page generation... well, that kind of coding and systems design needs something a bit more robust. Something that can save the entire system configuration in one go.
Snapshots of production systems and hardware abstraction come to mind.
Server automation is an elegant way to do things, no doubt. I find that the machines they build never quite seem to the same though. Repositories get updated, driver versions get updated, different servers have slightly different hardware and driver requirements, and there's often little differences between builds. And that causes configuration drift over time.
Plus, once the machine is in production and real time data is being processed through the database adn application... all bets are off on rebuilding it with server automation. But a VM snapshot of that machine can be used to create an identical copy of that database at that particular point in time.
But hardware overhead is the entire point. Folks who aren't using virtualization tie down their critical applications to individual pieces of hardware that those applications are installed upon. If a disk or chip goes bad, then so does the database and the webserver. If someone forgets to pay a hosting bill, 6 months of web design... gone. If a huricane blows through and floods your datacenter, your apps... gone. All of these disasters arise from the application being tied to the piece of hardware it's installed on.
When I was talking about application portability, I was referring to the idea that an application stack or service need not be tied down to a particular piece of hardware that it's being hosted on. My web servers don't sit on any particular physical machine. I'm not tied to a server, a data center, or a hosting company. I started off on a laptop, have been through four hosting services so far, and haven't had to rebuild my web applications a single time. If I get fed up with a hosting service, I can migrate inside of a couple hours. My production servers are portable and stable through migrations.
Well, yes. There's that. You're absolutely correct about how virtualization can provide all that, and I do all of that kind of application portability testing with my day job.
But in regards to my startup and portability, I was thinking of applications in the sense of web services running on LAMP virtual devices. I bounce my production virtual applications from machine to machine, hosting service to hosting service. I started off on a laptop, and have been through four hosting services so far, and haven't had to rebuild any of my website during the migrations.
When I was talking about application portability, I was referring to the idea that an application or service need not be tied down to a particular piece of hardware. My web servers don't sit on any particular physical machine. Folks who aren't using virtualization tie down their critical applications to individual pieces of hardware. If a disk or chip goes bad, then so does the database and the webserver. If someone forgets to pay a hosting bill, 6 months of web design... gone. Ever build a website and have your hosting company go out of business on you? Or have a server room flooded that you were hosting from? I've had all of these things happen to me over the past 15 years.
I've had it happen to me so many times that I eventually swore I'd never let it happen again. So, I converted all of my development and production systems to virtual machines. I won't work without them now days.
With virtual machines, I'm not locked into a particular hosting provider. I have a working disaster recovery plan. I have portability of my production application stacks. I can be re-hosted on a new hosting provider inside of 4 hours if I get irked by my current host. By creating an abstraction layer between the application and the hardware, I'm able to shuffle my virtual machines around from host to host, and not be affected by hardware failures, business discontinuity, or network outages.
Having been involved in a business start-up for a year or so now, I'd have to disagree. Virtualization is indispensible for QA testing. Being able to run a virtual network on a personal PC lets me design, debug, and do proof-of-concepts without requiring the investment in actual equipment. Virtualization isn't just about hardware consolidation: it's also about application portability. Small companies have just as much need for QA testing, hardware recycling, and application portability as the large ones.
How the MRI scanner as a "big invention"? Just because a technology is profound, and is revolutionary, doesn't mean that it has to be a consumer commodity.
But if you do want consumer commodities, try the cell phone and the internet protocol.
Actually, we *are* growing synthetic organs although they're still expensive, we now have things like laser optical tweezers and MEMS, we generate electricity from incinerating garbage, we actually have solar panels power all sorts of public works (think emergency phones and deer-sensors on highways); oh, and we have the MRI scanner and the internet, and our robot dinosaurs are starting to work *real* good.
It's just that our technology advancements now come in the form of complex systems. An MRI has a gazillion parts and can't be stored at home, because it uses a superconducting cryomagnet. But it was made in the last 50 years, and has had a profound impact on life expectancy and our understanding of medicine.
We're currently in a period of systems consolidation and preparation for the next big tech paradigm. When it happens, we're going to have humanoid robots walking the streets; we'll have outpatient clinics where people can have synthetic organs grown; and we'll be powering things with a lot more solar/wind/biofuels.
Don't mistake the myths of advance technology for advance technology. The myths of anti-gravity and teleportation are simply human's desire to overcome physical limitations of the physical universe. But they don't necessarily have anything to do with where the tech advancements are actually occurring. The major tech advancements are occurring in biology and systems science nowdays; not in physics and chemistry.
Mod parent up informative. Having done neural MRI research, I think we'll be able to eventually resolve neurons and some of the axons and dendrites for structural MRI images. But the water diffusion limit is a serious issue for fMRI.
Two points: first, research MRI scanners are already routinely scanning at the molecular level. 9 Tesla magnets with 2" bores are routinely used to exam mouse brains at the molcular level. Problem is, they have small bores and are only good for scanning small things. Building a molecular grade scanner that you can fit an entire person into..... that's a bit more tricky. Second, I think you're absolutely right about diff'ing issue. It creates a classic backup and synchronization problem, if the intent is to virtualize a living person and maintain a classic human experience of life. If, on the other hand, you're willing to fork your consciousness, and live more than one life, then it's a feature, rather than a flaw.
Having done neural MRI research at an ivy league neurology research institute, I'd point out that MRI scanners require higher field strength to get higher resolution; not higher energy, per se. The energy requirements for higher resolution are indirect, in that they're powering a cryomagnet; not being beamed into cellular tissue, as is the case with CT scanners. MRI scanners already get well into the cellular range with high field research magnets (9T magnets, for instance). And since a neuron is a type of cell, I would go so far as to say that getting a MRI magnet to do a 1:1 image at the neuronal synaptic level is really quite feasible. And that's with the same level of energy being beamed into cellular tissue as with current MRI magnets. The limiting factor in creating resolution with an MRI is magnetic field curvature per volumetric space.
As a bioinformaticist, I suspect your analysis may be backwards. We've sequenced the human genome. We have a handle on the genetics component. The difficulty will be in creating an embodied intelligence which can interact with people in the real world, rather than sit in a box in a data center somewhere. The vast bulk of our intelligence is directed at interacting with our environment and with others. If an artificial brain can't be put into a suitable body, it's going to distinctly un-human, in so far as it will lack many of the basic learned experiences that humans have... dealing with gravity, the process of eating and sleeping, interacting with other humans, etc....
Personally, I think that software consciousness will turn out to be quite easy in hindsight,
Agreed. It's going to be an 'everything-and-the-kitchen-sink' kind of problem. Put enough of the right systems together, and it will emerge rather on its own.
The problem isn't going to be creating an artificial intelligence. The problem is going to be in making it an autonomous agent that can be socially integrated into society. Think how long it takes to raise a kid... teaching the kid language, potty training, kindergarten, social skills, job skills, etc... You need to do all of that training with an AI... but it won't necessarily have a body it can move around in and interact with other people with. The first AIs are going to be alien to our experience, unless they're purpose built in android type shells.
I suspect that in 50 years, we'll look back and say 'oh, yeah... the first AIs were waking up 30 years ago, but it took us another 10 years to recognize them for what they were'.
'go forth and multiply' is simply religious speak for 'propagate the species' and 'survival', both of which are fairly standard concept in population biology. I agree with the GP that there is an overpopulation problem as it is; but be careful about conflating it with religious speak. The bible simply expresses in words the biological drive that humans experience every day. Religious wack-jobs aren't responsible for overpopulation because they follow 'go forth and multiply', nor is the religion itself. Overpopulation is just overpopulation. No need to blame the religions for it, or the people following said religions.
Did you know that Cerner has invested over a billion dollars in R&D and is considered by many to have one of the most integrated EMRs out there? It's one of the few systems that can match, feature for feature, what VistA offers.
Having worked as a Cerner analyst for the past 5 years, I can guarantee you that your problem is that you haven't hired enough on-site analysts and programmers to customize the Cerner applications to your on-site workflow. You're just working with the default settings, and haven't used their UI programming kits to develop custom workflows yet.
The problem with Cerner is that it's built on top of an Oracle database, and is simply a little *too* customizable. It can be very intimidating to approach, with literally thousands and thousands of database tables, and hundreds of applications. So, what happens, is that everybody avoids the work of customizing it. And it doesn't get done.
Because Americans have a mentality that they deserve "the best", which includes healthcare. Thus, they demand to take their sniffles and colds and other minor issues to medical doctors. We've systematically devalued any other medical practioner other than the doctor. Physician assistants, paramedics, licensed physicians without medical doctorates.... all of these medical professionals have been removed from the system.
For instance... did you know that in many states you can become a physician with just a Bachelor's of Arts? A physician license is all you need to have to practice medicine. It used to be that a doctorate only indicated that you had extra schooling. Back in the day, physicians without doctorates were common, especially out in the old west. Nowadays, most people can't even conceive of a physician without a doctorate. The military has vestiges of that old practice, though. You can become a medic and practice a much wider range of medicine without a doctoral degree than you can in civilian medicine.