I, for one, welcome this addition... every privilege escalation path you add is good for literally years of paid contract work.
Maybe. My thought has always been that if fusion is close enough to get ballpark figures, we can build the necessary infrastructure and much of the housing in parallel with fusion development. Because the energy distribution will impose novel demands on the grid, it's going to require a major rethink on communications protocols, over-generation procedures, action plans on what to do if lines are taken out.
With fusion, especially, it's expensive at best to learn after the fact. Much better to get all the learning done in the decade until working fusion.
With all that in place, the ramp time until fusion is fully online at a sensible price will be greatly reduced.
Parallelize, don't serialize. Only shredded wheat should be cerealized.
So we won't know it's Gnome until the release?
Very, very, sneaky!
I suggest the first code name be "Zurich"; my second choice is "Gringott"... don't tell anyone, we wouldn't want them knowing we were talking about Gnome!
Because this will be unlike Biosphere 2 how?
They should have done it under water, if they insisted on Hawaii instead of Antarctica, which would have been a better choice (or at altitude on K2 or Everest, as long as it was a non-permanent installation). There's too much temptation to cheat, there's no real danger, and we already know that curing concrete will eat all your CO2 if you are stupid and don't seal it.
The only good choice fora Hawaii location other than "under water" would be "Inside a large SO2 cloud near a volcano, so that breathing the external atmosphere would get you dead".
I suggest we confuse the primary Uber benefits with the electronic dispatch system, rather than showing up when you've made a commitment to show up, the lower prices Uber charges on average, the cleaner, newer vehicles, ad the pleasant drivers who have to be pleasant because there's a feedback system which loses them referrals, whereas a taxi driver with a medallion can't really be fired without losing the medallion.
It must be the app, right folks? Not all the other things?
There used to be a web page called "Your Eyes Suck at Blue". You might find it on the Wayback machine.
You can tell the luminance of each individual channel more precisely than you can perceive differences in mixed color. This is due to the difference between rod and cone cells. Your perception of the color gamut is, sorry, imprecise. I'm sure that you really can't discriminate 256 bits of blue in the presence of other, varying, colors.
Rather than abuse every commenter who has not joined your specialty on Slashdot, please take the source and write about what you find.
Given that CPU and memory get less expensive over time, it is no surprise that algorithms work practically today that would not have when various standards groups started meeting. Ultimately, someone like you can state what the trade-offs are in clear English, and indeed whether they work at all, which is more productive than trading naah-naahs.
So basically I'm responsible, because I didn't write the firmware, and instead it was written by an idiot? Like someone who runs Windows, and is therefore able to turn off Windows Update because it exists in the first place, and could be the very channel which, by means of DNS cache poisoning and/or router compromise and/or BGP poisoning, was the means to infect the thing in the first place?
How about we hold the idiot who thought giving the fridge a routable address via NAT off the local network in the first place, so that they could market specific brands of milk via coupons sent to me when I'm running low on milk, was a good idea, responsible instead?
It's clear you do not understand the position. You need to read about what the job entails, and then decide if you want to accept the offer or not. It's a substantial change in role from your current position. In this case, the Wikipedia article is pretty accurate:
As others have stated, your primary responsibility is specification. To do this, you meet with stakeholders, and do projective business IT strategic planning.
While you can relatively easily negotiate for read only access as a demand from "on high", you should not personally use it. It should be used by your staff, temporary or permanent, for the performance of detailed specification compliance audits and spot checks. This is adequate justification to get management buy-in for this type of access. This type of access is for a role, not for a person. This is one of the reasons it should not be you.
For day to day operations, what you need are dashboards, which measure the degree of compliance with the detailed specification in an ongoing basis. The main purpose of the dashboards are to give you information you can summarize periodically to the executives, and as feedback into your strategy decisions going forward (particularly decisions surround capacity planning and technology adoption).
The purpose of the ability to audit is to ensure that the dashboards are not giving you fudged numbers based on what you want to hear, vs. what IT whats to implement (or what they can implement; you may be asking for the impossible, as a dictator, when you should be viewing the detailed specifications as a negotiation). Audits can also provide progress reporting on deployment of specification changes, based on what IT is reporting vs. actual. Since you appear to be planning a lot of churn for them, I suspect you will need one FTE staff member to perform rolling audits to ensure that things are on schedule, and if they aren't, you can negotiate either a schedule change, or a working emphasis (this is a prioritization list: other things will suffer if you have insufficient staff in IT for the demands being made).
Good examples of what you can dictate are things you've complained about: Automated Provisioning, use of SRM in VMWare installations, enabling automated tiering in EMC storage hardware, and so on. Things which will bite the enterprise on the ass eventually, if they are not done.
Your initial dashboards should be based on displaying progress on this (e.g. "percentage of VMWare installations with SRM enabled", etc.).
Note that before any of your shit starts running down hill, you need to make sure you are not downhill from them. To do that, you are likely going to have to have meetings, a couple times a week (usually something like Tuesday/Friday), to collect requirements for the business, and then mash it into part of the requirements document that you will need to prepare before you start defining strategy and dictating conformance/performance). Otherwise you will find yourself buried in crap, because your goals will not be clearly derived from the enterprise goals.
Your ability to take new input from the early in the week meeting and report it in the late in the week meeting with the stakeholding execs is going to be your main performance metric until you go into the design, then implementation phases. Your goal is to get to an ongoing maintenance/change phase. Your metrics will be different in each phase. You will use these in your performance reviews to justify yourself.
If you have other things you care about, they need to be in the specifications -- and they probably need a dashboard, and they need to have a schedule.
For example, if you care about automated provisioning, then you need to have a scratch machine that is identical to the production machines, and you need to have a metric of "how long from a zeroed state does it take to provision the machine and make it ready for service. You would likely break this down further by provisioning category, if all machines are not provisioned identically (it's unlikely that they will be), and you need to have a list of configurations that the dashboard uses to display per-configuration percentage above/below goal speed (translates to downtime), and so on.
Note that for every metric you define, you will need to be prepared to negotiate a baseline acceptability, and then provide feedback into the IT performance review process as well -- and be prepared to give out "exceeds expectations", if they happen to do so -- be fair, do not just be a dictatorial ass: these people are your partners, not your minions.
If after reading the definition of the job -- and reading all of the above -- you feel that you are prepared to take the job, and define at least a rough outline of the stages of getting the processes in place, and demonstrate your progress on doing so to the execs -- and you want the job -- then take it. Otherwise, decline the job, and expect them to either find a second choice from inside to promote. Most likely whoever else has kept their systems up, and also bitched to management about the difficulty in doing so due to the environment, an outside person who can do the job, an outside person who's basically going to be a NOOP, or, worst case, an outside person who thinks they can do the job, but who will actually screw everything up. In other words, you should also think carefully about whether or not you can afford the risks of not taking the job, even if it's not entirely to your liking or inside your comfort zone.
Hope that all helps.
90% of ad networks vet their ads to run clean
Are you saying that if I send them an
Because if they don't do that, then they're not vetting jack shit.
(Putting aside the fact that Flash ads have mercifully fallen out of fashion in the last few years.)
"Completes Great Pacific Garbage Patch Research Expedition"
"every consumer needs to assume some responsibility"
Really? When *I* go online, yes, I have to assume some responsibility.
I hold the "things" up to the same standard: when the "things" go online, *they* have to assume some responsibility. It's not my f***ing fault if my fridge wants to surf the web, it's the fridge's fault.
When you make your mark in the world, watch out for guys with erasers. -- The Wall Street Journal