I run a 50 TB (and growing) pair of Documentum repositories on a SQL Server cluster. The only performance issues we've had can be traced to the storage system, not to the database.
Wish I had mod points today to mod this one up. Proficiency with a coding language or even frameworks or libraries only matters to a limited extent. Proficiency in triage and identification of issues, skills in enterprise scale design, preemptive anticipation of issues both technical and bureaucratic, understanding how costs affect your project... this is stuff that the vast majority of employees can only gain via experience. Coding at home with a stack of books or bookmarked Internet tutorials simply won't get you there.
Not terribly insightful. Deciding to pursue a buyout (or go public) has nothing to do with altruism for employees compensated by stock options - assuming he's in business to make a return on his investment (and that's safe until you clearly demonstrate otherwise), it's in his selfish interest to keep his employees reasonably happy. Part of that is making good on the implicit promise that as an owner, you will try your best to make those options worthwhile. Departing employees, especially in a startup, leave with important IP in their heads, including a lot of know-how about the business. Replacing them is non-trivial. An exodus en masse could very well permanently cripple the business.
Describing it as a "printer" implies some detail to the technique that would be missing from your description. And no, it's not really like making a car.
I know zilch about materials science, but I have to wonder how these structures would hold up as they get large. Will they be like concrete, or like sandstone? or like particle board...
I think I have a pretty good idea of your philosophical leanings on the subject of labor law, but I'll say this anyway for other readers. "Right-to-work" laws should really be termed "opportunity-to-work" laws, because the economic theory is that by lowering the potential risks for employers, they will be more willing to take those risks. Yes, you have the "right" to be fired immediately, but without those laws you might never have had the job in the first place.
"Contractor" in this sense does not necessarily mean "independent contractor". Most "government contractors" are employees of firms and get paid on W-2s like anybody else. The "contract" is government with firm, not government with individual.
Making them regular old unionized state workers makes them incredibly hard to fire, among other things. so you end up with a higher head count than you might otherwise, because you have to hire people to carry the dead weight.
Motivations for employees are always selfish - that's basic compensation theory. The trick is to try to align the rewards with the goals for the company or organization that you wish to accomplish, so that in serving their selfish interests, the employees are also serving the interests of the organization.
You have to consider the personal incentives for managers with budget authority. If you manage a shrinking department, there's no rewards for spending less money. Your prestige and responsibility shrink, and your career path dwindles. For better or for worse, all of the incentives for budget managers are towards bigger and bigger spending allocations.
You might be surprised at what agencies and have requirements for the most computing resources. Sure, DoD and NASA are high on the list, but so are IRS, SSA, CMS. Operational agencies that serve most Americans have HUGE amounts of data to manage.
If the government gets big enough, it won't be able to stand up at all... kinda like one of those 800 lb fat people on Maury who can't get out of bed and has to have breakfast trucked in and shoveled... never mind.
**shudder**
The government's job in this case is not to duplicate the testing done by Toyota engineers, but rather to provide oversight and verify that Toyota's engineers ARE doing it, to a degree of completeness and correctness that satisfies statutes and regulations. Clearly that task requires substantial technical expertise, but it's not the same task.
I can promise you have independent verification and validation contracts are bread & butter in the federal contracting world. The federal government has made huge strides in the direction of outsourcing almost all technical expertise, and quite a bit of management expertise (google "federal PMO contracts" for lots of random examples). The few civil servants left in many agencies are a kind of sheepherders, managing vast groups of contractors.
Slashdot Mirror
The glaring lack of proper nouns (specifically, people in my contacts or people I know, my individual pets, etc) makes this not so useful to me.
If you think that only people who have porn (or even laptops) should be worried about this, YOU have bigger problems.
Well, Australia just came off my honeymoon list.
how'd you get that past the lameness filter? sorceress indeed...
I run a 50 TB (and growing) pair of Documentum repositories on a SQL Server cluster. The only performance issues we've had can be traced to the storage system, not to the database.
Wish I had mod points today to mod this one up. Proficiency with a coding language or even frameworks or libraries only matters to a limited extent. Proficiency in triage and identification of issues, skills in enterprise scale design, preemptive anticipation of issues both technical and bureaucratic, understanding how costs affect your project... this is stuff that the vast majority of employees can only gain via experience. Coding at home with a stack of books or bookmarked Internet tutorials simply won't get you there.
Not terribly insightful. Deciding to pursue a buyout (or go public) has nothing to do with altruism for employees compensated by stock options - assuming he's in business to make a return on his investment (and that's safe until you clearly demonstrate otherwise), it's in his selfish interest to keep his employees reasonably happy. Part of that is making good on the implicit promise that as an owner, you will try your best to make those options worthwhile. Departing employees, especially in a startup, leave with important IP in their heads, including a lot of know-how about the business. Replacing them is non-trivial. An exodus en masse could very well permanently cripple the business.
Describing it as a "printer" implies some detail to the technique that would be missing from your description. And no, it's not really like making a car.
I know zilch about materials science, but I have to wonder how these structures would hold up as they get large. Will they be like concrete, or like sandstone? or like particle board...
I was responding to the parent post, not to the story. Read it again.
I think I have a pretty good idea of your philosophical leanings on the subject of labor law, but I'll say this anyway for other readers. "Right-to-work" laws should really be termed "opportunity-to-work" laws, because the economic theory is that by lowering the potential risks for employers, they will be more willing to take those risks. Yes, you have the "right" to be fired immediately, but without those laws you might never have had the job in the first place.
"Contractor" in this sense does not necessarily mean "independent contractor". Most "government contractors" are employees of firms and get paid on W-2s like anybody else. The "contract" is government with firm, not government with individual.
Making them regular old unionized state workers makes them incredibly hard to fire, among other things. so you end up with a higher head count than you might otherwise, because you have to hire people to carry the dead weight.
Doubtful. Who is going to pay for all of these replacement body parts? We can barely pay for the Viagra and Lipitor we get now.
Motivations for employees are always selfish - that's basic compensation theory. The trick is to try to align the rewards with the goals for the company or organization that you wish to accomplish, so that in serving their selfish interests, the employees are also serving the interests of the organization.
You have to consider the personal incentives for managers with budget authority. If you manage a shrinking department, there's no rewards for spending less money. Your prestige and responsibility shrink, and your career path dwindles. For better or for worse, all of the incentives for budget managers are towards bigger and bigger spending allocations.
You might be surprised at what agencies and have requirements for the most computing resources. Sure, DoD and NASA are high on the list, but so are IRS, SSA, CMS. Operational agencies that serve most Americans have HUGE amounts of data to manage.
You must not be aware of how many government data centers are already privately operated.
If the government gets big enough, it won't be able to stand up at all... kinda like one of those 800 lb fat people on Maury who can't get out of bed and has to have breakfast trucked in and shoveled... never mind. **shudder**
The government's job in this case is not to duplicate the testing done by Toyota engineers, but rather to provide oversight and verify that Toyota's engineers ARE doing it, to a degree of completeness and correctness that satisfies statutes and regulations. Clearly that task requires substantial technical expertise, but it's not the same task.
I can promise you have independent verification and validation contracts are bread & butter in the federal contracting world. The federal government has made huge strides in the direction of outsourcing almost all technical expertise, and quite a bit of management expertise (google "federal PMO contracts" for lots of random examples). The few civil servants left in many agencies are a kind of sheepherders, managing vast groups of contractors.
Thanks, that occupied a good 15 minutes out of my work day.
You don't need technology to do this. All you need is a network of government informants.
I can look forward to a Google Phobos?
just FYI, from the wikipedia article:
"S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for public key encryption and signing of e-mail encapsulated in MIME."
http://en.wikipedia.org/wiki/S/MIME