OS and Applications Development will fight eternally, in my experience. It's nothing to do with "development" vs "operations" or automation vs manual configuration - the OS guys want to lock everything down and use standard systems, and the applications guys want to open everything up and do everything custom and bespoke. How do you resolve that conflict?
I've always been lucky enough to work places where the app team's senior architects had actually heard of the concept of "security" and were able to beat the rest of their teams into line.
Then again, none of these places were Windows shops -- from what you say, it sounds like there may be some cultural differences. Application developers in a Java shop or a Python shop don't generally want the OS to do anything other than stay out of their way, which is a far cry from what you describe.
You could, but I'd rather start with PostgreSQL. As long as you have log archival, your backup process looks like this: Run pg_start_backup(), rsync the actual live database while it's still being written to, run pg_stop_backup(), done.
(Restore? Copy those files back, start up the database, and it replays operations from the archive logs to get back from the restored dump to the current point in time... or a point in time you specify, if you'd rather replay to, say, just before someone ran a UPDATE with a missing WHERE clause).
Development does that? So developers know all about DNS, firewalls and OS installation? Errrr, no. They think they do and they think it's easy, but they simply don't. Those that do get burned. Badly.
And that's why you have a crossdiciplinary team -- DevOps -- taking care of that stuff rather than foisting it on the application developers.
Good DevOps folks tend to also be system-level developers -- ideally people who know everything from the kernel level up -- as well as having a good chunk of system administration under the belt. It's a rare breed, sure, but that's why we make the big bucks.:)
Backup as well? How fabulous. In reality it's sys admins who should be encroaching on developer turf, not the other way around, and the reason why this Devops cargo cult crap has come into existence is because developers now need to know about it, they don't want to and as such they want to pretend it's something they can take over. Why? Because it doesn't matter how many lines of code you write, if it doesn't work in production no one cares and you won't get paid.
Developers "want to pretend"? Riiight.
Last place I was at it was a 2-man team (in the devops group -- app development was of course much, much larger) writing software to automate the configuration of 7 datacenters worldwide, the largest of them being well over 1000 hosts (for a storage- and search-centric application). And it worked, beautifully -- we scaled up our DCs to cope with customer demand without needing to scale up our operations-team headcount, which was exactly the thing we were investing in devops to do.
You look at the folks who are big names -- Google, Twitter, Disqus, Flickr -- and they're all investing in devops, because it gives repeatable, scalable results. You want to go stick your head in the sand? Be my guest. Me? I like being able to spin up a new cluster (or double the size of an existing one) by clicking a few buttons and letting the automation do the rest.
A few people want to be able to put Puppet on their resume so it (or something else) will probably show up somewhere sooner or later.
Personally, I can't recommend Puppet -- it makes simple things simple, but when you get to the point where you want to do hard things, you end up needing to make use of integration points that aren't so well-thought-through... whereas Chef has extra primitives ("data bags", search, &c) that are well-integrated and more power in the language (real Ruby, as opposed to a limited DSL) making it easier to do your own thing without someone having to have built in syntax for the purpose. Not saying there's anything you can't make Puppet do if you're willing to work at it, but it's going to be more work.
Specifically I mean the enthusiasm around it, as if it's some kind of revelation. Well, I work in an environment where everyone is a developer and everyone has root. Maybe that's not as common as I thought.
It's not so common in my experience -- especially in shops where growth happened before they started putting real work into infrastructure automation, so they started hiring out traditional sysadmins without development skillsets.
Even in places that started early, though, trusting your entire development staff with root is something that I've never seen happen -- and for good reason. One of those employers dealt with medical records, another with customers' email archives, another had credit card numbers pass through our hands... in every one of those cases we were audited by people who wanted to know, and with very good reason, exactly who had access to our production infrastructure, and why they had it, and what measures we took to make sure that nobody retained such access after they left. It's pretty hard to be sure that someone who's had root hasn't slipped in a backdoor somewhere, so keeping that list to a minimum is critical just for operational security reasons. (Beyond opsec, there's also the matter of avoiding the case where you have developers playing cowboy in production... but that's a different discussion).
There's also a Fortune 50 one of my former employers was bought by that was so particular about separation of responsibilities that talking to someone on the other side of the wall was verboten without going through channels. One person having access to both source control and production was utterly unthinkable. Now, that is just silliness, but giving root to everyone in your development staff -- particularly if you're doing enough dev work to have that be a significant number of individuals -- is something that doesn't scale too well.
it's about operations being automated via tools maintained by development, using traditional development methodologies. That's pretty much how it is where I work, it's been that way for as long as anyone remembers (at least 15 years). But no one ever called it DevOps.
15 years is quite some time -- by any chance were y'all an early adopter of CFEngine? That's the only toolkit I can think of under an OSS license for doing OS-level configuration programatically that was available at that time, unless y'all were using in-house tools.
[Personally -- It was about 10 years ago I evaluated CFEngine, decided I didn't like it, and wrote my own tools for OS-level configuration (sadly, proprietary); 4 years ago I was hired into a Puppet shop; 2 years ago I jumped ship for Chef, and have been a relatively happy camper since... though I'm anxiously awaiting better orchestration capabilities; Zookeeper and Noah are steps in the right direction, but need better integration with the rest of the stack].
My view is that giving this concept a label and then going on to "over define" it serves only to introduce yet another dogma.
There's utility to the label. First off, it gives a name to the people inside development who write tools for automating OS-level configuration. Second, it means that when I see a job opening described as a "devops position", I have a pretty good idea of what kind of skillset is going to be required, and I can be reasonably confident that someone with a "devops" entry on their resume knows how to think in terms of idempotent operations, notification triggers, and all the other primitives that go into modern config automation tools.
Folks can talk about "dogma" and "cults" all they like, but as long as a word or phrase has meaning and utility to those that use it, it's not so likely to be given up.
The sysadmins like virtual machines; they make life easier. What they don't like is developers telling them how to do their job. Internal software doesn't come with instructions, it comes with a coworker making demands about server resources, DNS/firewall/network configuration, licensing and backup requirements, etc... Not all those developer requests will be reasonable or correct; devs make mistakes too.
Thing is, that's not how it works in a mature devops shop.
Development writes the code that set up the DNS, the firewalls, even the kickstart files (or whatever your local equivalent is) that control OS installation. If development's code doesn't work, developers' dev VMs and QA's environments break first, because they're configured just the same way.
Licensing servers? Development writes the code that manages them. Backup? Development writes the code that automates it.
Or... well, in practice, a small group of people with deep sysadmin experience managed under the development group writes that code. Ops kicks tickets up to development when things break, but for the most part their layer of importance gets thinner -- hands-and-eyes on the physical servers, assigning roles to hardware they spin up using the dev-provided tools, diagnosing easy bugs and writing tickets (or pulling a developer in to diagnose the hard ones), etc.
I don't think DevOps is new or non-traditional. The *label* might have been invented recently but it's not like Dev and Ops never worked together before. Everyone should know something about everyone else's job, or maybe (from your post)IT and Development should maintain an awareness of each others' status. I've seen a bunch, they all pretty much mean the same thing, and they're all one sentence.
Huh?
DevOps isn't about mere communication or awareness -- it's about operations being automated via tools maintained by development, using traditional development methodologies.
That's a far tighter integration than what's traditional, even in a shop without a wall between the groups.
And how do you know the new VM won't have the same problem? If you never know what went wrong and fix the actual problem you will just end up restarting VMs constantly.
Sure -- but that's a thing to be replicated and fixed as a development task, not a critical-production-maintenance one. Not like you can't keep a copy of the bad VM around for inspection.
More to the point, if you're Doing It Right, the "spin up a new VM" process involves applying configuration-as-code, not replicating off some handcrafted mystical golden image that's been tweaked who-knows-what way, so every change that was ever made to the system since its OS installation? You have that change (in a version-controlled source tree), you know its state, you've replicated exactly that same configuration in your staging environment, and so bizarre one-off bugs don't happen so much to start with.
Regardless, new parking space can be made any time and there is no cost to deliver it.
First off, "can be made any time" is... not so clear. Hundreds of millions of dollars to build a garage, remember, and that's after acquiring the land (and in dense urban spaces, where parking demand is high, acquiring the land can be the most expensive part). Roads with high rises and expensive hotels aren't exactly cheap to widen either. Keep in mind, it's not the total amount of parking in the city that counts, but the total amount of parking in the high-demand area.
Second, even if there's no cost to deliver -- the cost to build gets spread over time regardless (via paying off municipal bonds over time) -- once it's built, the city is still paying. The question, then, is whether those bonds are paid by the people who actually use the resource, or spread to everyone via the general fund. The "make everyone pay for something only a few people use" approach strikes me as something which has been... ahem... remarkably out of favor in the American right wing recently.
Third, you're again ignoring the argument which you make so clearly regarding water -- that adjusting price based on availability is important to encourage conservation.
I'm kicking myself for not drawing a stronger parallel here --
In a free market the costs would steadily increase as the water is used and reservoirs go dry (very visible, to me anyway as a recreational boater on those reservoirs). The increasing rates would result in increased awareness of usage and of course most folks would use significantly less as rates increased during droughts.
This is exactly why parking should have market pricing as well! When downtown parking is scarce -- a "drought" -- hourly parking charges encourage turnover or alternate means of transport -- conservation.
The system you're saying you want -- wherein parking is first-come-first-serve all-you-can-eat -- is exactly like the thing you're saying is bad -- wherein utilities are unable to raise water rates when demand is high, resulting in supply being exhausted.
To compare a parking space to water is a poor choice as they are quite different.
The economic concept of scarcity applies to both -- and this is precisely what my argument hinges on.
High-demand parking spaces are also scarce. That the costs to produce them and maintain them are paid on a less-frequent basis and amortized over time doesn't make those costs disappear, no matter how much you might prefer to believe the contrary.
Ignoring other factors, charging for parking will eliminate some portion of the customer base for businesses in that town or city, and result in less business.
Absolutely not, because increased turnover means more business from the same number of spaces.
Charging at all, or different rates at different times eliminates some portion of potential customers, like myself.
Sure -- but if it eliminated too many potential customers, the spots would be empty. So -- if it's even possible to get an 85% fill rate with paid parking (and there's no question that it is!), the minority of customers who object on philosophical grounds are moot.
If I must reverse engineer something before I can understand it, then I must first acquire one or more samples of the item I wish to reverse engineer.
Have you ever actually been part of a company with something you think is unique and valuable and are trying to protect from reverse engineering?
A much bigger concern than a competitor buying your unit directly is one of your legitimate customers being on friendly terms with a competitor and giving them access to borrow the device for a weekend or send some engineers by to prod at it. If you're intending to be in the $FOO industry, you'd best have a network of contacts there, after all, or how would you expect to sell your device or get customer feedback even if you built it?
I pay for by consumption for my usage of minicipal water and other utilities, as it should be. I see what you're getting at though I don't necessarily agree with it. Part of a functional and useful public road system is parking in certain areas that would logically require parking.
It's also not a very "functional and useful" water utility if you don't actually get any water to consume -- yet you're fine with water not actually being delivered unless you pay use fees on top of the base infrastructure maintenance costs, whereas that same logic doesn't hold for public parking in places where it's scarce.
I can agree with some of the points you make about active policing with high fines -- I hope that technical measures such as the ones discussed in this article can help provide an alternative to that. It'd be considerably easier if anyone with a recognised in-state plate could be billed an uninflated rate after-the-fact (with the caveat that this would need to include overhead for the billing system itself) rather than the existing guess-how-long-you'll-be-or-pay-a-fine approach. I'd also like to see this kind of technical measure make the pricing more effective at following demand -- there's no reason to charge for parking when a street is empty, whereas in the restaurant district at 9pm, if pricing isn't high there'll be nowhere to park.
It's in the best interests of not just the city but also folks who own businesses on a street to have prime parking used by high-turnover customers rather than individuals working nearby. Appropriately calibrated hourly parking fees increase turnover while leaving utilisation levels high (ideally ~85% rather than the 100% too-quickly reached without them), and thereby maximise the value of this public resource.
Charging additional for use of a resource already paid for is wrong.
First, "already paid for" is... a very controversial choice of words. Transportation funding is expensive and ongoing, and maintenance of preexisting roads is a large part of that -- they don't just sit there forever once they're built any more than electric lines do.
Second, what you're asking for is a effectively a subsidy -- an expensive public resource (and making the roads wider to accommodate parking is considerably more expensive than building roads for through traffic only -- even ignoring the cost of rights-of-way, which often dwarfs those of construction in areas where parking availability is an issue) to be given away for free.
You talk about wanting smaller government -- but when it comes to a specific function of government that you care about, suddenly it's a ${DEITY}-given right to get your "free" parking. Do you also hold that municipally-owned electric and water utilities should be all-you-can-eat free-of-charge first-come-first-serve?
Funny thing about the public roads with tax dollars that you fund -- other people pay those taxes too.
I was not long ago at a public meeting about putting in some bike lanes on a neighborhood road with peak parking utilization measured well under 40%; this required taking out parking on one side of the street. The road in question was a great candidate -- its position relative to a major highway makes it a poor thoroughfare for motorists (who are subject to a one-way-only turn preventing them from using it to get towards the north central side of town) but a great one for cyclists (who, by virtue of the privilege of getting off the bike and turning into a pedestrian at that major intersection, are able to cross in a direction that motorists legally cannot).
We had a very vocal minority of neighbors talking about "their" parking that "they" paid for. City street, paid for by city property and sales taxes? Guess what -- folks commuting by bike pay those taxes too. Perhaps even moreso, since we're not sending a good chunk of each paycheck to a typically out-of-state bank funding a typically foreign-made vehicle, and thus have more money left to spend locally.
Point is? The other people you're sharing this parking space with also pay the same taxes you do. Does this give you more right than they have? If not, why should you have the ability to take advantage of first-come-first-serve rules to get unlimited use of a very scarce resource -- thereby blocking others, who already paid in those same taxes, from access to the same?
[For the uninitiated -- gas taxes, vehicle registration, and the like pay for highways, not city streets].
If the people could trust the city, we wouldn't need to deal with this shit all over the world.
News flash: In places where it matters, parking spaces are a scarce resource. Giving scarce resources away for free first-come-first-serve leads to some people hogging them and others not getting any.
I want parking to be expensive, because it means that in the rare occasions when I take my car downtown (and I do mean rare -- most of the time I bike or take the train), I can actually find a space. This also means that the city's incentives for folks to use lower-impact transportation (such as free parking for motorcycles, scooters and bicycles -- all of which use far less of this scarce resource) carry considerably more weight.
"Greed"? Market forces regulating distribution of a scarce resource isn't greed -- it's economics... and when technical solutions like this one let the market rate float with demand, it means that the economics are able to do a better job of matchmaking supply and demand.
To me, the difference between porn and nudity is when the subject is being treated as an object, for sexual gratification. In other words, when it's exploiting stereotypes. And while I don't mind nudity, on or off stage, porn is a bit different because I don't like the way in which women are portrayed (usually - there are exceptions).
There are a few fairly interesting cases to explore while we're discussing the moral field. One of these is that where the woman owns the company and has full control over the works created.
There's very little room to argue that Camille Crimson is being degraded -- she works only with her other half, retains strong creative control, produces work which is obviously artistic and creative in nature (with brilliant lighting, use of focus, musical selection, editing, &c -- doing much of all these things herself), and gives every appearance (not just in her work but interviews, articles and the like) of both enjoying her work and being in a mutually caring relationship with her partner.
More interesting, and perhaps more ambiguous, is the case of Joanna Angel -- some of whose work, if it were produced by someone with less control over her situation and working conditions, might give an impression of coercion (even if only by way of financial necessity). However -- Joanna owns her own production company (which employs many others in the same field); the knowledge that she does only the things she wants to do, and in exactly the way she wants to do them, puts the works she creates in a substantially different light.
So would you like your mother to be displayed as a whore, for all to have? That is porn.
But not all porn. Camille Crimson, whom I mentioned above, is certainly not "displayed as a whore" in any of her work -- she's a tender, playful person who respects and is respected by her partner. That said, there's no question that her work is "porn", as opposed to "nudity" -- to argue to the contrary would, I think, be delving into a "No True Scotsman" case in which case something not degrading must not be porn, no matter how much its intent includes titillation.
There's a huge amount of bad porn, to be sure; there is also "high art" created and promulgated to shock, and I don't make a habit of supporting that either. The trick, then, is to find media one can support. Reading blogs along the lines of The Joy of Eclecticity (a tumblr with as many thought-provoking quotes as it has happy naked people of varying genders and inclinations) and its ilk may or may not leave me titillated, but they almost always leave me feeling better about humanity.
One final note in closing -- one of my friends used to work in an adult-oriented business, in a position some might consider objectifying or degrading. By doing so, she set herself up in a secure position for the rest of her life -- she owns her own house, paid in full; if her husband were to divorce her, he would be the one homeless. All in all, the end result of this early career choice was entirely empowering -- and I have serious qualms about those who would limit a person's choices in the name that person's protection. So, going back to answering the question asked earlier in this thread -- yes, I would be entirely supportive with someone I know and care about working in porn, so long as they're doing so on their own terms, for their own benefit, and absent external coercion.
People don't accept a wage they can't live off of, though.
Look at what starting pay is at a fast food joint in NYC or Sunnyvale. The market forces there mean that "minimum wage" isn't the minimum wage -- nobody can live off of it, so you can't hire someone for that little, even for fast food.
The same applies to higher-end jobs as well -- what people are willing to work for varies with what it costs to maintain a given standard of living.
You mean just like MyISAM? It has it's [sic] uses.
If we grant that a substantial set of use cases where a full-scale, non-embedded, out-of-process database is called for but relational integrity is unimportant exist (something I grant only for the sake of the ongoing argument), that still leaves people who try to use it in situations outside that set. I once took maintainership of an accounting system for car dealerships built on top of a "database" without relational integrity. Cases where bugs in the software resulted in orphaned records and numbers that didn't add up were legion.
Saying you don't need relational integrity is right up there with saying you don't need bind variables because your hand-built escaping code is good enough. There might be cases where hand-built escaping is good enough, but encouraging J. Random Slashdot Reader to take that approach means it's going to be abused... and I assure you, the person who built that accounting system considered himself an expert.
no guarantees of that data has been flushed to disk when a COMMIT comes back
Interesting documentation. Reading the links -- suffice to say that MySQL's multi-master clusters are vastly less safe than Oracle RAC. Depending on after-the-fact conflict resolution rather than having proper locking... really? (And with respect to NDB not supporting fsync() before reporting a commit complete -- yes, I can provide a link for that. Being in a cluster isn't good enough -- sometimes you lose a rack, or a full DC).
Yes, it's cheaper. Yes, it might be good enough for someone. But if someone needs RAC features enough to pay $50K in licensing fees for a tiny cluster, NDB just ain't gonna' cut it. And if I'm handling medical data (which I was last time I deployed RAC), I'm not going to risk massive liability by deciding that I can afford to get a COMMIT back before data is not just ACKed by multiple nodes but sitting on a platter.
PostgreSQL 9.1's synchronous streaming replication is a sane middle ground -- it's not multi-master, but it actually preserves the same semantics and performance characteristics (durability semantics being the most critical of those -- but at the same time, needing to rewrite everywhere your code uses savepoints or autoincrement or relies on referential integrity exceptions because you're switching to a database backend that doesn't support them isn't any fun either) you'd have in a non-clustered environment. Having it available six years ago would have saved me one helluva lot of money.
Provided whomever sets the cluster up knows what they are doing and doesn't half-ass it, it works just fine.
Really? Compared to RAC, wherein moving to a cluster involves no loss of semantics, using NDB looks a whole lot like half-assing it already.
If you're using MySQL and need to scale further for some reason, then just use MySQL Cluster. There's no need to change entirely.
By "MySQL Cluster", you're referring to the configuration that requires NBD, right? No foreign keys, no guarantees of that data has been flushed to disk when a COMMIT comes back, and you actually think this might be a serious alternative for folks considering Oracle?!
If they oppose it, then it is a clear proof that their motivations are not as clear as they wish us to believe.
You're forgetting about Hanlon's Razor.
The larger concern I have here -- a position taken that anyone in disagreement must be duplicitous, without even allowing an opposing argument to be first presented, is no way to have a serious discussion.
This is, indeed, great research. Why muddy the waters with a bunch of flamebaiting?
I don't have a cite either -- but back when I worked in medical software, we put a huge amount of resources into fax integration because faxes were presumed secure, whereas other electronic content had to be encrypted before transmission.
Slashdot Mirror
I've always been lucky enough to work places where the app team's senior architects had actually heard of the concept of "security" and were able to beat the rest of their teams into line.
Then again, none of these places were Windows shops -- from what you say, it sounds like there may be some cultural differences. Application developers in a Java shop or a Python shop don't generally want the OS to do anything other than stay out of their way, which is a far cry from what you describe.
You could, but I'd rather start with PostgreSQL. As long as you have log archival, your backup process looks like this: Run pg_start_backup(), rsync the actual live database while it's still being written to, run pg_stop_backup(), done.
(Restore? Copy those files back, start up the database, and it replays operations from the archive logs to get back from the restored dump to the current point in time... or a point in time you specify, if you'd rather replay to, say, just before someone ran a UPDATE with a missing WHERE clause).
And that's why you have a crossdiciplinary team -- DevOps -- taking care of that stuff rather than foisting it on the application developers.
Good DevOps folks tend to also be system-level developers -- ideally people who know everything from the kernel level up -- as well as having a good chunk of system administration under the belt. It's a rare breed, sure, but that's why we make the big bucks. :)
Developers "want to pretend"? Riiight.
Last place I was at it was a 2-man team (in the devops group -- app development was of course much, much larger) writing software to automate the configuration of 7 datacenters worldwide, the largest of them being well over 1000 hosts (for a storage- and search-centric application). And it worked, beautifully -- we scaled up our DCs to cope with customer demand without needing to scale up our operations-team headcount, which was exactly the thing we were investing in devops to do.
You look at the folks who are big names -- Google, Twitter, Disqus, Flickr -- and they're all investing in devops, because it gives repeatable, scalable results. You want to go stick your head in the sand? Be my guest. Me? I like being able to spin up a new cluster (or double the size of an existing one) by clicking a few buttons and letting the automation do the rest.
Personally, I can't recommend Puppet -- it makes simple things simple, but when you get to the point where you want to do hard things, you end up needing to make use of integration points that aren't so well-thought-through... whereas Chef has extra primitives ("data bags", search, &c) that are well-integrated and more power in the language (real Ruby, as opposed to a limited DSL) making it easier to do your own thing without someone having to have built in syntax for the purpose. Not saying there's anything you can't make Puppet do if you're willing to work at it, but it's going to be more work.
It's not so common in my experience -- especially in shops where growth happened before they started putting real work into infrastructure automation, so they started hiring out traditional sysadmins without development skillsets.
Even in places that started early, though, trusting your entire development staff with root is something that I've never seen happen -- and for good reason. One of those employers dealt with medical records, another with customers' email archives, another had credit card numbers pass through our hands... in every one of those cases we were audited by people who wanted to know, and with very good reason, exactly who had access to our production infrastructure, and why they had it, and what measures we took to make sure that nobody retained such access after they left. It's pretty hard to be sure that someone who's had root hasn't slipped in a backdoor somewhere, so keeping that list to a minimum is critical just for operational security reasons. (Beyond opsec, there's also the matter of avoiding the case where you have developers playing cowboy in production... but that's a different discussion).
There's also a Fortune 50 one of my former employers was bought by that was so particular about separation of responsibilities that talking to someone on the other side of the wall was verboten without going through channels. One person having access to both source control and production was utterly unthinkable. Now, that is just silliness, but giving root to everyone in your development staff -- particularly if you're doing enough dev work to have that be a significant number of individuals -- is something that doesn't scale too well.
15 years is quite some time -- by any chance were y'all an early adopter of CFEngine? That's the only toolkit I can think of under an OSS license for doing OS-level configuration programatically that was available at that time, unless y'all were using in-house tools.
[Personally -- It was about 10 years ago I evaluated CFEngine, decided I didn't like it, and wrote my own tools for OS-level configuration (sadly, proprietary); 4 years ago I was hired into a Puppet shop; 2 years ago I jumped ship for Chef, and have been a relatively happy camper since... though I'm anxiously awaiting better orchestration capabilities; Zookeeper and Noah are steps in the right direction, but need better integration with the rest of the stack].
There's utility to the label. First off, it gives a name to the people inside development who write tools for automating OS-level configuration. Second, it means that when I see a job opening described as a "devops position", I have a pretty good idea of what kind of skillset is going to be required, and I can be reasonably confident that someone with a "devops" entry on their resume knows how to think in terms of idempotent operations, notification triggers, and all the other primitives that go into modern config automation tools.
Folks can talk about "dogma" and "cults" all they like, but as long as a word or phrase has meaning and utility to those that use it, it's not so likely to be given up.
Thing is, that's not how it works in a mature devops shop.
Development writes the code that set up the DNS, the firewalls, even the kickstart files (or whatever your local equivalent is) that control OS installation. If development's code doesn't work, developers' dev VMs and QA's environments break first, because they're configured just the same way.
Licensing servers? Development writes the code that manages them. Backup? Development writes the code that automates it.
Or... well, in practice, a small group of people with deep sysadmin experience managed under the development group writes that code. Ops kicks tickets up to development when things break, but for the most part their layer of importance gets thinner -- hands-and-eyes on the physical servers, assigning roles to hardware they spin up using the dev-provided tools, diagnosing easy bugs and writing tickets (or pulling a developer in to diagnose the hard ones), etc.
Huh?
DevOps isn't about mere communication or awareness -- it's about operations being automated via tools maintained by development, using traditional development methodologies.
That's a far tighter integration than what's traditional, even in a shop without a wall between the groups.
Sure -- but that's a thing to be replicated and fixed as a development task, not a critical-production-maintenance one. Not like you can't keep a copy of the bad VM around for inspection.
More to the point, if you're Doing It Right, the "spin up a new VM" process involves applying configuration-as-code, not replicating off some handcrafted mystical golden image that's been tweaked who-knows-what way, so every change that was ever made to the system since its OS installation? You have that change (in a version-controlled source tree), you know its state, you've replicated exactly that same configuration in your staging environment, and so bizarre one-off bugs don't happen so much to start with.
First off, "can be made any time" is... not so clear. Hundreds of millions of dollars to build a garage, remember, and that's after acquiring the land (and in dense urban spaces, where parking demand is high, acquiring the land can be the most expensive part). Roads with high rises and expensive hotels aren't exactly cheap to widen either. Keep in mind, it's not the total amount of parking in the city that counts, but the total amount of parking in the high-demand area.
Second, even if there's no cost to deliver -- the cost to build gets spread over time regardless (via paying off municipal bonds over time) -- once it's built, the city is still paying. The question, then, is whether those bonds are paid by the people who actually use the resource, or spread to everyone via the general fund. The "make everyone pay for something only a few people use" approach strikes me as something which has been... ahem... remarkably out of favor in the American right wing recently.
Third, you're again ignoring the argument which you make so clearly regarding water -- that adjusting price based on availability is important to encourage conservation.
I'm kicking myself for not drawing a stronger parallel here --
This is exactly why parking should have market pricing as well! When downtown parking is scarce -- a "drought" -- hourly parking charges encourage turnover or alternate means of transport -- conservation.
The system you're saying you want -- wherein parking is first-come-first-serve all-you-can-eat -- is exactly like the thing you're saying is bad -- wherein utilities are unable to raise water rates when demand is high, resulting in supply being exhausted.
The economic concept of scarcity applies to both -- and this is precisely what my argument hinges on.
High-demand parking spaces are also scarce. That the costs to produce them and maintain them are paid on a less-frequent basis and amortized over time doesn't make those costs disappear, no matter how much you might prefer to believe the contrary.
Indeed, buying a single private parking space in high-demand areas can be a six-figure investment... and cities routinely pay hundreds of millions for parking garages. Even amortized over the lifespan of the space, we're not talking about negligible expense... yet you're insisting you have an entitlement to get them for free.
Absolutely not, because increased turnover means more business from the same number of spaces.
Sure -- but if it eliminated too many potential customers, the spots would be empty. So -- if it's even possible to get an 85% fill rate with paid parking (and there's no question that it is!), the minority of customers who object on philosophical grounds are moot.
Have you ever actually been part of a company with something you think is unique and valuable and are trying to protect from reverse engineering?
A much bigger concern than a competitor buying your unit directly is one of your legitimate customers being on friendly terms with a competitor and giving them access to borrow the device for a weekend or send some engineers by to prod at it. If you're intending to be in the $FOO industry, you'd best have a network of contacts there, after all, or how would you expect to sell your device or get customer feedback even if you built it?
It's also not a very "functional and useful" water utility if you don't actually get any water to consume -- yet you're fine with water not actually being delivered unless you pay use fees on top of the base infrastructure maintenance costs, whereas that same logic doesn't hold for public parking in places where it's scarce.
I can agree with some of the points you make about active policing with high fines -- I hope that technical measures such as the ones discussed in this article can help provide an alternative to that. It'd be considerably easier if anyone with a recognised in-state plate could be billed an uninflated rate after-the-fact (with the caveat that this would need to include overhead for the billing system itself) rather than the existing guess-how-long-you'll-be-or-pay-a-fine approach. I'd also like to see this kind of technical measure make the pricing more effective at following demand -- there's no reason to charge for parking when a street is empty, whereas in the restaurant district at 9pm, if pricing isn't high there'll be nowhere to park.
It's in the best interests of not just the city but also folks who own businesses on a street to have prime parking used by high-turnover customers rather than individuals working nearby. Appropriately calibrated hourly parking fees increase turnover while leaving utilisation levels high (ideally ~85% rather than the 100% too-quickly reached without them), and thereby maximise the value of this public resource.
First, "already paid for" is... a very controversial choice of words. Transportation funding is expensive and ongoing, and maintenance of preexisting roads is a large part of that -- they don't just sit there forever once they're built any more than electric lines do.
Second, what you're asking for is a effectively a subsidy -- an expensive public resource (and making the roads wider to accommodate parking is considerably more expensive than building roads for through traffic only -- even ignoring the cost of rights-of-way, which often dwarfs those of construction in areas where parking availability is an issue) to be given away for free.
You talk about wanting smaller government -- but when it comes to a specific function of government that you care about, suddenly it's a ${DEITY}-given right to get your "free" parking. Do you also hold that municipally-owned electric and water utilities should be all-you-can-eat free-of-charge first-come-first-serve?
Funny thing about the public roads with tax dollars that you fund -- other people pay those taxes too.
I was not long ago at a public meeting about putting in some bike lanes on a neighborhood road with peak parking utilization measured well under 40%; this required taking out parking on one side of the street. The road in question was a great candidate -- its position relative to a major highway makes it a poor thoroughfare for motorists (who are subject to a one-way-only turn preventing them from using it to get towards the north central side of town) but a great one for cyclists (who, by virtue of the privilege of getting off the bike and turning into a pedestrian at that major intersection, are able to cross in a direction that motorists legally cannot).
We had a very vocal minority of neighbors talking about "their" parking that "they" paid for. City street, paid for by city property and sales taxes? Guess what -- folks commuting by bike pay those taxes too. Perhaps even moreso, since we're not sending a good chunk of each paycheck to a typically out-of-state bank funding a typically foreign-made vehicle, and thus have more money left to spend locally.
Point is? The other people you're sharing this parking space with also pay the same taxes you do. Does this give you more right than they have? If not, why should you have the ability to take advantage of first-come-first-serve rules to get unlimited use of a very scarce resource -- thereby blocking others, who already paid in those same taxes, from access to the same?
[For the uninitiated -- gas taxes, vehicle registration, and the like pay for highways, not city streets].
News flash: In places where it matters, parking spaces are a scarce resource. Giving scarce resources away for free first-come-first-serve leads to some people hogging them and others not getting any.
I want parking to be expensive, because it means that in the rare occasions when I take my car downtown (and I do mean rare -- most of the time I bike or take the train), I can actually find a space. This also means that the city's incentives for folks to use lower-impact transportation (such as free parking for motorcycles, scooters and bicycles -- all of which use far less of this scarce resource) carry considerably more weight.
"Greed"? Market forces regulating distribution of a scarce resource isn't greed -- it's economics... and when technical solutions like this one let the market rate float with demand, it means that the economics are able to do a better job of matchmaking supply and demand.
There are a few fairly interesting cases to explore while we're discussing the moral field. One of these is that where the woman owns the company and has full control over the works created.
There's very little room to argue that Camille Crimson is being degraded -- she works only with her other half, retains strong creative control, produces work which is obviously artistic and creative in nature (with brilliant lighting, use of focus, musical selection, editing, &c -- doing much of all these things herself), and gives every appearance (not just in her work but interviews, articles and the like) of both enjoying her work and being in a mutually caring relationship with her partner.
More interesting, and perhaps more ambiguous, is the case of Joanna Angel -- some of whose work, if it were produced by someone with less control over her situation and working conditions, might give an impression of coercion (even if only by way of financial necessity). However -- Joanna owns her own production company (which employs many others in the same field); the knowledge that she does only the things she wants to do, and in exactly the way she wants to do them, puts the works she creates in a substantially different light.
But not all porn. Camille Crimson, whom I mentioned above, is certainly not "displayed as a whore" in any of her work -- she's a tender, playful person who respects and is respected by her partner. That said, there's no question that her work is "porn", as opposed to "nudity" -- to argue to the contrary would, I think, be delving into a "No True Scotsman" case in which case something not degrading must not be porn, no matter how much its intent includes titillation.
There's a huge amount of bad porn, to be sure; there is also "high art" created and promulgated to shock, and I don't make a habit of supporting that either. The trick, then, is to find media one can support. Reading blogs along the lines of The Joy of Eclecticity (a tumblr with as many thought-provoking quotes as it has happy naked people of varying genders and inclinations) and its ilk may or may not leave me titillated, but they almost always leave me feeling better about humanity.
One final note in closing -- one of my friends used to work in an adult-oriented business, in a position some might consider objectifying or degrading. By doing so, she set herself up in a secure position for the rest of her life -- she owns her own house, paid in full; if her husband were to divorce her, he would be the one homeless. All in all, the end result of this early career choice was entirely empowering -- and I have serious qualms about those who would limit a person's choices in the name that person's protection. So, going back to answering the question asked earlier in this thread -- yes, I would be entirely supportive with someone I know and care about working in porn, so long as they're doing so on their own terms, for their own benefit, and absent external coercion.
People don't accept a wage they can't live off of, though.
Look at what starting pay is at a fast food joint in NYC or Sunnyvale. The market forces there mean that "minimum wage" isn't the minimum wage -- nobody can live off of it, so you can't hire someone for that little, even for fast food.
The same applies to higher-end jobs as well -- what people are willing to work for varies with what it costs to maintain a given standard of living.
If we grant that a substantial set of use cases where a full-scale, non-embedded, out-of-process database is called for but relational integrity is unimportant exist (something I grant only for the sake of the ongoing argument), that still leaves people who try to use it in situations outside that set. I once took maintainership of an accounting system for car dealerships built on top of a "database" without relational integrity. Cases where bugs in the software resulted in orphaned records and numbers that didn't add up were legion.
Saying you don't need relational integrity is right up there with saying you don't need bind variables because your hand-built escaping code is good enough. There might be cases where hand-built escaping is good enough, but encouraging J. Random Slashdot Reader to take that approach means it's going to be abused... and I assure you, the person who built that accounting system considered himself an expert.
Interesting documentation. Reading the links -- suffice to say that MySQL's multi-master clusters are vastly less safe than Oracle RAC. Depending on after-the-fact conflict resolution rather than having proper locking... really? (And with respect to NDB not supporting fsync() before reporting a commit complete -- yes, I can provide a link for that. Being in a cluster isn't good enough -- sometimes you lose a rack, or a full DC).
Yes, it's cheaper. Yes, it might be good enough for someone. But if someone needs RAC features enough to pay $50K in licensing fees for a tiny cluster, NDB just ain't gonna' cut it. And if I'm handling medical data (which I was last time I deployed RAC), I'm not going to risk massive liability by deciding that I can afford to get a COMMIT back before data is not just ACKed by multiple nodes but sitting on a platter.
PostgreSQL 9.1's synchronous streaming replication is a sane middle ground -- it's not multi-master, but it actually preserves the same semantics and performance characteristics (durability semantics being the most critical of those -- but at the same time, needing to rewrite everywhere your code uses savepoints or autoincrement or relies on referential integrity exceptions because you're switching to a database backend that doesn't support them isn't any fun either) you'd have in a non-clustered environment. Having it available six years ago would have saved me one helluva lot of money.
Really? Compared to RAC, wherein moving to a cluster involves no loss of semantics, using NDB looks a whole lot like half-assing it already.
By "MySQL Cluster", you're referring to the configuration that requires NBD, right? No foreign keys, no guarantees of that data has been flushed to disk when a COMMIT comes back, and you actually think this might be a serious alternative for folks considering Oracle?!
Only by a missing comma.
Read it as "If I want good games, companies like EA..."
It matters for purposes of discussing motivations.
If one doesn't care about motivations, one need not discuss them.
You're forgetting about Hanlon's Razor.
The larger concern I have here -- a position taken that anyone in disagreement must be duplicitous, without even allowing an opposing argument to be first presented, is no way to have a serious discussion.
This is, indeed, great research. Why muddy the waters with a bunch of flamebaiting?
I don't have a cite either -- but back when I worked in medical software, we put a huge amount of resources into fax integration because faxes were presumed secure, whereas other electronic content had to be encrypted before transmission.
They do enjoy specially protected legal status.
It does.