No, the USS Yorktown, CG-48, is a Ticonderoga-class cruiser. The US doesn't have any battleships in service, and didn't in 1997 when the incident occurred. The previous USS Yorktown, CV-10, was an Essex-class carrier, which is probably the source of the confusion about CV-48's ship type.
And yes, it did indeed require towage back to port.
So claims Government Computer News. According to Atlantic Fleet, the captain and the contractor who was the source of the GCN story, it did not. The contractor said the reporter altered his statements.
Let's also remember that accidents do cluster like a lot of events and there is statistical theory that covers it.
No, there's no statistical theory that says accidents or other events tend to cluster. Statistics just says that clusters do happen sometimes. Human intuition (AKA common sense) says that rare random events should always be widely separated in time, but that's because common sense sucks at understanding randomness.
Common sense tells us that if a rare event has just happened, the probability that it's going to happen again is decreased because it just happened. But random events don't work that way. The fact that one just happened neither increases nor decreases the chance that another will happen now, which means that common sense is surprised in the (rare) case that two of them happen in quick succession and shocked when three happen. Because these clusters are surprising to our innumerate brains they stick out in our memory... and since our brains insist on finding causes and inventing narratives, we get folk theories that random events cluster. Confirmation bias then causes us to take note of every cluster because it confirms the theory, and ignore single events, because they don't.
So, common sense erroneously tells us that accidents cluster. Statistics tells us that accidents (assuming they're rare random events) can happen at any time, which means that accident clusters occur, but non-clustered accidents are more common. If accidents cluster too much or too often, that's evidence that the accidents aren't random.
When I'm reading docs or explanations that talk about a specific version of something, I find it very helpful to know exactly what version is being referenced. Often, this lets me adapt what the documentation is saying so that it fits the version I have. Knowing precisely where the version sits in the lineage is very helpful for that.
Sure. For me at least, letters do that exactly as well as numbers do. There is no difference. The only exception is library numbering where the specific meanings of major, minor and sub-minor versions would be difficult to replicate with letters -- well, actually, letters would do fine but no one does major, minor and sub-minor letters. But with system releases that's really not an issue and no one does it with numbers either.
In the case of Android, the library API is numbered -- Oreo is API level 26, for example.
I live outside CA, and have not experienced this. Cult of youth is not everywhere.
I work for a CA company (Google), and have not experienced it either. Previously I worked for IBM and I really didn't see it there, in fact something of the opposite; gray hair was overvalued, though not heavily. Before working for IBM (21 years ago), I was young.
Yes, if that's all you want to know. If, however, you want to know which version a release is in more absolute terms, then you have to count letters.
Interesting. I have a good feel for where letters lie in the alphabet, and in relation to one another. I can't necessarily subtract them to know that, e.g. M - F = 7, but I have a good rough feel for how far apart they are. I also don't know that I've ever needed to know that Froyo was seven releases before Marshmallow.
I don't just want to know which releases the version is between, I want to know its place in the entire run.
Why? I can't think of a time that has ever been useful information. The closest is that sometimes I'm interested in knowing when a release came out, in order to place it in the larger context of what was happening in the world and in technology at the time. The Ubuntu year numbers are outstanding for that purpose, but neither letters nor ordinary version numbers are helpful.
But it always pisses me off that it's necessary to do that. Just go with version numbers, people!
Google Android engineer here: In most cases I don't actually know what the numbers are without looking them up. I kind of get the complaint in Debian's case, since the choice of Toy Story character is arbitrary, but both Ubuntu and Android have been going in alphabetical order (though Ubuntu has to wrap, or something, in October), so it's just as easy to tell which release is before or after another as if they were numbered. Internally, we pretty much only use the code names (or letters, before the names are announced).
Actually, Android does have a number sequence that I track closely: API level. The OS version number doesn't mean that much to me.
I do know 8.0, though. I added a feature to Nougat that binds Keystore keys to OS version and security patch level as another layer of defense against rollback attacks (where the attacker pushes a legitimate but old OS that has known vulnerabilities). Keystore is used for disk encryption keys, among other things, so when Keystore keys break, the device doesn't boot. Due to an error in the version number management on internal testing devices (which are used by large numbers of employees as their everyday phones), we had to roll back the version number. I found a workaround, but for a while it looked like we might have to wipe everyone's phones.
I'd say it's insufficient. Everything should be encrypted and authenticated end to end, not just forms and form responses. Actually, it's really more important that data coming to your browser be authenticated than that data you send be encrypted. Why? Because unless your browser and OS are perfectly secure (they're not) then you have to trust every network hop between the server and you not to inject malware. With authentication, you only have to trust the server.
And as long as you're authenticating all of the data, you might as well encrypt it, too, because some stuff does need to be protected and (a) it's not always obvious what does and what does not and (b) there's no reason not to just encrypt it all.
Fortunately he can just retrieve his files from his Git repository, right? Or... he just learned a painful lesson of why you always use a code repository.
I have to take this opportunity to tell my favorite oh-shit story.
Some twenty-odd years ago, I was working on an embedded system project which had about 60 person-years of development effort into it (20 developers, three years). We worked on HPUX workstations with our home directories NFS-mounted on a big Network Appliances NFS server. The server was pretty cool tech for the day, making use of RAID for redundancy, with nifty snapshotting features, including automatic snapshotting that created a set of hidden subdirectories in each directory with your files as they were an hour before, two hours before, etc. Getting back any old version was super easy. Plus we all used CVS, and the CVS server also used NFS storage.
So... all of our eggs were in one basket, but it was a highly-reliable and flexible basket and, of course, the sysadmin made nightly backups, rotated the tapes offsite, etc. The backups even included the snapshots, providing quite fine-grained history from any point in time. So not bad.
Well, one day something went wrong, and the NFS server lost everything. I don't know if it was hardware failure, if the sysadmin accidentally did something like "rm -rf/", or what. But it was all gone. All of the developers' home directories, with their working copies, and the central CVS repository. Every Single Line Of Code, all of the design documents other that what happened to be laying around in hardcopy, everything. 60 person-years.
Oh shit.
But, backups, right? No.
Not one.
The sysadmin had never tested his backups, and it turned out that his backup script didn't have permission to read any of the directories where the important data lived. The backup tapes were all useless. He had dozens of methodically-archived off-site copies of the NFS server system binaries. You know, the ones that come on the installation media.
OH SHIT!
Luckily, we had one major customer that was so big, financially, and so influential in the relevant industry, that when they signed their contract to buy our product, they made us commit to keeping a developer on-site, full-time. So we all took turns spending a couple of weeks at a time living in a hotel and working in their facility, on the other side of the continent. And, most importantly, there was a development workstation there. With a local copy of the code that was updated via FTP as needed.
Now, for you young'uns that only know about distributed version control systems, CVS wasn't (isn't) such a beast. In CVS there's one central repository which has all of the versioned history, all of the branches (not that there were many, because working with branches was a pain in the ass), all of the tags, etc. When you check out the code, you get only the current head revision of the one branch, no history at all.
That's what this one remote workstation had. A checkout of HEAD, as it was a couple of weeks before the disaster. We carefully copied that, and FTP'd it back home, and used it to start a new, fresh, CVS repository. All of the commit history was gone, and a couple of weeks of work by 20 or so people, but we had nearly-current code. All of the design docs and other bits and pieces were gone, but we had code.
You may be wondering if, at this point, the sysadmin got canned. He did not. He was called onto the carpet and told that we HAD to have good, tested backups going forward. He agreed that it would be his top priority. A couple of weeks later, he reported back to senior management that we had good backups.
My boss decided to test it. He disabled snapshotting of his home directory, created a file, put some stuff into it, waited a day (so it would get backed up to tape), then deleted it and walked over to ask the sysadmin to recover it for him.
What kind of idiot only has one copy of 3 months of work?
No doubt.
I once worked with a guy who had the opposite problem. He did not trust the version control system, or much of anything else. He'd check the source out, copy it once onto a USB drive and a second time to his work directory. Then he'd remove the USB drive and put it in a drawer for safekeeping, then proceed to work on the code. Periodically he'd stop and copy his changed files to the USB drive. When he had completed some work, he'd copy the changed files over to the checkout location, then commit the change to the version control system.
Where it got really nightmarish is when he had multiple changes in progress at once. He'd have a checkout for each stream of work, plus a copy of each checkout on a USB drive, plus a work directory for each. He tried very hard never to do that, which meant he was always refusing to fix important bugs because he was already working on something else, even if what he was doing was less important, just because it was too hard for him to context switch due to his lame system.
If you're wondering how he kept everything straight, he didn't. He frequently forgot a file or two when copying from his work directory to the checkout, resulting in commits that didn't build because they were missing part of the change (even worse was when they *did* build). Once in a while, he copied from the wrong work directory. As far as I could tell, he never actually used the USB drives for anything at all, just copied to them and put them in a drawer.
What about merge conflicts? Heh. Merge conflicts terrified him. He was always trying to convince people not to touch any file that he was working on, and advocating for replacing the version control system with one that used a locking model, so he could lock "his" files and be sure that no one else could work on them.
I was a contractor and only worked at the place for about two months. I still felt like strangling him; I don't know how the others who had to deal with him long-term did it.
I've got a broken Apple Watch, uses Sapphire glass. My Timex from 30 years ago using fused quartz is still unscathed.
Engineering measurements trump anecdotes.
You've never used a hydro carb before?
No, and neither have you, if you're claiming it increases fuel efficiency.
You've never used a hydro carb before? They work (but not at 200 MPG, more like 80 MPG.
Bullshit. In high-performance engines that need very high compression ratios, or operate at very high temperatures, water injection can prevent premature detonation, but in normal automobile engines it does nothing but reduce power.
Which is why phone manufacturers charge almost the same price of the phone for a screen replacement?
Try building a car from replacement parts purchased from a dealer and see what the total cost is.
At least, you have to admit that Clinton would have nominated a very different kind of justice.
Yes, of course. I think you missed my point: appointing the SC justice can't be considered a "victory" for Trump, because no matter who was President, they were going to appoint a justice. So it's not so much a "victory" as it is a "gift".
Okay, not a victory for Trump, but a victory for Trump's voters. I know lots of people who voted for Trump only because they wanted a conservative justice, and they got it. Actually, this issue is kind of an anti-victory for Trump, because if there hadn't been a seat or two on SCOTUS up for grabs, he'd have gotten fewer votes... and it wouldn't have taken that many fewer to have lost the election.
"The CNBC article says both that Bannon resigned and that Trump fired him."
I can see that: "You can't resign, you work for me. You're fired."
Or "Please have your resignation on my desk this afternoon". That's the way these things are typically done, so that technically the individual resigned, even though they were actually fired.
The supreme court appointment was engineered by Congress and no matter who was President, they were going to make an appointment
You're correct on the rest, and grasshoppa is nuts if he thinks that Trump's effort to take on ObamaCare has accomplished anything at all (the left was already talking about how to improve it), but on this one you're wrong. At least, you have to admit that Clinton would have nominated a very different kind of justice. It's remotely possible that the Senate could have refused to confirm, but very doubtful. They managed to hold off confirming Obama's nominee for 8 months, but there's no way they'd have left SCOTUS at eight justices for four years.
, you only have one image for both eyes, not two like you get in a mirror
Depth perception is not based on stereoscopy beyond a couple of dozen feet anyway. And for close up you can just add distance marks, like most backup cameras have.
" If laminar quartz (or fused quartz; note that they're different things) "
Not geologically, they're not. Laminar quartz comes from hydrothermal alteration and fusing of cryptocrystalline mass. It is natural fused quartz.
Fused quartz is a glass, an amorphous fluid structure, meaning that the molecules aren't aligned in any particular way. I believe laminar quartz is a crystal, meaning that the molecules are in a particular pattern. If laminar quartz is not crystalline, then I stand corrected. I can't find any references to indicate what exactly laminar quartz is. Actually, it mostly appears to be a term that fell out of common use about 200 years ago, since all of the Google results that mention it are from early to mid-19th century books.
"But I don't find it being used anywhere. That's a pretty strong indicator that there are some problems with it"
Most fused quartzes are in use in everything else, right down to scientific glassware and dab rig nails. And quartz withstands breaking far better than sapphire. As you increase mohs hardness level, you get more brittle.
I'm not sure whether you're using the technical or the everyday definition of "brittle" here. If you're using the technical term (breaks without significant deformation), then you're correct, of course, but given sapphire's very high strength (in virtually every way), it's not really an issue. If you're using the everyday definition, you're simply wrong. Under most circumstances sapphire will take far more force before breaking than quartz.
You wanna know why it isn't used? Because there's no profit in a nearly-unbreakable screen.
Uh, huh, and automakers have kept the 200 mile per gallon carburetor out of production for the last fifty years, because the oil companies have paid them off.
Hell yes there's profit in a nearly-unbreakable screen. Device makers have no need at all to pad their revenues by making devices that are more breakable than necessary, because there are plenty of other factors that drive quick obsolescence, and there would be huge competitive advantage in being able to tell prospective customers that your screens won't break.
And I didn't say they made quartz screens NOW, I'm saying they should be making and using them.
Color me skeptical. There's a lot of competition in this space, because broken screens are a huge problem. If laminar quartz (or fused quartz; note that they're different things) were the obvious solution you say, it would be available on the market. About the only way that could not be true is if it were more expensive than simply replacing a broken screen, and even then I'd expect to find it used on devices that bill themselves as ultra-tough.
But I don't find it being used anywhere. That's a pretty strong indicator that there are some problems with it. Sapphire (AKA aluminum oxide, AKA transparent aluminum) is harder and more scratch-resistant than quartz, and the thermal expansion issue really doesn't matter for small pieces, so unless quartz is significantly cheaper than sapphire, the latter is a better choice.
But, we don't see sapphire on phones, really, only on watches. Why? Not only is it much more expensive than Gorilla Glass, but as phones get thinner it has another problem, which quartz shares: it doesn't flex, at all. Having an extremely rigid screen means you're going to need to build an extremely rigid body, otherwise the first time someone puts in in their back pocket and sits on it, the screen will break. When the phone is thick a rigid body is easy, but thick phones don't sell -- especially not phones in the upper end of the price range, which is where you'd have to be to add a sapphire or quartz screen to the BoM.
Skyscraper apartment buildings don't "carpet" the land
Haven't traveled much have you? Visit Paris some time.
I lived in Paris for two months, and in aggregate have spent at least another six months there throughout the course of my 50 years of life. I've been to every continent except Antarctica, spent several years living outside the US, and have visited at least three dozen countries.
Imagine what Paris would look like if you tried to put the same number of people in detached homes. You'd have a residential area that extends at least to Orleans and Saint Quentin, nothing but houses. It would be impractical, and unlivable.
But most people don't like telecommuting.
People don't like commuting for hours either.
Many, many people actually prefer that over not having the socialization they get at work. I spent 10 years telecommuting full time for a company (IBM) that pushed everyone out of the offices and into telecommuting. Some of us, like me, loved it. Others -- probably the majority -- hated it and many of them left the company because of that fact.
Guess what else people don't like; they don't like your "lowest-footprint, least-impactful" apartment block hellscapes and living in a glorified bedroom in a tower.
You apparently didn't read my post. I know lots of people who commute for hours *out* of the city because they want that badly to live *in* the city. They could live much closer to work, for less money, but they don't want to. They have the money to live where they want, and where they want to live is in a highrise in San Francisco.
I think they're nuts. They look at my choice (rural Utah) and think I'm nuts. Different strokes.
That's why anywhere that geography and the prevailing laws allow high density urbanity doesn't emerge. Suburbs and exburbs emerge. So when you're dealing in what people do and don't like try to keep that in mind.
Utter nonsense. Suburbs and exurbs are an almost uniquely American thing. Most of the world's population is clustered in cities, and it's not because of zoning laws or geography. Even in the US, 80% of the population lives in urban areas.
If Sheila James and her ilk would like an office somewhere then so be it, but perhaps we could simple not try to pile all those offices into the same few square miles of la-la land.
There are very good reasons why all of the office buildings cluster together. I've seen what happens when you spread them out. As it happens, IBM did that for most of a century and ended up with many such company towns all over the northeast, especially upstate New York and Connecticut. By and large, employees hated them. You can't get a job with the company without moving to the company town, and you can't leave the company without having to move out of the company town. Cities with clusters of businesses are good for both the businesses and the employees. Employees have job mobility, without uprooting and disrupting their lives, and companies have a large labor pool without having to relocate people.
Your way has been tried. It doesn't work well. Telecommuting has been tried. It works for some people and some jobs. By and large, people are going to continue working in cities, either living in them or commuting to them. So we should make it easy for those who want to live in cities to do so by building enough housing, and easy for those who want to commute to do so, by building transit infrastructure.
Slashdot Mirror
You're thinking of a different incident.
It was a battleship, not a carrier.
No, the USS Yorktown, CG-48, is a Ticonderoga-class cruiser. The US doesn't have any battleships in service, and didn't in 1997 when the incident occurred. The previous USS Yorktown, CV-10, was an Essex-class carrier, which is probably the source of the confusion about CV-48's ship type.
And yes, it did indeed require towage back to port.
So claims Government Computer News. According to Atlantic Fleet, the captain and the contractor who was the source of the GCN story, it did not. The contractor said the reporter altered his statements.
https://en.wikipedia.org/wiki/USS_Yorktown_(CG-48)#Smart_ship_testbed
does anyone else remember the "flagship US airforce carrier"
Wow, the Air Force has carriers now? I'll bet the Navy is really pissed about that.
Let's also remember that accidents do cluster like a lot of events and there is statistical theory that covers it.
No, there's no statistical theory that says accidents or other events tend to cluster. Statistics just says that clusters do happen sometimes. Human intuition (AKA common sense) says that rare random events should always be widely separated in time, but that's because common sense sucks at understanding randomness.
Common sense tells us that if a rare event has just happened, the probability that it's going to happen again is decreased because it just happened. But random events don't work that way. The fact that one just happened neither increases nor decreases the chance that another will happen now, which means that common sense is surprised in the (rare) case that two of them happen in quick succession and shocked when three happen. Because these clusters are surprising to our innumerate brains they stick out in our memory... and since our brains insist on finding causes and inventing narratives, we get folk theories that random events cluster. Confirmation bias then causes us to take note of every cluster because it confirms the theory, and ignore single events, because they don't.
So, common sense erroneously tells us that accidents cluster. Statistics tells us that accidents (assuming they're rare random events) can happen at any time, which means that accident clusters occur, but non-clustered accidents are more common. If accidents cluster too much or too often, that's evidence that the accidents aren't random.
When I'm reading docs or explanations that talk about a specific version of something, I find it very helpful to know exactly what version is being referenced. Often, this lets me adapt what the documentation is saying so that it fits the version I have. Knowing precisely where the version sits in the lineage is very helpful for that.
Sure. For me at least, letters do that exactly as well as numbers do. There is no difference. The only exception is library numbering where the specific meanings of major, minor and sub-minor versions would be difficult to replicate with letters -- well, actually, letters would do fine but no one does major, minor and sub-minor letters. But with system releases that's really not an issue and no one does it with numbers either.
In the case of Android, the library API is numbered -- Oreo is API level 26, for example.
I did reply to the wrong person. I'm surprised I did that. In any case, it would make no sense to call VOIP a "LAN line".
I live outside CA, and have not experienced this. Cult of youth is not everywhere.
I work for a CA company (Google), and have not experienced it either. Previously I worked for IBM and I really didn't see it there, in fact something of the opposite; gray hair was overvalued, though not heavily. Before working for IBM (21 years ago), I was young.
Yes, if that's all you want to know. If, however, you want to know which version a release is in more absolute terms, then you have to count letters.
Interesting. I have a good feel for where letters lie in the alphabet, and in relation to one another. I can't necessarily subtract them to know that, e.g. M - F = 7, but I have a good rough feel for how far apart they are. I also don't know that I've ever needed to know that Froyo was seven releases before Marshmallow.
I don't just want to know which releases the version is between, I want to know its place in the entire run.
Why? I can't think of a time that has ever been useful information. The closest is that sometimes I'm interested in knowing when a release came out, in order to place it in the larger context of what was happening in the world and in technology at the time. The Ubuntu year numbers are outstanding for that purpose, but neither letters nor ordinary version numbers are helpful.
Er, "If Facebook can do X, so can everyone else" doesn't follow. At all.
It helps not to think. I certainly don't with my comments. ;)
FTFY.
If Facebook can do that, everyone else can do the same thing.
Er, "If Facebook can do X, so can everyone else" doesn't follow. At all.
"Oreos are pretty much as universally beloved as a cookie can be" no some people think they taste foul ...
You should try the Cinnamon Bun Oreos.
That's the thing, though - it is so US centric
How so? Because it's based on the Latin alphabet? That's more Western-centric than US-centric.
when it comes to finding cool names, you are just so juvenile.
Playful, not juvenile :-)
And Ubuntu's naming strategy is toe-curling
Well, you can't pin that one on the US. Not that I think Ubuntu's names are bad.
But it always pisses me off that it's necessary to do that. Just go with version numbers, people!
Google Android engineer here: In most cases I don't actually know what the numbers are without looking them up. I kind of get the complaint in Debian's case, since the choice of Toy Story character is arbitrary, but both Ubuntu and Android have been going in alphabetical order (though Ubuntu has to wrap, or something, in October), so it's just as easy to tell which release is before or after another as if they were numbered. Internally, we pretty much only use the code names (or letters, before the names are announced).
Actually, Android does have a number sequence that I track closely: API level. The OS version number doesn't mean that much to me.
I do know 8.0, though. I added a feature to Nougat that binds Keystore keys to OS version and security patch level as another layer of defense against rollback attacks (where the attacker pushes a legitimate but old OS that has known vulnerabilities). Keystore is used for disk encryption keys, among other things, so when Keystore keys break, the device doesn't boot. Due to an error in the version number management on internal testing devices (which are used by large numbers of employees as their everyday phones), we had to roll back the version number. I found a workaround, but for a while it looked like we might have to wipe everyone's phones.
Or a LAN line.
You mean "land line". The terminology predates IP telephony, and in any case the term clearly cannot apply to local area networks.
This seems like overkill to me.
I'd say it's insufficient. Everything should be encrypted and authenticated end to end, not just forms and form responses. Actually, it's really more important that data coming to your browser be authenticated than that data you send be encrypted. Why? Because unless your browser and OS are perfectly secure (they're not) then you have to trust every network hop between the server and you not to inject malware. With authentication, you only have to trust the server.
And as long as you're authenticating all of the data, you might as well encrypt it, too, because some stuff does need to be protected and (a) it's not always obvious what does and what does not and (b) there's no reason not to just encrypt it all.
s/save/screw/
Fortunately he can just retrieve his files from his Git repository, right? Or... he just learned a painful lesson of why you always use a code repository.
I have to take this opportunity to tell my favorite oh-shit story.
Some twenty-odd years ago, I was working on an embedded system project which had about 60 person-years of development effort into it (20 developers, three years). We worked on HPUX workstations with our home directories NFS-mounted on a big Network Appliances NFS server. The server was pretty cool tech for the day, making use of RAID for redundancy, with nifty snapshotting features, including automatic snapshotting that created a set of hidden subdirectories in each directory with your files as they were an hour before, two hours before, etc. Getting back any old version was super easy. Plus we all used CVS, and the CVS server also used NFS storage.
So... all of our eggs were in one basket, but it was a highly-reliable and flexible basket and, of course, the sysadmin made nightly backups, rotated the tapes offsite, etc. The backups even included the snapshots, providing quite fine-grained history from any point in time. So not bad.
Well, one day something went wrong, and the NFS server lost everything. I don't know if it was hardware failure, if the sysadmin accidentally did something like "rm -rf /", or what. But it was all gone. All of the developers' home directories, with their working copies, and the central CVS repository. Every Single Line Of Code, all of the design documents other that what happened to be laying around in hardcopy, everything. 60 person-years.
Oh shit.
But, backups, right? No.
Not one.
The sysadmin had never tested his backups, and it turned out that his backup script didn't have permission to read any of the directories where the important data lived. The backup tapes were all useless. He had dozens of methodically-archived off-site copies of the NFS server system binaries. You know, the ones that come on the installation media.
OH SHIT!
Luckily, we had one major customer that was so big, financially, and so influential in the relevant industry, that when they signed their contract to buy our product, they made us commit to keeping a developer on-site, full-time. So we all took turns spending a couple of weeks at a time living in a hotel and working in their facility, on the other side of the continent. And, most importantly, there was a development workstation there. With a local copy of the code that was updated via FTP as needed.
Now, for you young'uns that only know about distributed version control systems, CVS wasn't (isn't) such a beast. In CVS there's one central repository which has all of the versioned history, all of the branches (not that there were many, because working with branches was a pain in the ass), all of the tags, etc. When you check out the code, you get only the current head revision of the one branch, no history at all.
That's what this one remote workstation had. A checkout of HEAD, as it was a couple of weeks before the disaster. We carefully copied that, and FTP'd it back home, and used it to start a new, fresh, CVS repository. All of the commit history was gone, and a couple of weeks of work by 20 or so people, but we had nearly-current code. All of the design docs and other bits and pieces were gone, but we had code.
You may be wondering if, at this point, the sysadmin got canned. He did not. He was called onto the carpet and told that we HAD to have good, tested backups going forward. He agreed that it would be his top priority. A couple of weeks later, he reported back to senior management that we had good backups.
My boss decided to test it. He disabled snapshotting of his home directory, created a file, put some stuff into it, waited a day (so it would get backed up to tape), then deleted it and walked over to ask the sysadmin to recover it for him.
The backups still didn
What kind of idiot only has one copy of 3 months of work?
No doubt.
I once worked with a guy who had the opposite problem. He did not trust the version control system, or much of anything else. He'd check the source out, copy it once onto a USB drive and a second time to his work directory. Then he'd remove the USB drive and put it in a drawer for safekeeping, then proceed to work on the code. Periodically he'd stop and copy his changed files to the USB drive. When he had completed some work, he'd copy the changed files over to the checkout location, then commit the change to the version control system.
Where it got really nightmarish is when he had multiple changes in progress at once. He'd have a checkout for each stream of work, plus a copy of each checkout on a USB drive, plus a work directory for each. He tried very hard never to do that, which meant he was always refusing to fix important bugs because he was already working on something else, even if what he was doing was less important, just because it was too hard for him to context switch due to his lame system.
If you're wondering how he kept everything straight, he didn't. He frequently forgot a file or two when copying from his work directory to the checkout, resulting in commits that didn't build because they were missing part of the change (even worse was when they *did* build). Once in a while, he copied from the wrong work directory. As far as I could tell, he never actually used the USB drives for anything at all, just copied to them and put them in a drawer.
What about merge conflicts? Heh. Merge conflicts terrified him. He was always trying to convince people not to touch any file that he was working on, and advocating for replacing the version control system with one that used a locking model, so he could lock "his" files and be sure that no one else could work on them.
I was a contractor and only worked at the place for about two months. I still felt like strangling him; I don't know how the others who had to deal with him long-term did it.
I've got a broken Apple Watch, uses Sapphire glass. My Timex from 30 years ago using fused quartz is still unscathed.
Engineering measurements trump anecdotes.
You've never used a hydro carb before?
No, and neither have you, if you're claiming it increases fuel efficiency.
You've never used a hydro carb before? They work (but not at 200 MPG, more like 80 MPG.
Bullshit. In high-performance engines that need very high compression ratios, or operate at very high temperatures, water injection can prevent premature detonation, but in normal automobile engines it does nothing but reduce power.
Which is why phone manufacturers charge almost the same price of the phone for a screen replacement?
Try building a car from replacement parts purchased from a dealer and see what the total cost is.
At least, you have to admit that Clinton would have nominated a very different kind of justice.
Yes, of course. I think you missed my point: appointing the SC justice can't be considered a "victory" for Trump, because no matter who was President, they were going to appoint a justice. So it's not so much a "victory" as it is a "gift".
Okay, not a victory for Trump, but a victory for Trump's voters. I know lots of people who voted for Trump only because they wanted a conservative justice, and they got it. Actually, this issue is kind of an anti-victory for Trump, because if there hadn't been a seat or two on SCOTUS up for grabs, he'd have gotten fewer votes... and it wouldn't have taken that many fewer to have lost the election.
"The CNBC article says both that Bannon resigned and that Trump fired him." I can see that: "You can't resign, you work for me. You're fired."
Or "Please have your resignation on my desk this afternoon". That's the way these things are typically done, so that technically the individual resigned, even though they were actually fired.
The supreme court appointment was engineered by Congress and no matter who was President, they were going to make an appointment
You're correct on the rest, and grasshoppa is nuts if he thinks that Trump's effort to take on ObamaCare has accomplished anything at all (the left was already talking about how to improve it), but on this one you're wrong. At least, you have to admit that Clinton would have nominated a very different kind of justice. It's remotely possible that the Senate could have refused to confirm, but very doubtful. They managed to hold off confirming Obama's nominee for 8 months, but there's no way they'd have left SCOTUS at eight justices for four years.
, you only have one image for both eyes, not two like you get in a mirror
Depth perception is not based on stereoscopy beyond a couple of dozen feet anyway. And for close up you can just add distance marks, like most backup cameras have.
" If laminar quartz (or fused quartz; note that they're different things) "
Not geologically, they're not. Laminar quartz comes from hydrothermal alteration and fusing of cryptocrystalline mass. It is natural fused quartz.
Fused quartz is a glass, an amorphous fluid structure, meaning that the molecules aren't aligned in any particular way. I believe laminar quartz is a crystal, meaning that the molecules are in a particular pattern. If laminar quartz is not crystalline, then I stand corrected. I can't find any references to indicate what exactly laminar quartz is. Actually, it mostly appears to be a term that fell out of common use about 200 years ago, since all of the Google results that mention it are from early to mid-19th century books.
"But I don't find it being used anywhere. That's a pretty strong indicator that there are some problems with it"
Most fused quartzes are in use in everything else, right down to scientific glassware and dab rig nails. And quartz withstands breaking far better than sapphire. As you increase mohs hardness level, you get more brittle.
I'm not sure whether you're using the technical or the everyday definition of "brittle" here. If you're using the technical term (breaks without significant deformation), then you're correct, of course, but given sapphire's very high strength (in virtually every way), it's not really an issue. If you're using the everyday definition, you're simply wrong. Under most circumstances sapphire will take far more force before breaking than quartz.
You wanna know why it isn't used? Because there's no profit in a nearly-unbreakable screen.
Uh, huh, and automakers have kept the 200 mile per gallon carburetor out of production for the last fifty years, because the oil companies have paid them off.
Hell yes there's profit in a nearly-unbreakable screen. Device makers have no need at all to pad their revenues by making devices that are more breakable than necessary, because there are plenty of other factors that drive quick obsolescence, and there would be huge competitive advantage in being able to tell prospective customers that your screens won't break.
And I didn't say they made quartz screens NOW, I'm saying they should be making and using them.
Color me skeptical. There's a lot of competition in this space, because broken screens are a huge problem. If laminar quartz (or fused quartz; note that they're different things) were the obvious solution you say, it would be available on the market. About the only way that could not be true is if it were more expensive than simply replacing a broken screen, and even then I'd expect to find it used on devices that bill themselves as ultra-tough.
But I don't find it being used anywhere. That's a pretty strong indicator that there are some problems with it. Sapphire (AKA aluminum oxide, AKA transparent aluminum) is harder and more scratch-resistant than quartz, and the thermal expansion issue really doesn't matter for small pieces, so unless quartz is significantly cheaper than sapphire, the latter is a better choice.
But, we don't see sapphire on phones, really, only on watches. Why? Not only is it much more expensive than Gorilla Glass, but as phones get thinner it has another problem, which quartz shares: it doesn't flex, at all. Having an extremely rigid screen means you're going to need to build an extremely rigid body, otherwise the first time someone puts in in their back pocket and sits on it, the screen will break. When the phone is thick a rigid body is easy, but thick phones don't sell -- especially not phones in the upper end of the price range, which is where you'd have to be to add a sapphire or quartz screen to the BoM.
Skyscraper apartment buildings don't "carpet" the land
Haven't traveled much have you? Visit Paris some time.
I lived in Paris for two months, and in aggregate have spent at least another six months there throughout the course of my 50 years of life. I've been to every continent except Antarctica, spent several years living outside the US, and have visited at least three dozen countries.
Imagine what Paris would look like if you tried to put the same number of people in detached homes. You'd have a residential area that extends at least to Orleans and Saint Quentin, nothing but houses. It would be impractical, and unlivable.
But most people don't like telecommuting.
People don't like commuting for hours either.
Many, many people actually prefer that over not having the socialization they get at work. I spent 10 years telecommuting full time for a company (IBM) that pushed everyone out of the offices and into telecommuting. Some of us, like me, loved it. Others -- probably the majority -- hated it and many of them left the company because of that fact.
Guess what else people don't like; they don't like your "lowest-footprint, least-impactful" apartment block hellscapes and living in a glorified bedroom in a tower.
You apparently didn't read my post. I know lots of people who commute for hours *out* of the city because they want that badly to live *in* the city. They could live much closer to work, for less money, but they don't want to. They have the money to live where they want, and where they want to live is in a highrise in San Francisco.
I think they're nuts. They look at my choice (rural Utah) and think I'm nuts. Different strokes.
That's why anywhere that geography and the prevailing laws allow high density urbanity doesn't emerge. Suburbs and exburbs emerge. So when you're dealing in what people do and don't like try to keep that in mind.
Utter nonsense. Suburbs and exurbs are an almost uniquely American thing. Most of the world's population is clustered in cities, and it's not because of zoning laws or geography. Even in the US, 80% of the population lives in urban areas.
If Sheila James and her ilk would like an office somewhere then so be it, but perhaps we could simple not try to pile all those offices into the same few square miles of la-la land.
There are very good reasons why all of the office buildings cluster together. I've seen what happens when you spread them out. As it happens, IBM did that for most of a century and ended up with many such company towns all over the northeast, especially upstate New York and Connecticut. By and large, employees hated them. You can't get a job with the company without moving to the company town, and you can't leave the company without having to move out of the company town. Cities with clusters of businesses are good for both the businesses and the employees. Employees have job mobility, without uprooting and disrupting their lives, and companies have a large labor pool without having to relocate people.
Your way has been tried. It doesn't work well. Telecommuting has been tried. It works for some people and some jobs. By and large, people are going to continue working in cities, either living in them or commuting to them. So we should make it easy for those who want to live in cities to do so by building enough housing, and easy for those who want to commute to do so, by building transit infrastructure.