What the Supreme Court actually did was to disallow direct regulation of CO2 unless the EPA actually wants to attempt to regulate ALL producers of >250 tons annually, which is impractical.
What the EPA intended to do was to regulate producers of >100,000 tons annually, with the possibility of reducing that threshold over time as we get handle on the issue.
What the Supreme Court did leave intact is the ability to regulate CO2 production by producers who are already regulated for other reasons 'anyway'.
That does happen to match up fairly well with what the EPA intended to do originally, but does not allow the flexibility to regulate CO2 producers who do not produce large amounts of other pollution.
I wouldn't go so far as "useless", but I'd say powershell would be a lot more useful if I could count on having the AD and Exchange cmdlets available. As it is, many of my admin scripts are tied to my workstation due to dependencies.
Or, the answer is I'm an idiot who doesn't know the right way to package and distribute powershell scripts.
I was thinking "looks good", until I saw that this setup uses a dual-headed USB charger that sure looks designed for indoor use only. I'm fine with a fixed battery in my cell phone, tablet, and even laptop, but my bike a) lives outdoors and b) need to accept a spare battery because working lights can be a life-or-death matter.
It was easy to manage since there was never any question which tape was 'next' or safe to reuse. Robotic tape libraries, software with better tape management, and eventually disk-to-disk backup make it obsolete, but I always did think that a 28x13+1(or2) calendar would be much more sensible than what we have now.
Not that I was ever silly enough to think that the world would adopt just because it makes more sense:)
Capable? We're capable of it now (for values of 'now' == 'using a current level of technology').
Doing it requires some heavy lifting in a few senses:
1. We would need to accept that the first group or groups out are most likely going to die, and that we're going to accept that as part of the learning curve. That sucks, but I wouldn't expect to have any problems finding volunteers regardless. 2. Those volunteers would need to accept that those who survive will probably live short lives in miserable conditions working hard to build infrastructure that followers-on will benefit from. 3. We would need to accept that doing this means dedicating somewhere between 1x and 2x the size of the annual US annual pet food & supplies budget ($35 billion) every year for the next decade or so (http://www.americanpetproducts.org/press_industrytrends.asp). 4. We would need to provide some incentive for the volunteers beyond adventure and fame. Land grants on Mars, perhaps?
Obviously way oversimplified, but once you take away the need to make it a safe round trip, the project gets much easier. I could be wrong; there may not be enough volunteers ready to risk their lives for a chance to colonize Mars, but I'd bet there are.
What's holding us back isn't technology, it's a lack of societal will to devote the relatively modest resources needed to try.
I looked at this tech when it was actually new, around a year ago, and admittedly just pulled the datasheet today to double check my recollection. I'm glad that the limitations are less severe than I thought.
OTOH, nVidia really ought to fix their datasheets, also.
This isn't particularly new. It's nice tech, but each ~$2000 K1 board supports 4 users. 4. The K2 board supports 2 'power users'. (ref: NVIDIA data sheet: http://www.nvidia.com/content/... )
If I cram 4 K1 boards in a server, I can now support 16 virtual desktops with 3D acceleration for an $8k delta over and above the other expenses of VDI.
Unless you ABSOLUTELY MUST have VDI for 3D workloads, I can't see how this makes sense.
Once upon a time when 128Kbps BRI ISDN was fast, voice calls were frequently billed at a lower per-minute rate than data calls. To take advantage of this, a common trick was to place a voice call and then pass data over it. This did result in a lower data rate of 56Kbps per channel or 112Kbps overall, but if that was enough, you could save a lot of money.
Fast-forward to VOLTE.
Most wireless carriers offer unlimited voice minute plans. Since it's all going to be IP over LTE now, I have to wonder if there will a way to pass your data off as a 'voice' call and avoid data caps and limits? Not on a stock phone, but on a rooted device with a custom OS build, maybe?
note taking in meetings with OneNote IT Manager that takes notes? Interesting.
Serious question: what do you think managers do? How do you think we juggle multiple projects with varying requirements, deadlines, staffing needs, and status changes without taking careful notes?
Regarding Surface: I've offered my thoughts based on 6+ months of daily real-world business usage. I gather that you disagree, but I'd like to know: have you actually tried using one?
Absolutely: Surface (RT/Pro) is a product for those ALREADY tied in to MS systems, not a product to entice new customers.
Thankfully for MS, in the business world, that's a pretty big market, so take it and run with it:
1. Remove the silly restrictions on joining the RT Surfaces to a domain and using them for business purposes. 2. Introduce Surface 3 (non-pro) @$500. Sell it at cost, if cost is less than $500. I don't care if it's ARM or x64, but keep everything that makes Surface 2 good and cut price to the bone. Make them so attractive that managers need to justify NOT buying them, not the other way around. 3. Bundle the full Office suite with all Surfaces, not just the RT version, and add Visio. 4. Bundle at least the basic touch keyboard with all Surfaces.
Basically, instead of trying to sell to the iPad market, embrace these as business machines that also happen to work OK for entertainment on the go.
The author went on to point out that the Three Laws are fictional laws that were applied to fictional full AIs that we don't have in the real world.
It's possible I'm wrong, but having read the article twice now, I don't see where the author made or addressed that point at all. That omission is what my initial comment turns on -- discussing what a robot should do in the absence of true AI is meaningless.
In the end the error occurs because of a human mistake in programming it or missing a possible condition.
Or a failed mechanical system.
Even if the sensors and software are perfect, a mechanical failure could still result in a crash. When that happens, who is liable?
I would imagine the owner, just the same as if the steps collapse in your house and injure someone, you are liable even if you can't be said to be responsible in any proximate sense.
Now, your auto insurance rate will depend on your age, sex, location, type of car, sensor suite, software version, and whether or not you've rooted it. I'm so looking forward to that.
On the other hand, if Google really wants to assume all liability for anyone using their driverless cars, sign me up!
Of course current and contemplated robots can't make decisions about whether or not to sacrifice their owner to save two strangers. That sort of decision making depends on an independent ability to think and weigh alternatives morally.
Asimov's laws were written for robots that were also artificial intelligences. Kind of a big point to leave out of this article, since it changes the nature of the question entirely.
I do not believe that anyone seriously believes that driverless cars, industrial robots, or roombas work that way.
The programmers writing the code for those systems will program them to perform the specified tasks as well as possible taking in to account all relevant rules and regulations as well as the nature of the task and the abilities of the robotic system. Anything unanticipated will result in undefined behavior, perhaps guided by some very high-level heuristics (ie., if you don't know what to do, stop, put on the emergency flashers, and call for human assistance).
Short version: in the absence of artificial intelligence, talking about what a robot should do in a moral context is silly, not profound.
I suspect it's an editing error where I was writing in present tense (be seen as...), started a switch to past tense (been seen as...), and instead ended up with that ridiculous construction.
First off, I think that 'better than ZFS' is a good and legitimate goal, seeing as how ZFS is very, very good, but not perfect.
That said, there's also BTFS and HAMMER aiming to be 'better than ZFS'.
I know: everyone wants to scratch their own itch, and there is no reason that multiple projects in the same area should necessarily been see as competing, and if I'm unhappy about it, I should just go write my own instead of complaining. Did I cover everything?:)
I just wonder sometimes if Linux wouldn't have moved beyond EXT4, X11, and the desktop environment wars if the 'not invented here' syndrome were just a little less prevalent.
Not that I actually think this is a great idea, but if we really want to bring people online, why not aim for a device that can actually get them online rather than a USB stick that requires a complete PC with network connectivity to do so. By contrast, a low-end smart phone can:
1. Be had for ~$100 USD in quantity 1 ( http://www.amazon.com/gp/offer-listing/B00CKUBLFQ/ref=sr_1_1_olp?ie=UTF8&qid=1399770265&sr=8-1&keywords=windows+phone+unlocked&condition=new ). Call it $75 USD in large quantity 2. Can get online without any other equipment 3. Can be practically recharged with a cheap solar panel 4. Can be used for mobile payment networks that are very popular in the developing world
Yeah, I know that $75 is an order of magnitude greater than $7, but it seems like a far wiser use of funds if you feel the need to buy and supply electronics instead of clean water.
After seeing what Paramount did with the Blu-Ray release of the original Star Trek, there might actually have been hope that they would put out a proper restoration of the originals, possibly with selectable audio mixes and VFX.
Nice to see someone who gets it. I've been in the IT infrastructure business for many years now, and I think that plumbing, electrical, or another skilled trade is exactly the right analogy.
That said, the answer to the question that I've found is that the compelling story you tell about infrastructure is all about the future. Specifically, how you plan to evolve that infrastructure to support the changing IT environment and needs of the business while staying within reasonable and predictable budgets. 'Predictable' can not be overemphasized.
At any time, you should be able to tell the business managers what your infrastructure will look like in 1, 3, 5 years, what that will cost, what alternatives you have considered, and what the major risks are.
In a sense, you are correct. I am referring to more than the kernel when I say 'Linux'. Acknowledged, there is wide disagreement about that.
I'm referring to 'Linux' as the core of an alternative to the Mac OS/OS X/DOS/Windows 9.x/Windows NT/BeOS systems that have locked the vast majority of computer users in to a licensed platform for most of personal computing history. It's not happening, and that saddens me.
I've been around Linux a long time. It's powerful. It's alternately the only way to accomplish some tasks, and maddeningly broken in others (even ignoring sound and xconfig). The OOM killer's tendency to kill exactly the process you DO NOT WANT KILLED has been an issue for more years than I can count. Maybe it's better now (and yes, I know it is tunable), or maybe we all just have more memory.
At any rate, Linux has succeeded marvelously as the hobby it once was, and I'm glad it's around underneath Android, Microtik, Vyatta, etc. It's a good server platform, although no longer head-and-shoulders over Windows Server as is used to be. What it isn't is meaningful for most users most of the time.
I remember my first successful install -- Slackware with kernel 0.99pl12. Tried SLS and failed.
I applaud the award, but I'll admit to mixed feelings about Linux these days.
Free, in either sense, just isn't enough to put up with the added difficulty of keeping a system running. I'm not talking about hobbyist level on the one hand where each system can be lovingly tended by hand nor large-company level where systems are templates, scripted, PUPPETed, and under service contract. I'm not even talking about Linux on the desktop, which is still for masochists. I'm talking about small-to-midsize deployments where the system admin is either nonexistent or a generalist who is also the help desk, web developer, and DBA. In that case, MS has made it so easy to put in a domain controller, WSUS, and manage centrally or just go with Office 365 that Linux looks positively archaic.
RHEL with RHN (or the Suse or Ubuntu equivalent) are OK, but far more expensive and still don't manage your desktops in any meaningful fashion. The Windows support in PUPPET and CHEF are poor at best.
I can't help feeling that Linux, while extraordinarily powerful, has less relavance now than it did 10 years ago. It kind of feels like VMS and Solaris did when they were clearly better than their competition, but basically missing the point for mainstream business or home use. No doubt Linux will be around in the server room and as the basis of 'appliances' and embedded systems for years to come, but the year of Linux on the desktop is never coming, is it?
I've used it, personally, to implement a public-facing website. That site endured the dreaded 'slashdot effect' several times. No failures.
When implemented properly, Marklogic is damn near unkillable. It will slow down, it will reject connections when queues are full, but it will not fall over. Naturally, this assumes proper underpinnings and capacity calculations. With Marklogic, those are actually documented.
Mandatory disclosure: I do not have and have never had any association with Marklogic other than a paying customer.
Slashdot Mirror
I don't know how practical it will be, but this looks much cooler:
http://www.laserfocusworld.com...
What the Supreme Court actually did was to disallow direct regulation of CO2 unless the EPA actually wants to attempt to regulate ALL producers of >250 tons annually, which is impractical.
What the EPA intended to do was to regulate producers of >100,000 tons annually, with the possibility of reducing that threshold over time as we get handle on the issue.
What the Supreme Court did leave intact is the ability to regulate CO2 production by producers who are already regulated for other reasons 'anyway'.
That does happen to match up fairly well with what the EPA intended to do originally, but does not allow the flexibility to regulate CO2 producers who do not produce large amounts of other pollution.
I wouldn't go so far as "useless", but I'd say powershell would be a lot more useful if I could count on having the AD and Exchange cmdlets available. As it is, many of my admin scripts are tied to my workstation due to dependencies.
Or, the answer is I'm an idiot who doesn't know the right way to package and distribute powershell scripts.
I was thinking "looks good", until I saw that this setup uses a dual-headed USB charger that sure looks designed for indoor use only. I'm fine with a fixed battery in my cell phone, tablet, and even laptop, but my bike a) lives outdoors and b) need to accept a spare battery because working lights can be a life-or-death matter.
Nice design, but seriously deficient function.
That is remarkably similar to what I used to use for a backup tape rotation once upon a time:
27 daily tapes labeled d1-d27
13 'monthly' tapes labeled m1-m13
1 year-end tape labeled appropriately
It was easy to manage since there was never any question which tape was 'next' or safe to reuse. Robotic tape libraries, software with better tape management, and eventually disk-to-disk backup make it obsolete, but I always did think that a 28x13+1(or2) calendar would be much more sensible than what we have now.
Not that I was ever silly enough to think that the world would adopt just because it makes more sense :)
Capable? We're capable of it now (for values of 'now' == 'using a current level of technology').
Doing it requires some heavy lifting in a few senses:
1. We would need to accept that the first group or groups out are most likely going to die, and that we're going to accept that as part of the learning curve. That sucks, but I wouldn't expect to have any problems finding volunteers regardless.
2. Those volunteers would need to accept that those who survive will probably live short lives in miserable conditions working hard to build infrastructure that followers-on will benefit from.
3. We would need to accept that doing this means dedicating somewhere between 1x and 2x the size of the annual US annual pet food & supplies budget ($35 billion) every year for the next decade or so (http://www.americanpetproducts.org/press_industrytrends.asp).
4. We would need to provide some incentive for the volunteers beyond adventure and fame. Land grants on Mars, perhaps?
Obviously way oversimplified, but once you take away the need to make it a safe round trip, the project gets much easier. I could be wrong; there may not be enough volunteers ready to risk their lives for a chance to colonize Mars, but I'd bet there are.
What's holding us back isn't technology, it's a lack of societal will to devote the relatively modest resources needed to try.
Meanwhile, Elon Musk is going to go ahead and do it anyway: http://www.wired.com/2012/11/e...
I wouldn't bet my life on his succeeding, but I wouldn't bet it on his failing, either.
Apparently I was mistaken.
I looked at this tech when it was actually new, around a year ago, and admittedly just pulled the datasheet today to double check my recollection. I'm glad that the limitations are less severe than I thought.
OTOH, nVidia really ought to fix their datasheets, also.
Better now? (and profanity-free to boot!)
This isn't particularly new. It's nice tech, but each ~$2000 K1 board supports 4 users. 4. The K2 board supports 2 'power users'. (ref: NVIDIA data sheet: http://www.nvidia.com/content/... )
If I cram 4 K1 boards in a server, I can now support 16 virtual desktops with 3D acceleration for an $8k delta over and above the other expenses of VDI.
Unless you ABSOLUTELY MUST have VDI for 3D workloads, I can't see how this makes sense.
Once upon a time when 128Kbps BRI ISDN was fast, voice calls were frequently billed at a lower per-minute rate than data calls. To take advantage of this, a common trick was to place a voice call and then pass data over it. This did result in a lower data rate of 56Kbps per channel or 112Kbps overall, but if that was enough, you could save a lot of money.
Fast-forward to VOLTE.
Most wireless carriers offer unlimited voice minute plans. Since it's all going to be IP over LTE now, I have to wonder if there will a way to pass your data off as a 'voice' call and avoid data caps and limits? Not on a stock phone, but on a rooted device with a custom OS build, maybe?
My uses, as an IT manager:
note taking in meetings with OneNote
IT Manager that takes notes? Interesting.
Serious question: what do you think managers do? How do you think we juggle multiple projects with varying requirements, deadlines, staffing needs, and status changes without taking careful notes?
Regarding Surface: I've offered my thoughts based on 6+ months of daily real-world business usage. I gather that you disagree, but I'd like to know: have you actually tried using one?
Absolutely: Surface (RT/Pro) is a product for those ALREADY tied in to MS systems, not a product to entice new customers.
Thankfully for MS, in the business world, that's a pretty big market, so take it and run with it:
1. Remove the silly restrictions on joining the RT Surfaces to a domain and using them for business purposes.
2. Introduce Surface 3 (non-pro) @$500. Sell it at cost, if cost is less than $500. I don't care if it's ARM or x64, but keep everything that makes Surface 2 good and cut price to the bone. Make them so attractive that managers need to justify NOT buying them, not the other way around.
3. Bundle the full Office suite with all Surfaces, not just the RT version, and add Visio.
4. Bundle at least the basic touch keyboard with all Surfaces.
Basically, instead of trying to sell to the iPad market, embrace these as business machines that also happen to work OK for entertainment on the go.
Got to love a major ecommerce vendor who can't even get THAT right!
At some point, that has to count as negligence, and some sort of liability ought to attach.
>
The author went on to point out that the Three Laws are fictional laws that were applied to fictional full AIs that we don't have in the real world.
It's possible I'm wrong, but having read the article twice now, I don't see where the author made or addressed that point at all. That omission is what my initial comment turns on -- discussing what a robot should do in the absence of true AI is meaningless.
In the end the error occurs because of a human mistake in programming it or missing a possible condition.
Or a failed mechanical system.
Even if the sensors and software are perfect, a mechanical failure could still result in a crash. When that happens, who is liable?
I would imagine the owner, just the same as if the steps collapse in your house and injure someone, you are liable even if you can't be said to be responsible in any proximate sense.
Now, your auto insurance rate will depend on your age, sex, location, type of car, sensor suite, software version, and whether or not you've rooted it. I'm so looking forward to that.
On the other hand, if Google really wants to assume all liability for anyone using their driverless cars, sign me up!
Of course current and contemplated robots can't make decisions about whether or not to sacrifice their owner to save two strangers. That sort of decision making depends on an independent ability to think and weigh alternatives morally.
Asimov's laws were written for robots that were also artificial intelligences. Kind of a big point to leave out of this article, since it changes the nature of the question entirely.
I do not believe that anyone seriously believes that driverless cars, industrial robots, or roombas work that way.
The programmers writing the code for those systems will program them to perform the specified tasks as well as possible taking in to account all relevant rules and regulations as well as the nature of the task and the abilities of the robotic system. Anything unanticipated will result in undefined behavior, perhaps guided by some very high-level heuristics (ie., if you don't know what to do, stop, put on the emergency flashers, and call for human assistance).
Short version: in the absence of artificial intelligence, talking about what a robot should do in a moral context is silly, not profound.
Apparently, I grew up speaking 'typo'.
I suspect it's an editing error where I was writing in present tense (be seen as...), started a switch to past tense (been seen as...), and instead ended up with that ridiculous construction.
Oops.
First off, I think that 'better than ZFS' is a good and legitimate goal, seeing as how ZFS is very, very good, but not perfect.
That said, there's also BTFS and HAMMER aiming to be 'better than ZFS'.
I know: everyone wants to scratch their own itch, and there is no reason that multiple projects in the same area should necessarily been see as competing, and if I'm unhappy about it, I should just go write my own instead of complaining. Did I cover everything? :)
I just wonder sometimes if Linux wouldn't have moved beyond EXT4, X11, and the desktop environment wars if the 'not invented here' syndrome were just a little less prevalent.
Not that I actually think this is a great idea, but if we really want to bring people online, why not aim for a device that can actually get them online rather than a USB stick that requires a complete PC with network connectivity to do so. By contrast, a low-end smart phone can:
1. Be had for ~$100 USD in quantity 1 ( http://www.amazon.com/gp/offer-listing/B00CKUBLFQ/ref=sr_1_1_olp?ie=UTF8&qid=1399770265&sr=8-1&keywords=windows+phone+unlocked&condition=new ). Call it $75 USD in large quantity
2. Can get online without any other equipment
3. Can be practically recharged with a cheap solar panel
4. Can be used for mobile payment networks that are very popular in the developing world
Yeah, I know that $75 is an order of magnitude greater than $7, but it seems like a far wiser use of funds if you feel the need to buy and supply electronics instead of clean water.
After seeing what Paramount did with the Blu-Ray release of the original Star Trek, there might actually have been hope that they would put out a proper restoration of the originals, possibly with selectable audio mixes and VFX.
Nice to see someone who gets it. I've been in the IT infrastructure business for many years now, and I think that plumbing, electrical, or another skilled trade is exactly the right analogy.
That said, the answer to the question that I've found is that the compelling story you tell about infrastructure is all about the future. Specifically, how you plan to evolve that infrastructure to support the changing IT environment and needs of the business while staying within reasonable and predictable budgets. 'Predictable' can not be overemphasized.
At any time, you should be able to tell the business managers what your infrastructure will look like in 1, 3, 5 years, what that will cost, what alternatives you have considered, and what the major risks are.
In a sense, you are correct. I am referring to more than the kernel when I say 'Linux'. Acknowledged, there is wide disagreement about that.
I'm referring to 'Linux' as the core of an alternative to the Mac OS/OS X/DOS/Windows 9.x/Windows NT/BeOS systems that have locked the vast majority of computer users in to a licensed platform for most of personal computing history. It's not happening, and that saddens me.
I've been around Linux a long time. It's powerful. It's alternately the only way to accomplish some tasks, and maddeningly broken in others (even ignoring sound and xconfig). The OOM killer's tendency to kill exactly the process you DO NOT WANT KILLED has been an issue for more years than I can count. Maybe it's better now (and yes, I know it is tunable), or maybe we all just have more memory.
At any rate, Linux has succeeded marvelously as the hobby it once was, and I'm glad it's around underneath Android, Microtik, Vyatta, etc. It's a good server platform, although no longer head-and-shoulders over Windows Server as is used to be. What it isn't is meaningful for most users most of the time.
I remember my first successful install -- Slackware with kernel 0.99pl12. Tried SLS and failed.
I applaud the award, but I'll admit to mixed feelings about Linux these days.
Free, in either sense, just isn't enough to put up with the added difficulty of keeping a system running. I'm not talking about hobbyist level on the one hand where each system can be lovingly tended by hand nor large-company level where systems are templates, scripted, PUPPETed, and under service contract. I'm not even talking about Linux on the desktop, which is still for masochists. I'm talking about small-to-midsize deployments where the system admin is either nonexistent or a generalist who is also the help desk, web developer, and DBA. In that case, MS has made it so easy to put in a domain controller, WSUS, and manage centrally or just go with Office 365 that Linux looks positively archaic.
RHEL with RHN (or the Suse or Ubuntu equivalent) are OK, but far more expensive and still don't manage your desktops in any meaningful fashion. The Windows support in PUPPET and CHEF are poor at best.
I can't help feeling that Linux, while extraordinarily powerful, has less relavance now than it did 10 years ago. It kind of feels like VMS and Solaris did when they were clearly better than their competition, but basically missing the point for mainstream business or home use. No doubt Linux will be around in the server room and as the basis of 'appliances' and embedded systems for years to come, but the year of Linux on the desktop is never coming, is it?
I've used it, personally, to implement a public-facing website. That site endured the dreaded 'slashdot effect' several times. No failures.
When implemented properly, Marklogic is damn near unkillable. It will slow down, it will reject connections when queues are full, but it will not fall over. Naturally, this assumes proper underpinnings and capacity calculations. With Marklogic, those are actually documented.
Mandatory disclosure: I do not have and have never had any association with Marklogic other than a paying customer.
Masochist.