I'm not overly worried about Player cutting into their marketshare; frankly, I think VMware Server poses a bigger risk in the small-customer space (though the limited snapshot support pretty much puts a ceiling on that one's use). That said, I'm presently employed by a Fortune 100, and we're perfectly happy to pay for VMware ESX -- which is what they're trying to leverage customers of lower-end products towards anyhow.
For the moment, virtualization software has a substantial lock-in effect; the APIs for doing automation for Xen, VMware and VirtualBox (for instance) are quite far from being compatible with each other (and VirtualBox and VMware go as far as having their own proprietary container formats). As such, a company developing internal automated testing software wants to target a dominant environment (so as to avoid needing to rework this infrastructure later). However, folks like Red Hat are sponsoring libvirt to provide a way for Xen, KVM and other supported backends (which should include VMware at some point) to share a single set of management infrastructure, making the network effect weaker -- so getting mindshare now should provide a hedge against commoditization later.
Personally, I'm thoroughly in favor of Red Hat's bid to open up virtualization; VMware has done good research (and turned a good profit) in the past, but letting them (or anyone) rest on their laurels in the future is suboptimal for society as a whole; if VMware's products remain thoroughly superior (which they may well do -- see their recent research into record-and-replay), let them continue to compete effectively in an environment where switching virtualization product backends is a trivial affair.
You mean "their" business model, not "there" business model; the latter word refers to location, while the former refers to possession.
They're VMware. They have plenty of products they charge (lots and lots of) money for; giving away low-end freebies isn't going to hurt their bottom line much, as anyone running a QA department will want to have the management tools &c. that come with the full releases, without needing a developer to write local toolage (which can be even more expensive, after opportunity cost for the staff involved is taken into account).
I generally agree with you that overuse of stored procedures is a Bad Thing... but (having worked with a rockstar-class DBA for the last four years or so) I've also seen some very effective uses made of them in a context where core business logic is still kept in the app proper; think code specifically for database maintenance, upgrades, restructuring and support. I advocate for cautious use, thus, rather than outright avoidance.
Not some software; all software. That's not a very convenient way to describe it, to be sure -- but when you get under the hood and look at what the CPU is doing, it's all -- completely -- 100% math.
Yes, you _can_ do those things, but what you get is a RDBMS-centric application design. Suitable for some tasks, less so for others.
There's nothing DB-specific at all about prepared statements; any database and ORM worth thinking about supports them; given the performance and security improvements (one Oracle application I saw spent a full 50% of the database's CPU time doing soft parses because the developers didn't use prepared statements), there's no excuse for failing to use them. For stored procedures that's less true -- but porting between databases isn't that much trouble if they're judiciously applied, and any decent ORM will be able to work with them. Stored procedures should be used only where they make sense; prepared statements always make sense.(*)
(*) - or close enough to be a rule of thumb for anyone who doesn't know enough to understand when/why this is or is not true.
WTF! You can write server side code but don't know how to do the basic javascript stuff.
Screw "basic"; if you're building an AJAX site, you want your javascript to be all-singing and all-dancing... and entirely reliable.
Writing for Java, you have static compile-time checking; you have 1001 different unit tests framework and code coverage frameworks and other tools you can use to help write reliable, production-quality software. For JavaScript, you have jack squat -- not even compile-time static checking. GWT solves that gap, providing a way to apply the same quality control tools and processes you have for your server-side code on your client-side code. As such, it's an extremely valuable tool in your toolkit.
I'm trying to think of something clever to say but I've got nothing, so I'll just say it. What the hell is wrong with you? When I see a voicemail from my wife I almost immediately push 7 to delete it. "The girlfriend" doesn't have anything to say, so it's never allowable. The fact that they leave a voicemail at all is the root of the problem.
The question could be turned around: What is wrong with you, to marry someone so uninteresting (and about whom you care so little) that you don't care what they have to say?
Uninteresting is a bug -- a serious, showstopper bug. I'm paying for my wife's law classes right now partially to decrease the chances of "uninteresting" ever happening. How is it that you get to a point where you don't care about the root cause (not being interested in your wife's communications) and just complain about a symptom (those uninteresting communications occurring)? Think about it for a bit.
I don't generally criticize people's personal relationships -- but dude, you went there first. A long-term committed relationship with someone you don't want to hear from just isn't a good place to be.
I live in Austin, and hate traveling with a passion. Whether not my income level makes me part of the market they're intended to target, Cricket makes sense for me.
That said -- yes, the iPhone has some compelling technical advantages over anything Cricket offers; those advantages, however, are significantly offset by the delta in price and customer service.
Here in Austin, elsewhere is Cricket Wireless. In Dallas, I think it's MetroPCS. Sure, the national carriers screw everyone over... but the smaller ones tend to be a little more up-front with their customers.
I think you took the parent much too seriously. At least, I hope you took the parent much too seriously; my impression was that it was made in jest, and not respective of the parent's true positions.
Now -- I'm putting my 20-something Libertarian hat on for the rest of this post, as I think that (of all those I wear) it's most relevant.
Personal responsibility is a Good Thing; it's only when the mechanism of state is used to enforce one particular view of what "personal responsibility" entails that there come problems. The Golden Rule isn't going anywhere -- people can understand that things they don't want others to do to them shouldn't be encouraged, and that they shouldn't do such things themselves. It's principally victimless crimes which we consider outdated -- and only inasmuch as they are considered criminal, not necessarily to the extent that they're considered good ideas: I may not want the police to be breaking down doors to arrest potheads, but there's no way in hell I want my kids toking up on a regular basis (and I'm not going to set a bad example for them -- or, at present, harm my focus on my career -- by doing so myself); while I may not teach them "right from wrong" in exactly the same way you would, there's no way I'd be a good parent if I didn't teach that actions have consequences, and that those consequences are important, and thus that intelligent people just Don't Do Certain Things. The folks in my social group who are having kids have cleaned up parts of their lives that would otherwise have set a bad example -- so again, when it becomes important, we tend to do the right thing.
So -- don't worry. The generation after you might see things a little differently, but we're not (by and large) the raving irresponsible asshats like the those discussed in this story, and we don't like those people either. We'll figure things out -- your parents were worried about your generation too, and you turned out all right... right?
Any military has subcomponents which save the lives of the military personnel themselves. Further, while it hasn't happened recently, once in a while there's on occasion for a defensive war, in which case the military is charged with saving the lives of members of the civilian populace it protects (or allies of the same).
To be sure, these goals (of saving lives... that one cares about) are addressed by destroying other lives... but even so, it most certainly can be fairly stated that military apparatus can be used for saving lives.
Are you saying the DMCA grants immunity to hosts as long as no one tries to take them to court? Whoop dee freakin doo. That's some kind of immunity, let me tell you.
The DMCA grants immunity to hosts as long as they follow the procedure it lays out. It's a very real and legitimate (and useful) thing.
That procedure lays out a takedown notice and counter-notice process; the individual who put the content up (not the host) can counter-notify the host to the effect that they're asserting that their content is legal (and willing to be on the line if it's not), at which point the host can put it back up; if it's not legal, that individual (not the host) is on the hook. The point is that as long as they follow procedure, the host is never on the hook... but yes, that requires that they take things down immediately when requested, though they can put them up again given a counternotice (and can't be asked to take the same thing down again that they've already been given a counternotice for).
There are also penalties (specified, again, by the DMCA) for those who send takedown notices without good will -- and the EFF has prosecuted a few of those successfully.
It's a legitimate argument: One of the factors in weighing whether something is fair use is whether it impacts the commercial market for that product. If Viacom creates a commercial market for such clips, that's a strike against folks making fair use of clips in that same way.
Of course, there are other factors as well (if one is using the clips for social commentary and taking only as much as they need for that purpose, for instance, that's a strong factor in favor of fair use... but reducing demand for the commercial version does indeed factor in).
I think this is a silly subtopic in a discussion of XML, but just to jump in here...
What is the actual rate of undetected corrupt (not lost -- those are reliably detected) packets that reach TCP layer, and how it compares with undetected error rate of those computers' RAM? We are not just dealing with extremely small, even though nonzero probabilities -- it's a multiplication of very small probabilities.
Depends on where your failures are, but sometimes it's quite high; I recall a time within the last ten years I had to redownload an ISO from the exact same server several times to get the file without the md5sum on the transferred file coming out wrong -- and on comparison between the attempts it turned out to be a single byte here or there that was flipped. Adding an extra layer of data integrity protection (IPsec) resolved the issue (and I had no further issues after that point), but data corruption making it past the TCP-layer checksum really can and does happen in practice.
If you're building an easier-to-parse and more-space-efficient language that isn't XML, why bother trying to make it look vaguely like XML? All you're doing is adding confusion and setting up for failure when someone tries to feed in a document that isn't compliant.
Part of the point of using XML is being able to use any generator with any parser and rely on third-party validation tools; if you're dealing with a restricted subset, that's off the table, and you might as well do something completely different (like what Google is here).
What size datacenter did you manage? Was it heterogenous? How many DR plans have you built and tested? Have you designed and deployed a multi-site driectory service? What about networking? Have you set up a multi-homed BGP site?
Somewhere between two and three hundred hosts at peak, split between QA, dev, IT, production support and client systems; yes; three (counting the internal and customer DR plans as distinct -- which they most certainly were); yes (we used the whole AFS+LDAP+Kerberos stack heavily); yes (though as we grew I frequently leaned on folks with network admin experience where appropriate); no (see prior parenthetical).
Can we call this thread done? I think it's just degenerating into e-peen, and probably not worth either of our time.
I fully agree that double-checking every patch is insane. Even if it's not anything you're ever going to do, though, someone on your IT staff should know enough C to have the ability; using that ability to double-check vendor patches is ridiculous, but using it to diagnose and fix critical bugs that your vendor is dragging their feet on isn't.
Developers are terrible sysadmins, and sysadmins are terrible developers. I hire both, and believe me, the hard and especially soft skills required for one to succeed in one position are not found with those required for the other.
If you think you're a good sysadmin AND a good developer, well, you're probably mediocre in both areas.
My current position (like the last few years with my prior employer) has a significant focus on writing software that automates system administration tasks. The first startup I worked for had me developing tools used to QA their custom Linux distribution (in addition to porting and bugfixing other peoples' software to crosscompile for all the embedded targets supported by that distribution and doing the odd bit of kernel work)... and I've certainly worn the sysadmin hat long enough to be comfortable there.
If you honestly don't think it's possible to live in both worlds -- or at least to usefully and profitably occupy a niche that requires a foot in each -- send me an email and I'll give you references to call.
If I came across as trolling for flames, perhaps I communicated badly. This reply (by Danny Rathjens) posed the argument far better. I certainly don't hold that everyone on staff should have that skillset -- but certainly, someone should... and if you have only one sysadmin on staff, it falls to them to be that someone.
I should have specified senior sysadmins, to be sure -- there's no reason to be that picky about everyone on staff. OTOH, the whole point of having senior people is to have someone who can dig into and eventually solve any issue that comes up -- and that means understanding what's under the abstractions. Addressing your comparison, software isn't as reliable as hardware is these days; maybe in ten years this won't be the case, but right now having someone available who can dig into the operating system (or your app server, or any layer inbetween) is damned useful.
Oh, hush. I'm not (and have never claimed to be) all that good -- the preexisting guru here is way the hell better than I am, and the only thing I need to do to be put in my place is to ask one of my old friends from the embedded-system days what they're working on presently -- many of them are hardcore kernel folks now (a few both were and are Linux architecture maintainers; those folks grok modern CPUs in a way I probably never will). I didn't count those people in the "about five" count because they're too busy to do system administration, and I don't have certain knowledge that they ever picked it up (they were on the kernel development side of the house even back in the day, while I was userland but occasionally moonlighted in their world).
I'm not arguing that putting folks with that kind of skillset to use doing system administration is in any way productive -- but having sysadmins who can grok, debug and extend other peoples' C and do light kernel work when necessary vastly increases the flexibility of your IT department and allows independence in cases where one might otherwise be at a vendor's mercy.
IMHO, ACPI bugs is not someone what a sysadmin does - maybe figuring out that it is a an ACPI problem and then opening an appropriate support cal with the server vendor.
Depends. If the vendor (who's also a major investor) loaned you hardware which they haven't rolled out to your country yet, and the agreement under which they're funding your operation compels you to support their equipment, and they happen not to officially support the operating system you run on...
Let's say that life in a startup can be complicated sometimes, and leave it at that.
Honestly, how many people do you know who fit the bill you've described, and how did they capture that much expertise?
To answer your questions in order: Five come to mind immediately; mostly while working in embedded systems (it's a very good way to get exposed to the whole stack at once); currently, the systems engineering team at Dell MessageOne, though most of my career has been startups doing fun and interesting things (and the guru-type who convinced me to take my current job started back when MessageOne was startup-phase). "Fun and interesting" is a reasonably effective substitute for high-paying, all things considered.
Slashdot Mirror
I'm not overly worried about Player cutting into their marketshare; frankly, I think VMware Server poses a bigger risk in the small-customer space (though the limited snapshot support pretty much puts a ceiling on that one's use). That said, I'm presently employed by a Fortune 100, and we're perfectly happy to pay for VMware ESX -- which is what they're trying to leverage customers of lower-end products towards anyhow.
For the moment, virtualization software has a substantial lock-in effect; the APIs for doing automation for Xen, VMware and VirtualBox (for instance) are quite far from being compatible with each other (and VirtualBox and VMware go as far as having their own proprietary container formats). As such, a company developing internal automated testing software wants to target a dominant environment (so as to avoid needing to rework this infrastructure later). However, folks like Red Hat are sponsoring libvirt to provide a way for Xen, KVM and other supported backends (which should include VMware at some point) to share a single set of management infrastructure, making the network effect weaker -- so getting mindshare now should provide a hedge against commoditization later.
Personally, I'm thoroughly in favor of Red Hat's bid to open up virtualization; VMware has done good research (and turned a good profit) in the past, but letting them (or anyone) rest on their laurels in the future is suboptimal for society as a whole; if VMware's products remain thoroughly superior (which they may well do -- see their recent research into record-and-replay), let them continue to compete effectively in an environment where switching virtualization product backends is a trivial affair.
You mean "their" business model, not "there" business model; the latter word refers to location, while the former refers to possession.
They're VMware. They have plenty of products they charge (lots and lots of) money for; giving away low-end freebies isn't going to hurt their bottom line much, as anyone running a QA department will want to have the management tools &c. that come with the full releases, without needing a developer to write local toolage (which can be even more expensive, after opportunity cost for the staff involved is taken into account).
I generally agree with you that overuse of stored procedures is a Bad Thing... but (having worked with a rockstar-class DBA for the last four years or so) I've also seen some very effective uses made of them in a context where core business logic is still kept in the app proper; think code specifically for database maintenance, upgrades, restructuring and support. I advocate for cautious use, thus, rather than outright avoidance.
Not some software; all software. That's not a very convenient way to describe it, to be sure -- but when you get under the hood and look at what the CPU is doing, it's all -- completely -- 100% math.
There's nothing DB-specific at all about prepared statements; any database and ORM worth thinking about supports them; given the performance and security improvements (one Oracle application I saw spent a full 50% of the database's CPU time doing soft parses because the developers didn't use prepared statements), there's no excuse for failing to use them. For stored procedures that's less true -- but porting between databases isn't that much trouble if they're judiciously applied, and any decent ORM will be able to work with them. Stored procedures should be used only where they make sense; prepared statements always make sense.(*)
(*) - or close enough to be a rule of thumb for anyone who doesn't know enough to understand when/why this is or is not true.
Screw "basic"; if you're building an AJAX site, you want your javascript to be all-singing and all-dancing... and entirely reliable.
Writing for Java, you have static compile-time checking; you have 1001 different unit tests framework and code coverage frameworks and other tools you can use to help write reliable, production-quality software. For JavaScript, you have jack squat -- not even compile-time static checking. GWT solves that gap, providing a way to apply the same quality control tools and processes you have for your server-side code on your client-side code. As such, it's an extremely valuable tool in your toolkit.
Fair enough; I did indeed take some of your words more seriously than they were intended to be read. Please accept my apologies.
The question could be turned around: What is wrong with you, to marry someone so uninteresting (and about whom you care so little) that you don't care what they have to say?
Uninteresting is a bug -- a serious, showstopper bug. I'm paying for my wife's law classes right now partially to decrease the chances of "uninteresting" ever happening. How is it that you get to a point where you don't care about the root cause (not being interested in your wife's communications) and just complain about a symptom (those uninteresting communications occurring)? Think about it for a bit.
I don't generally criticize people's personal relationships -- but dude, you went there first. A long-term committed relationship with someone you don't want to hear from just isn't a good place to be.
I live in Austin, and hate traveling with a passion. Whether not my income level makes me part of the market they're intended to target, Cricket makes sense for me.
That said -- yes, the iPhone has some compelling technical advantages over anything Cricket offers; those advantages, however, are significantly offset by the delta in price and customer service.
Here in Austin, elsewhere is Cricket Wireless. In Dallas, I think it's MetroPCS. Sure, the national carriers screw everyone over... but the smaller ones tend to be a little more up-front with their customers.
I think you took the parent much too seriously. At least, I hope you took the parent much too seriously; my impression was that it was made in jest, and not respective of the parent's true positions.
Now -- I'm putting my 20-something Libertarian hat on for the rest of this post, as I think that (of all those I wear) it's most relevant.
Personal responsibility is a Good Thing; it's only when the mechanism of state is used to enforce one particular view of what "personal responsibility" entails that there come problems. The Golden Rule isn't going anywhere -- people can understand that things they don't want others to do to them shouldn't be encouraged, and that they shouldn't do such things themselves. It's principally victimless crimes which we consider outdated -- and only inasmuch as they are considered criminal, not necessarily to the extent that they're considered good ideas: I may not want the police to be breaking down doors to arrest potheads, but there's no way in hell I want my kids toking up on a regular basis (and I'm not going to set a bad example for them -- or, at present, harm my focus on my career -- by doing so myself); while I may not teach them "right from wrong" in exactly the same way you would, there's no way I'd be a good parent if I didn't teach that actions have consequences, and that those consequences are important, and thus that intelligent people just Don't Do Certain Things. The folks in my social group who are having kids have cleaned up parts of their lives that would otherwise have set a bad example -- so again, when it becomes important, we tend to do the right thing.
So -- don't worry. The generation after you might see things a little differently, but we're not (by and large) the raving irresponsible asshats like the those discussed in this story, and we don't like those people either. We'll figure things out -- your parents were worried about your generation too, and you turned out all right... right?
Any military has subcomponents which save the lives of the military personnel themselves. Further, while it hasn't happened recently, once in a while there's on occasion for a defensive war, in which case the military is charged with saving the lives of members of the civilian populace it protects (or allies of the same).
To be sure, these goals (of saving lives... that one cares about) are addressed by destroying other lives... but even so, it most certainly can be fairly stated that military apparatus can be used for saving lives.
How so?
The DMCA grants immunity to hosts as long as they follow the procedure it lays out. It's a very real and legitimate (and useful) thing.
That procedure lays out a takedown notice and counter-notice process; the individual who put the content up (not the host) can counter-notify the host to the effect that they're asserting that their content is legal (and willing to be on the line if it's not), at which point the host can put it back up; if it's not legal, that individual (not the host) is on the hook. The point is that as long as they follow procedure, the host is never on the hook... but yes, that requires that they take things down immediately when requested, though they can put them up again given a counternotice (and can't be asked to take the same thing down again that they've already been given a counternotice for).
There are also penalties (specified, again, by the DMCA) for those who send takedown notices without good will -- and the EFF has prosecuted a few of those successfully.
It's a legitimate argument: One of the factors in weighing whether something is fair use is whether it impacts the commercial market for that product. If Viacom creates a commercial market for such clips, that's a strike against folks making fair use of clips in that same way.
Of course, there are other factors as well (if one is using the clips for social commentary and taking only as much as they need for that purpose, for instance, that's a strong factor in favor of fair use... but reducing demand for the commercial version does indeed factor in).
I think this is a silly subtopic in a discussion of XML, but just to jump in here...
Depends on where your failures are, but sometimes it's quite high; I recall a time within the last ten years I had to redownload an ISO from the exact same server several times to get the file without the md5sum on the transferred file coming out wrong -- and on comparison between the attempts it turned out to be a single byte here or there that was flipped. Adding an extra layer of data integrity protection (IPsec) resolved the issue (and I had no further issues after that point), but data corruption making it past the TCP-layer checksum really can and does happen in practice.
If you're building an easier-to-parse and more-space-efficient language that isn't XML, why bother trying to make it look vaguely like XML? All you're doing is adding confusion and setting up for failure when someone tries to feed in a document that isn't compliant.
Part of the point of using XML is being able to use any generator with any parser and rely on third-party validation tools; if you're dealing with a restricted subset, that's off the table, and you might as well do something completely different (like what Google is here).
Somewhere between two and three hundred hosts at peak, split between QA, dev, IT, production support and client systems; yes; three (counting the internal and customer DR plans as distinct -- which they most certainly were); yes (we used the whole AFS+LDAP+Kerberos stack heavily); yes (though as we grew I frequently leaned on folks with network admin experience where appropriate); no (see prior parenthetical).
Can we call this thread done? I think it's just degenerating into e-peen, and probably not worth either of our time.
I fully agree that double-checking every patch is insane. Even if it's not anything you're ever going to do, though, someone on your IT staff should know enough C to have the ability; using that ability to double-check vendor patches is ridiculous, but using it to diagnose and fix critical bugs that your vendor is dragging their feet on isn't.
My current position (like the last few years with my prior employer) has a significant focus on writing software that automates system administration tasks. The first startup I worked for had me developing tools used to QA their custom Linux distribution (in addition to porting and bugfixing other peoples' software to crosscompile for all the embedded targets supported by that distribution and doing the odd bit of kernel work)... and I've certainly worn the sysadmin hat long enough to be comfortable there.
If you honestly don't think it's possible to live in both worlds -- or at least to usefully and profitably occupy a niche that requires a foot in each -- send me an email and I'll give you references to call.
If I came across as trolling for flames, perhaps I communicated badly. This reply (by Danny Rathjens) posed the argument far better. I certainly don't hold that everyone on staff should have that skillset -- but certainly, someone should... and if you have only one sysadmin on staff, it falls to them to be that someone.
I should have specified senior sysadmins, to be sure -- there's no reason to be that picky about everyone on staff. OTOH, the whole point of having senior people is to have someone who can dig into and eventually solve any issue that comes up -- and that means understanding what's under the abstractions. Addressing your comparison, software isn't as reliable as hardware is these days; maybe in ten years this won't be the case, but right now having someone available who can dig into the operating system (or your app server, or any layer inbetween) is damned useful.
Oh, hush. I'm not (and have never claimed to be) all that good -- the preexisting guru here is way the hell better than I am, and the only thing I need to do to be put in my place is to ask one of my old friends from the embedded-system days what they're working on presently -- many of them are hardcore kernel folks now (a few both were and are Linux architecture maintainers; those folks grok modern CPUs in a way I probably never will). I didn't count those people in the "about five" count because they're too busy to do system administration, and I don't have certain knowledge that they ever picked it up (they were on the kernel development side of the house even back in the day, while I was userland but occasionally moonlighted in their world).
I'm not arguing that putting folks with that kind of skillset to use doing system administration is in any way productive -- but having sysadmins who can grok, debug and extend other peoples' C and do light kernel work when necessary vastly increases the flexibility of your IT department and allows independence in cases where one might otherwise be at a vendor's mercy.
Depends. If the vendor (who's also a major investor) loaned you hardware which they haven't rolled out to your country yet, and the agreement under which they're funding your operation compels you to support their equipment, and they happen not to officially support the operating system you run on...
Let's say that life in a startup can be complicated sometimes, and leave it at that.
To answer your questions in order: Five come to mind immediately; mostly while working in embedded systems (it's a very good way to get exposed to the whole stack at once); currently, the systems engineering team at Dell MessageOne, though most of my career has been startups doing fun and interesting things (and the guru-type who convinced me to take my current job started back when MessageOne was startup-phase). "Fun and interesting" is a reasonably effective substitute for high-paying, all things considered.