So, Slashdot can sell ads. People may or may not block them. They can also sell subscriptions so we can see "articles in the future" and whatever else that gets you. But, really, the value in a site like Slashdot is its users -- even the crazy ones like the "you're all cows" guy.
Seriously, it wouldn't be Slashdot without the trolls - it would be a bland, boring place. My early reaction to the comments to this story was actually "where's APK? I hope he's OK". There's a real sense of community here that keeps people coming back (no, not the "we're all friends" nonsense, no real community is like that either). Mess with it and the community dies.
But fortunately Dice seemed to get that - heck, I should probably change my sig now.
That's the problem with paywalls - people are only going to pay for original content, not news aggregation, and a lot of what news sites do is just aggregation of AP stories and stories from other sources. How sure can you be that yor produce enough original content to survive a paywall? Maybe the paywall easy to bypass hedges your bet.
Busty Babes in Bikinis playing volleyball decrying one another if their latest Texmex burger is "Tex" or "Mex" with two guys in the stand watching hungrily, monster burgers in their hands, saying "You going to tell them that it's both?" "Nope," says the other as he takes the kind of bite you might while still trying to watch TV while eating.
Sounds pretty misogynistic to me...
Sounds awesome to me. People having fun and generally enjoying themselves - the thing the neo-puritans hate the most.
Oh, I agree completely: Unidoce isn't made easy by C++, and it damn well should be. Especially, I want extremely optimized library code for getting Unicode meta-data about codepoints, and for validation. I'm sure ICU is good and all, but this deserves to be part of the language (with fully-baked support for std::algorithms working codepoint-wise, since std::algorithms has some great stuff hidden inside).
so yes: there are plenty of reasons to have a hand written destructor that actually does something
Yes, but my point is, only do it in a narrow set of carefully-reviewed library primitives. You don't really need very many - various OS "handles" and anything specific to the code base that needs unique handling (can't be built from other primitives, e.g., you're doing slab allocation and have a special "free" action).
For example, if you have a rich "file" class with many methods, it should have an empty destructor. But it should have as a member a primitive that wraps a FILE or Windows HANDLE object that only knows how to call fclose or CloseHandle.
To many, the phrase "non-trivial destructor" informally means "no interesting code written in the destructor definition", not the formal meaning in the standard, which is I think what you're talking about? In any case, I was talking about the former.
The reason for empty destructors is that destructors that actually clean up resources are usually a bad idea. (Debugging-related stuff in destructors is different.) The "allocate in the constructor, clean up in the destructor" pattern was a natural evolution from well-written C code. If you were used to "allocate at the top of the function, clean up at the bottom", it was the obvious better approach. But it's still just as error-prone (just fewer places for errors), and the fact that the destructor doesn't get called if the constructor throws isn't broadly internalized by coders (and is my least-favorite intermittent resource leak to run down).
Having very small resource-specific classes, similar in functionality to auto_ptr or unique_ptr (just managing a file handle or whatever instead of memory allocation) is the better answer. Only clean up a resource in a class whose only purpose is to clean up a resource. Using those primitives as members in other classes, or as local variables, is as idiot-proof as C++ gets.
The resource-leak headaches saved by difference in approach is amazing when junior coders are involved, it's really a difference in kind. And it's dead easy to police in code-reviews. The last time I did C++ we had a single, templated class in library code, and nowhere else in the code base was a non-trivial destructor allowed. (Odd cases like adding an object to a global list, and removing it on destruction could be managed within this system.)
To the OP: it might not be a bad idea. Though if you're considering C and Rust, you really ought to have C++ on the table. It's got the same resource footprint as the other two. You can be much less foot-shooty in C++ than C if you use modern style (no loss of efficiency either), and the tooling is much more mature than Rust.
There's really no reason ever to use C over C++ if you have a C++ compiler available.
So many bad books on C++ make this very hard for people to learn. I haven't yet found a good site for explaining why and how to have empty destructors for all but a few carefully-reviewed library classes (this is more than just RAII, or perhaps it's the golden version of it). Heck, it'd be nice to find a good guide to the latest standard, with a bunch of new anti-foot-shooting tools, plus "concepts" to allow much more sane templating for performance.
Heck, even explaining how to use std::strings and vectors with no performance loss vs C would be a wonderful thing in a "learn C" website or book. 9plus a nudge to switch to hashmaps instead of the old maps) This stuff isn't complicated in practice, and it belongs in introductory works.
Thanks - I just learned about Linux Mint Debian Edition, wonderfully Ubuntu-cancer-free. I'll have to dig up a VMware image, or ISO, this weekend and give it a spin.
What's a good distro to run XFCE on top of? Ubuntu has played it's own share of dirty tricks (e.g. sending your file searches to the mothership), and I'm looking for something better.
Has MS done this with a server OS? Does WIn10 Pro work this way (not a rhetorical question - I honestly don't know)?
If this is just the free consumer OS, and the OS for workstations and the OS for servers doesn't do this shit, then your rant is way off base, and all the geeks can just run the business version. Does anyone know if Pro does this same shit?
Why do you think Google doesn't live in your datacenter? They're amazing subtle and invasive. Why do you think this will apply to MS enterprise products? Is is even in WIn10 Pro? Any reason to think it will be in any of their business products, from server to Exchange to anything at all?
In the real world, "Art" is defined by culture, not by someone's capacity for "artistic intent." There are plenty of people in the world who want to "express" themselves in their "art," but no one pays any attention to them because what these "artists" are doing seems weird or obnoxious or even insane to most people. In essence, there is a failure to communicate. Art is a cultural product that requires both a creator and an audience who can find this "expressive" stuff which you talk about and can value it.
That's definitely art: it's bad art. Unless it's so incoherent it isn't even an "expression". But that's not usually the case - usually it's clear what's going on, it just sucks.
BTW, I don't buy that mere "aesthetic engagement" is sufficient for art. Just because something's painted on canvas with skill doesn't make it art! It also has to communicate some idea or emotion. The Mona Lisa is art because of the smile, not the paint. Robotically playing the piano with no emotion isn't art unless the lack of emotion was actually the artistic intent. Painting a great counterfeit may demonstrate the skill of the artist, but contains no new artistic expression.
In any case, it's not about the "craft", it's about the message. Super Mario Bros isn't art (though it contains art). A game that takes you through some emotional journey though your actions in the game and interaction with the presented environment certainly can be. "Second-person storytelling" and all that.
"art" could mean just about anything in English, so yes video games can be art.
Well, there's a bit more to it than that. "Art" allows any expressive medium, and so indeed games can be art to the extent they convey artistic intent.
Is painting art? Well, when painting a house, typically not. Is a random game art? Typically not. But there are certainly games that would fit most definitions of "art" that don't prescribe a medium, from evoking emotion to ambiguity of interpretation to varying schools of expression within the medium. And this of course surpasses mere presentation of other art within the game experience - a screenshot could be art, but that's not game-as-art, and yet game-as-art can happen.
It's not really even a question that games can be art. Of course they can be - it's a rich enough medium for such expression. It's equally clear that most games aren't art, just as most house painting isn't art.
The amount of government required to enforce basic order is really quite small - look at the tiny percentage of the $6 Trillion US governments (all levels) spend each year that goes to law enforcement and the courts and so on. You could fund that without an income tax.
Beyond that, the more government you have the less freedom you have. Sometimes that tradeoff may be worthwhile, it's arguable on a law-by-law, tax-by-tax basis. But there's always a cost in freedom for a new law, and a cost-benefit analysis is always needed.
If you're anywhere inside a symmetrical spherical shell, there's no gravitational pull from the shell. It all balances out. So, unless the sphere was spinning fast, you'd just fall into the sun - and you could only tune the spinning for one narrow band, you'd still get too much or too little everywhere else.
This problem is what inspired Larry Niven to publish his idea for a "ring world" - a more practical, lower tech approach. First as a non-fiction article in a SF mag, then as a series of SF novels. Now most people only know the idea Halo, sadly.
Plus a sphere isn't gravitationally stable - you'd have to constantly work to keep the star centered. Without some sort of gravity control, the whole idea is impractical, which is why finding one would be a big deal to physicists - we have no reason to think any such thing is possible today (but then, we don't have a good quantum gravity theory either).
could still successfully figure out how to use a pair of oxen to spread four bushels of seed over a virgate (with a peck left over)
It's an interesting note on the history of muscle-based farming that the standard amount of land one guy and his animals would farm in a season gradually increased from 30 acres (a virgate) to 40 acres, and along with that the amount of food you'd expect a family to live on.
You also see "blocks" (as in city blocks or neighborhood blocks) commonly as 1 furlong in medium population density areas in the US (city blocks tend to be smaller).
This is why the mile is 32*3*5*11 feet. OK, so the 11 is actually in there for different reasons than divisibility: there was a tradition of measuring any goods with 10-20% slop built in for spoilage. For land, a furlong (220 yards) gives you a 200 yard field with room to build a fence or road, and still have room to turn the oxen for the next furrow over. (An acre, BTW, is a rectangle a furlong by a surveyor's chain - a very handy unit for land measurement at the time.)
It's not entirely a coincidence that a furlong is very close to 200 meters. That was a strong influence in making the meter somewhat larger than the yard.
Or you take professional responsibility for adequate testing. No one need "matrix monkeys" any more, and when it comes to writing automated tests, software developers can develop that software just fine. What you miss is the "this works, but it's stupid" bugs. Those are a big deal in old-school, shrinkwrap software with multi-year release cycles, but if we do something stupid we hear about it the next week and deploy the fix the following week. If we have a blatant functional bug that escapes testing, the rollback usually happens before the customers see it, thanks to sanity tests built into deployment.
I believe these were construction site workers, not security guards. Safety (including ensuring everyone on site has checked in, and is wearing safety equipment at all times) is a big deal on modern construction sites. Not waring a bright orange safety vest makes you stand out like a sore thumb, and somebody will confront you about it when the see you. The "security managers" were different people than the "safety managers" who stopped the tresspassers. If their job was "mange the safety of the construction site", the title probably makes sense.
I don't think these were security guards - I think the "safety managers" may have been just that: construction personnel who oversee safety on the construction site. If you enter any modern construction site without proper safety equipment, someone on staff will certainly confront you, probably in a way that seems aggressive, as shouting is the norm on a site.
If they "breaking the window and cutting the safety belt" happened before the vehicular assault, that's clearly them in the wrong, but if they just were recording license plate then that's fine.
Jeb vs Biden would be just as bad. I suspect Rubio will replace Bush as the Donor Party candidate from the right, however - while just as bad politically, at least it's not a dynasty. I fear we'll get yet another Donor Party vs Donor Party general, sadly enough, whether Clinton v Bush or Biden v Rubio, it will barely matter who wins.
oftware can make judgement calls. In the case of weapons, we just don't feel comfortable allowing that. For self-driving-cars, there is no moral issue.
That's not the way most people use the phrase "judgement call" - if there's a rule you can write down, it's not a judgment call. We do have weapons that will kill anything that looks hostile with millisecond response time, but only where there's no judgement call required in identifying targets.
You might want to read up on what autonomous vehicles can do. They have already driven millions of miles on public roads, and have a safety record better than average human drivers.
Most of the time. That's at least a decade from reliable. It's a world of difference. Nothing today is anywhere near safe if a human isn't ready to take over the controls. Sure, there are routes that are safe, in most weather, if there's no detour or policeman waving traffic down. Sure the cars are safe in normal conditions. That's the first half of the problem solved.
Do you envision the entire vehicle to be unusable if it's not connected or if the on-board AI breaks down?
There's definitely a place for cars that can't be driven manually - no controls, the car is like the back of a limo, or an old-school train car where the seats faced each other, with perhaps a table in-between. No different from "can't be driven if the engine brakes down", and moving parts fail with age in a way software doesn't.
Devops isn't "ops people who code", it's "fire all the ops people, and make your software devs do that ops stuff too". It works about as well as you'd imagine - lots of automation, but the lack of real ops experience (and desire to do that for a living) really shows. And yes, you'd be on call - it's not devops if someone else has to wake up if you break it. That's the whole point, really - one team that has to live with the results of their choices. It's less than ideal, but better than any approach that lets dev blow off the concerns of ops.
DevOps is a specialization which used to be part of standard system administration. Developing custom tools to do custom tasks, in this case related to "Ops" (another specialty that used to be standard sysadmin territory). The term is a great dummy term, but really does not distinguish someone's ability to manage servers and infrastructure.
Not in my job it's not. We're all full-time software engineers, and none of us have any sort of ops, sys-admin, or any other sort of "IT" background. Just as we don't have any QA people, and none of us has a QA background. We write, test, operate, and maintain the product the company sells.
It doesn't work as well as dispensing with QA did. If you're writing good tests, the only value QA adds is early customer feedback, but if you're running a web service that you can change when you want to, you can respond quickly to actual customer feedback, and that's better. However, even with lots of automation, ops is still a specialty. It just takes more of our time to do it than it would to have a specialist do it full-time. It's also no fun - ops isn't our chosen career, and it's not what we like doing.
Devops tries to fix the usual distance and disconnect between dev and ops, and that's a great goal. But devops is a poor, suboptimal, and un-fun way of achieving that goal. Having a distinct ops staff integrated with the dev team (same first-level mangers, sitting next to one another, attending the same stand-ups, etc, no distinct ops and dev structure), would be a lot better. But then, horrors, engineers wouldn't be fully interchangeable cogs!
Slashdot Mirror
So, Slashdot can sell ads. People may or may not block them. They can also sell subscriptions so we can see "articles in the future" and whatever else that gets you. But, really, the value in a site like Slashdot is its users -- even the crazy ones like the "you're all cows" guy.
Seriously, it wouldn't be Slashdot without the trolls - it would be a bland, boring place. My early reaction to the comments to this story was actually "where's APK? I hope he's OK". There's a real sense of community here that keeps people coming back (no, not the "we're all friends" nonsense, no real community is like that either). Mess with it and the community dies.
But fortunately Dice seemed to get that - heck, I should probably change my sig now.
That's the problem with paywalls - people are only going to pay for original content, not news aggregation, and a lot of what news sites do is just aggregation of AP stories and stories from other sources. How sure can you be that yor produce enough original content to survive a paywall? Maybe the paywall easy to bypass hedges your bet.
Busty Babes in Bikinis playing volleyball decrying one another if their latest Texmex burger is "Tex" or "Mex" with two guys in the stand watching hungrily, monster burgers in their hands, saying "You going to tell them that it's both?" "Nope," says the other as he takes the kind of bite you might while still trying to watch TV while eating.
Sounds pretty misogynistic to me...
Sounds awesome to me. People having fun and generally enjoying themselves - the thing the neo-puritans hate the most.
Oh, I agree completely: Unidoce isn't made easy by C++, and it damn well should be. Especially, I want extremely optimized library code for getting Unicode meta-data about codepoints, and for validation. I'm sure ICU is good and all, but this deserves to be part of the language (with fully-baked support for std::algorithms working codepoint-wise, since std::algorithms has some great stuff hidden inside).
so yes: there are plenty of reasons to have a hand written destructor that actually does something
Yes, but my point is, only do it in a narrow set of carefully-reviewed library primitives. You don't really need very many - various OS "handles" and anything specific to the code base that needs unique handling (can't be built from other primitives, e.g., you're doing slab allocation and have a special "free" action).
For example, if you have a rich "file" class with many methods, it should have an empty destructor. But it should have as a member a primitive that wraps a FILE or Windows HANDLE object that only knows how to call fclose or CloseHandle.
To many, the phrase "non-trivial destructor" informally means "no interesting code written in the destructor definition", not the formal meaning in the standard, which is I think what you're talking about? In any case, I was talking about the former.
The reason for empty destructors is that destructors that actually clean up resources are usually a bad idea. (Debugging-related stuff in destructors is different.) The "allocate in the constructor, clean up in the destructor" pattern was a natural evolution from well-written C code. If you were used to "allocate at the top of the function, clean up at the bottom", it was the obvious better approach. But it's still just as error-prone (just fewer places for errors), and the fact that the destructor doesn't get called if the constructor throws isn't broadly internalized by coders (and is my least-favorite intermittent resource leak to run down).
Having very small resource-specific classes, similar in functionality to auto_ptr or unique_ptr (just managing a file handle or whatever instead of memory allocation) is the better answer. Only clean up a resource in a class whose only purpose is to clean up a resource. Using those primitives as members in other classes, or as local variables, is as idiot-proof as C++ gets.
The resource-leak headaches saved by difference in approach is amazing when junior coders are involved, it's really a difference in kind. And it's dead easy to police in code-reviews. The last time I did C++ we had a single, templated class in library code, and nowhere else in the code base was a non-trivial destructor allowed. (Odd cases like adding an object to a global list, and removing it on destruction could be managed within this system.)
To the OP: it might not be a bad idea. Though if you're considering C and Rust, you really ought to have C++ on the table. It's got the same resource footprint as the other two. You can be much less foot-shooty in C++ than C if you use modern style (no loss of efficiency either), and the tooling is much more mature than Rust.
There's really no reason ever to use C over C++ if you have a C++ compiler available.
So many bad books on C++ make this very hard for people to learn. I haven't yet found a good site for explaining why and how to have empty destructors for all but a few carefully-reviewed library classes (this is more than just RAII, or perhaps it's the golden version of it). Heck, it'd be nice to find a good guide to the latest standard, with a bunch of new anti-foot-shooting tools, plus "concepts" to allow much more sane templating for performance.
Heck, even explaining how to use std::strings and vectors with no performance loss vs C would be a wonderful thing in a "learn C" website or book. 9plus a nudge to switch to hashmaps instead of the old maps) This stuff isn't complicated in practice, and it belongs in introductory works.
Thanks - I just learned about Linux Mint Debian Edition, wonderfully Ubuntu-cancer-free. I'll have to dig up a VMware image, or ISO, this weekend and give it a spin.
What's a good distro to run XFCE on top of? Ubuntu has played it's own share of dirty tricks (e.g. sending your file searches to the mothership), and I'm looking for something better.
Has MS done this with a server OS? Does WIn10 Pro work this way (not a rhetorical question - I honestly don't know)?
If this is just the free consumer OS, and the OS for workstations and the OS for servers doesn't do this shit, then your rant is way off base, and all the geeks can just run the business version. Does anyone know if Pro does this same shit?
Why do you think Google doesn't live in your datacenter? They're amazing subtle and invasive. Why do you think this will apply to MS enterprise products? Is is even in WIn10 Pro? Any reason to think it will be in any of their business products, from server to Exchange to anything at all?
In the real world, "Art" is defined by culture, not by someone's capacity for "artistic intent." There are plenty of people in the world who want to "express" themselves in their "art," but no one pays any attention to them because what these "artists" are doing seems weird or obnoxious or even insane to most people. In essence, there is a failure to communicate. Art is a cultural product that requires both a creator and an audience who can find this "expressive" stuff which you talk about and can value it.
That's definitely art: it's bad art. Unless it's so incoherent it isn't even an "expression". But that's not usually the case - usually it's clear what's going on, it just sucks.
BTW, I don't buy that mere "aesthetic engagement" is sufficient for art. Just because something's painted on canvas with skill doesn't make it art! It also has to communicate some idea or emotion. The Mona Lisa is art because of the smile, not the paint. Robotically playing the piano with no emotion isn't art unless the lack of emotion was actually the artistic intent. Painting a great counterfeit may demonstrate the skill of the artist, but contains no new artistic expression.
In any case, it's not about the "craft", it's about the message. Super Mario Bros isn't art (though it contains art). A game that takes you through some emotional journey though your actions in the game and interaction with the presented environment certainly can be. "Second-person storytelling" and all that.
"art" could mean just about anything in English, so yes video games can be art.
Well, there's a bit more to it than that. "Art" allows any expressive medium, and so indeed games can be art to the extent they convey artistic intent.
Is painting art? Well, when painting a house, typically not. Is a random game art? Typically not. But there are certainly games that would fit most definitions of "art" that don't prescribe a medium, from evoking emotion to ambiguity of interpretation to varying schools of expression within the medium. And this of course surpasses mere presentation of other art within the game experience - a screenshot could be art, but that's not game-as-art, and yet game-as-art can happen.
It's not really even a question that games can be art. Of course they can be - it's a rich enough medium for such expression. It's equally clear that most games aren't art, just as most house painting isn't art.
The amount of government required to enforce basic order is really quite small - look at the tiny percentage of the $6 Trillion US governments (all levels) spend each year that goes to law enforcement and the courts and so on. You could fund that without an income tax.
Beyond that, the more government you have the less freedom you have. Sometimes that tradeoff may be worthwhile, it's arguable on a law-by-law, tax-by-tax basis. But there's always a cost in freedom for a new law, and a cost-benefit analysis is always needed.
If you're anywhere inside a symmetrical spherical shell, there's no gravitational pull from the shell. It all balances out. So, unless the sphere was spinning fast, you'd just fall into the sun - and you could only tune the spinning for one narrow band, you'd still get too much or too little everywhere else.
This problem is what inspired Larry Niven to publish his idea for a "ring world" - a more practical, lower tech approach. First as a non-fiction article in a SF mag, then as a series of SF novels. Now most people only know the idea Halo, sadly.
Plus a sphere isn't gravitationally stable - you'd have to constantly work to keep the star centered. Without some sort of gravity control, the whole idea is impractical, which is why finding one would be a big deal to physicists - we have no reason to think any such thing is possible today (but then, we don't have a good quantum gravity theory either).
could still successfully figure out how to use a pair of oxen to spread four bushels of seed over a virgate (with a peck left over)
It's an interesting note on the history of muscle-based farming that the standard amount of land one guy and his animals would farm in a season gradually increased from 30 acres (a virgate) to 40 acres, and along with that the amount of food you'd expect a family to live on.
You also see "blocks" (as in city blocks or neighborhood blocks) commonly as 1 furlong in medium population density areas in the US (city blocks tend to be smaller).
so base 210 (7*5*3*2) would be an even better one
This is why the mile is 32*3*5*11 feet. OK, so the 11 is actually in there for different reasons than divisibility: there was a tradition of measuring any goods with 10-20% slop built in for spoilage. For land, a furlong (220 yards) gives you a 200 yard field with room to build a fence or road, and still have room to turn the oxen for the next furrow over. (An acre, BTW, is a rectangle a furlong by a surveyor's chain - a very handy unit for land measurement at the time.)
It's not entirely a coincidence that a furlong is very close to 200 meters. That was a strong influence in making the meter somewhat larger than the yard.
Or you take professional responsibility for adequate testing. No one need "matrix monkeys" any more, and when it comes to writing automated tests, software developers can develop that software just fine. What you miss is the "this works, but it's stupid" bugs. Those are a big deal in old-school, shrinkwrap software with multi-year release cycles, but if we do something stupid we hear about it the next week and deploy the fix the following week. If we have a blatant functional bug that escapes testing, the rollback usually happens before the customers see it, thanks to sanity tests built into deployment.
I believe these were construction site workers, not security guards. Safety (including ensuring everyone on site has checked in, and is wearing safety equipment at all times) is a big deal on modern construction sites. Not waring a bright orange safety vest makes you stand out like a sore thumb, and somebody will confront you about it when the see you. The "security managers" were different people than the "safety managers" who stopped the tresspassers. If their job was "mange the safety of the construction site", the title probably makes sense.
I don't think these were security guards - I think the "safety managers" may have been just that: construction personnel who oversee safety on the construction site. If you enter any modern construction site without proper safety equipment, someone on staff will certainly confront you, probably in a way that seems aggressive, as shouting is the norm on a site.
If they "breaking the window and cutting the safety belt" happened before the vehicular assault, that's clearly them in the wrong, but if they just were recording license plate then that's fine.
Jeb vs Biden would be just as bad. I suspect Rubio will replace Bush as the Donor Party candidate from the right, however - while just as bad politically, at least it's not a dynasty. I fear we'll get yet another Donor Party vs Donor Party general, sadly enough, whether Clinton v Bush or Biden v Rubio, it will barely matter who wins.
oftware can make judgement calls. In the case of weapons, we just don't feel comfortable allowing that. For self-driving-cars, there is no moral issue.
That's not the way most people use the phrase "judgement call" - if there's a rule you can write down, it's not a judgment call. We do have weapons that will kill anything that looks hostile with millisecond response time, but only where there's no judgement call required in identifying targets.
You might want to read up on what autonomous vehicles can do. They have already driven millions of miles on public roads, and have a safety record better than average human drivers.
Most of the time. That's at least a decade from reliable. It's a world of difference. Nothing today is anywhere near safe if a human isn't ready to take over the controls. Sure, there are routes that are safe, in most weather, if there's no detour or policeman waving traffic down. Sure the cars are safe in normal conditions. That's the first half of the problem solved.
Do you envision the entire vehicle to be unusable if it's not connected or if the on-board AI breaks down?
There's definitely a place for cars that can't be driven manually - no controls, the car is like the back of a limo, or an old-school train car where the seats faced each other, with perhaps a table in-between. No different from "can't be driven if the engine brakes down", and moving parts fail with age in a way software doesn't.
How does the occupant get out in a power failure?
Through the ... doors?
Devops isn't "ops people who code", it's "fire all the ops people, and make your software devs do that ops stuff too". It works about as well as you'd imagine - lots of automation, but the lack of real ops experience (and desire to do that for a living) really shows. And yes, you'd be on call - it's not devops if someone else has to wake up if you break it. That's the whole point, really - one team that has to live with the results of their choices. It's less than ideal, but better than any approach that lets dev blow off the concerns of ops.
DevOps is a specialization which used to be part of standard system administration. Developing custom tools to do custom tasks, in this case related to "Ops" (another specialty that used to be standard sysadmin territory). The term is a great dummy term, but really does not distinguish someone's ability to manage servers and infrastructure.
Not in my job it's not. We're all full-time software engineers, and none of us have any sort of ops, sys-admin, or any other sort of "IT" background. Just as we don't have any QA people, and none of us has a QA background. We write, test, operate, and maintain the product the company sells.
It doesn't work as well as dispensing with QA did. If you're writing good tests, the only value QA adds is early customer feedback, but if you're running a web service that you can change when you want to, you can respond quickly to actual customer feedback, and that's better. However, even with lots of automation, ops is still a specialty. It just takes more of our time to do it than it would to have a specialist do it full-time. It's also no fun - ops isn't our chosen career, and it's not what we like doing.
Devops tries to fix the usual distance and disconnect between dev and ops, and that's a great goal. But devops is a poor, suboptimal, and un-fun way of achieving that goal. Having a distinct ops staff integrated with the dev team (same first-level mangers, sitting next to one another, attending the same stand-ups, etc, no distinct ops and dev structure), would be a lot better. But then, horrors, engineers wouldn't be fully interchangeable cogs!