IF they are doing that...
Which they aren't, since there's no money in it for them, getting involved in law suits,
IF they are doing that...
Which they aren't, since there's no money in it for them, getting involved in law suits,
100K a year after taxes.
It's bound to go up, but to being "wealthy" means $2-4M in investments to get to that after taxes. Depending on how.
Everything after that is either "invest in the investments" or "pay off the house loan against the line of credit".
Any way you look at it, if you do not want to work, or you do not want to work on something other than "facebook++" for some asshole who thinks he has a magic "get rich quick" scheme, you are at a minimum looking at $4M.
What command-line do you use to get anagrams?
Pretty sure it's "/bin/sh and a working brain".
"Denali" = anagram for "Denial"
Worked on many projects code named "Denali".
Sadly out of mod points... this deserves to be modded up.
Re the last paragraph. That is not entirely true, as Intel appear to be able to integrate new chipsets during the time they are released (but only to next tier manufacture) before the public can buy anything using it.
What kind of "peeing on it" has been done to the Intel drivers to get them integrated ?
Exactly the same kind. It's possible to do for anything, it just takes time.
The reason Intel is able to do this ahead of general release, when other vendors aren't, is that it does not lose them a competitive advantage.
First, there is no issue of another manufacturer producing "pin and register compatible devices", and undercutting Intel, because Intel's graphics are integrated into the CPU; you'd have to build an entire Intel compatible CPU as well, and you'd have to do it competitively in terms of price point.
Second, no one really wants to emulate Intel Integrated Graphics in silicon, since there's really no advantage to doing so, since the chips have inferior performance relative to the competition.
So there's really nothing lost by Intel pre-announcing all of the information needed to make a driver, or even publishing source code for the driver, since doing so will sell more Intel chips, not less. For other GPU vendors, this is simply not the case, and there's no economic value in such pre-disclosure.
The whole posting is disengenuous.
"the R9 Fury isn't yet in good shape on the open-source driver"
The card won't be changing to fix this; the driver will have to change to accommodate the card; therefore it is more correct to say "The Open Source driver is not yet in good shape on the R9 Fury". In other words, it's not the hardware's fault that the driver doesn't support it yet.
"AMD's open-source developers haven't yet found the time to implement power management / re-clocking support"
The power management model in Linux is Linux's responsibility, not AMD's. The authors of the Open Source driver are accountable *only* for writing callbacks for the device power management component, and populating the structure. It's my understanding that Linux lacks a uniform model for use by all graphics drivers, in this regard. his is a Linux issue, not an AMD issue.
In general, in a hardware world, you either NDA people, or the Open Source is going to lag the closed source, period. This is because openly manipulating code related to an unreleased hardware product in a publicly accessible source repository, instead of a privately held repository, is tantamount to preannouncing your hardware to competitors. You might as well have the CEO call a press conference, and then shoot themselves in the head in public.
Open Source projects have a secondary problem in that, even if the driver source was developed entirely by engineers within AMD, and released the same day as the hardware was made available, the Open Source projects aren't going to be happy just integrating the code as is. They will insist on peeing on it to make it smell like themselves, just as cats do with new furniture, and this will take time. You can either have closed source, or you can have it integrated later than the release date, but you can not have both.
I, for one, welcome this addition... every privilege escalation path you add is good for literally years of paid contract work.
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?
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.
"Completes Great Pacific Garbage Patch Research Expedition"
If I'd known computer science was going to be like this, I'd never have given up being a rock 'n' roll star. -- G. Hirst