One other note: this works as long as you have any semi-private place at work where you can put the drive. It could be a desk drawer or something else. I don't see any reason why there is a requirement that it be stored at a site you "own and control". Just put heavy AES encryption on the backups as I do, just in case the drive falls into other hands. Then your only real risk is financial loss of the disk itself. I know other people at my workplace that all do the same thing. And if you want heavier security and don't mind paying for it and taking extra time, a safe deposit box at a local bank is a good fallback, and certainly much cheaper then a colo. You'd have to have pretty deep pockets for colo space and the bandwidth to back up to and from that location, making it impractical for most people.
A colocation center? Do the initial backup locally then use something to replicate changes in the future?
Too painful and expensive. This can be made much simpler. I have two sets of backups I keep: an internal 2 TB hard drive for local backups, and a pair of 1 TB external drives for off site backups. Every Monday, I unplug the external drive at my house as I head out the door for work. At work, I put it into my locker and retrieve the other drive, which I bring home with me when I leave for the day. When I get home, I plug it into the vacant USB and power cord, and presto: it's online and ready for backup! My software (I use ShadowProtect Desktop) does a full backup of the machine every Sunday night, so Monday mornings it is always ready for the swap again. It's a very quick and painless way to have offsite backups without spending a fortune on comparatively slow Internet bandwidth.
The communications market is so "deregulated" that monopolism takes over, with deliberate barriers to entry placed by noncompete agreements and dirty tactics. And yet so many people think anarcho-libertarian, "laissez faire" deregulation will somehow make their lives better in every aspect.
That's not true at all. Try opening up a new cable company in your local town, or opening up a new power plant and running new wires to all the houses. Oh, that's right, you can't, because the government has decided that it would be inefficient to have more than one set of power lines, or water lines, or cable lines, or telephone lines, etc, going into a single home. So they allow one provider to service the whole town and be a government sanctioned monopoly. That's hardly "deregulation"... in fact, it's the epitome of the government regulating and controlling everything.
They're built by lowest bidders Serco and QSS Inc. Neither an American company. If they had decided to hire Americans to do this job, they would have had a very large pool of qualified and skilled workers from which to choose.
I disagree. I've worked with American, Indian and Chinese developers, and you know what the number one issue is? It's not lack of qualification, it's lack of testing! Most developer HATE testing no matter which country they are from, and therefore don't do it. And you know what kind of testing they really, really, really hate? Load Testing! It is especially hated because you can't just generate large loads from your laptop... you actually have to set up dedicated load balancing agents to really simulate a large load. Setting up the load testing environment takes quite a bit more effort than most other kinds of testing, such as unit testing. So, it gets skipped all the time, and bites project after project. And I guarantee you load testing was never done on this site, and probably would have been skipped even if Americans were doing it, unless they were especially conscientious and hard working developers, which most aren't.
I'd be interested to know what line of work you do, programming wise. My experience tells me that a lot of programming that is being done is meant to be powerful and meant to be built quickly. Running quickly and with low tolerance for faults is a little less important because very few things are mission critical. While anathema to the academic, it demands a certain skill set, which is the ability to very quickly assimilate new arbitrary knowledge about libraries, software, and code, that the programmer hasn't seen before. The result is a fragile sort of knowledge that often lacks formality and granularity but is sufficient enough to accomplish a task very quickly.
There is definitely some truth to what you say. I started out as a programmer in 2007 but quit programming and went into infrastructure/systems engineering after my first programming job precisely because of what you just described. I got into computers and programming initially because I had a desire to cultivate a deep understanding of the computer and how it worked, and I discovered very quickly that modern programming is all about the latest "shiny new framework" and slapping something together as quickly as you can (the politically correct term for this is, of course, agile). That's all well and good, and there is a definite place for that because speed to market is very important in a competitive environment. And a lot of people really seem to enjoy that style of rapid development at the expense of truly understanding what is going on. But it wasn't for me.
That said, there is also truth to what the grandparent said when he posted this:
I wasn't saying a programmer should write everything from scratch every day. But if you don't know how to, you're SOL and at everybody else's mercy when something goes wrong. You're costing your company money. Because things inevitably go wrong.
Those people with the "fragile sort of knowledge" are at everyone's mercy when things go wrong. They literally have no clue where to go next or how to troubleshoot if things don't work exactly right. And in my company, it's me and others at the heart of the infrastructure devops teams who they come to when things go down, because we are the ones who actually understand how it all really works underneath the high level frameworks and scaffolding. We understand the networking, the HTTP, the authentication protocols, languages and everything else at the bottom. The best programmers, at least at this company, are the ones who did those rapid development jobs for just a few years and moved as quickly as they could into backend "Developer Center of Excellence" type teams, where their job is to support other developers, create standards, write programs designed for the infrastructure as a whole and therefore learn the deeper points of the technologies.
Conclusion: The grandparent is right when he says that the best programmers understand how things work under the hood and could write these objects from scratch if they had to. But you are right when you say that not all programmers have to be at that level in order to do something effective. Both types are essential to organization, because you have to have people fast enough to outmaneuver the competition, but also really solid people in reserve to back up the quick and dirty developers when things go wrong.
are cells Turing machines?
Yes, they are. They are state machines (proteins, chemical substances, and other such items keeping state) with a semi-infinite tape (ie - DNA).
No, sorry, but this is a fractally wrong statement to make. With sufficient curiousity, you will be dedicated to learning as much as you can. The drive to learn will push you where you need to go. Intelligence merely sets the speed by which you'll arrive. Your over-emphasis on intelligence is elitism; It's suggesting that if you can't be "smart enough", you shouldn't be in science.
This is a nice thought, but patently untrue. It's like saying that anyone can be an NFL football player, and your level of physical talent and ability merely dictates the speed by which you'll arrive. But that isn't actually true. Without sufficient "speed" you'll never arrive, and it's the same in science. You may have the curiosity, but without the mental talent and aptitude you'll be forever beaten to new discoveries by all the other scientists who not only have your curiousity, but also the mental aptitude you lack.
Sure, anyone can play football and throw the ball around, but most don't have what it takes to play in the NFL. Similarly, everyone can learn the basics about the scientific method and learn to think in an empirical way, but not everyone has what it takes to be a professional scientist, or to make major scientific discoveries like Einstein did.
Yet I would argue true geniuses need the support structure the Steve Jobs/Edisons/etc can provide to realize their potential.
I think this is right on, but it extends much farther than just "true geniuses". Personally, I'm one of those highly technical people who are really good at the nitty gritty details of making technology work, but as I've learned more about myself over the years I've realized that I need to make sure I stay in the technical arena, rather than going into management or some of the purely "visionary" roles, because the high level of technical talent I have doesn't mean I have a commensurately high level of visionary talent. I've learned that a good idea for me is to seek out the visionary types in my organization and try to get myself onto their projects, because they can supply overall direction and I can provide a really good technical implementation. I'm not trying to compare myself to Woz, Einstein, Tesla, or these other geniuses, because I'm not nearly that smart, but I do think the principle extends to me an many others. There is an almost symbiotic relationship that can be had when technical people realize they need visionaries, and visionaries respect and treat the technical people well. I think it applies to much of industry, not just super geniuses and super visionaries.
Lazy voters here just complete the part of the ballot that selects the President (which is by far the highest profile election on the paper) and submit that.
I think that's a good thing. If the only thing they are following is the presidential race, then that's all they should vote on. I personally won't vote on any race I haven't thoroughly researched, as I want to leave the decision up to those who know something about it. (For the record, I do try to research every race beforehand, but if there's some judge up for election and I know nothing about their legal opinions, what grounds do I have for deciding whether they should stay or not?)
Personally, I wish more people would vote only on races they understand, rather than voting straight "R" or "D" on every race. I'm a Republican, but there are from time to time completely corrupt Republicans that should not be re-elected. Also, their are unprincipled Republicans that likewise should not be re-elected. And I know the same is true on the Democrat side... the re-election of Jesse Jackson Jr. even though the FBI said he committed felony campaign finance fraud would be a great example. If you don't know anything about it, leave it blank.
99% of the "agile" efforts I've seen used agile as an excuse to avoid whatever part of the SDLC annoyed them most.
This is totally true. And I think the main part of the SDLC they try to avoid is planning. I've both been a developer and had developers writing automation code as projects for me as an infrastructure engineer, and the most frequent abuse is zero planning. And that's the thing that makes agile seem endless to users like me. The developers keep having to rewrite everything every dang sprint because they didn't put enough planning into the architecture to make it flexible enough to meet the requirements. And speaking of requirements gathering, that consisted of getting a bunch of user stories and then diving straight into coding, rather than taking the time to get into the true details and really flesh what the users needed. Which is another agile abuse.
I'm honestly getting pretty darn sick of agile, because even with the defects in other paradigms, I think better software was developed more quickly. It's amazing what a little up front thought (which most other paradigms call for) will get you. And again, a lot of people will argue that it's not agile that is the problem, but the abuse of agile. I agree in theory that abuse of agile is the problem, but since 99% of projects seem to do agile wrong in practice, it might be time to throw the baby out with the bath water and get a new paradigm that isn't so easily misinterpreted.