These are LiPo batteries we're talking about. AFAIK, they're always a single cell, and I don't think they typically contain any circuitry. If they did, they'd have a four-wire connector like lithium ion packs, rather than two. (Or at least all the flat packs I've seen only have the two wires.)
No, according to the CIA's website, they also accept FOIA requests by snail mail. AFAIK, this has always been the case. However, the only electronic way to submit a FOIA request is by fax (still), AFAIK.
Dendrites are usually caused by overcharging, which as you previously mentioned, would indicate either a charge circuit design flaw (e.g. too high a charge voltage) or a hardware/firmware bug that causes the charger to stay in rapid charge mode for too long. But the GP is also correct in saying that rapid charging makes it more challenging to choose the proper temperature cutoffs to prevent thermal runaway.
That first interview is what I've always informally called a "bozo screen". They mainly exist to keep from wasting a bunch of interviewers' time on somebody who has no prayer of getting hired.
This is where it helps to know somebody at the company where you want to work who will vouch for you. Most companies will skip the phone screen if you have good internal recommendations.
The people making the hiring decisions don't see you or your résumé. They just see the comments from the randomly selected interviewers. If you passed that test (answering the questions and being able to explain/defend your answers without coming across as an arrogant jerk), I don't see how an age-related bias could even be possible.
There could, however, be some sort of accidental systemic bias in the nature of the questions themselves. If so, that's worth investigating and fixing.
Exactly. If you watch enough TV that those 4K streams from Netflix put you over the cap, they'd rather you spend $50 on a cable TV subscription than $50 a month for more data, because additional cable customers give them better negotiating power when it comes time to renegotiate their contracts with the networks.
None. The purpose of caps from cable companies isn't to cover the costs of infrastructure improvements. It is to serve as a disincentive to dropping cable TV service, just as it always was.
I can't possibly have faith in that. It's entirely too easy to throw money at someone and get them to pay a few cents each to a thousand random people to install an app and rate it. The only way to actually get high-quality reviews is to use an Amazon-like system where folks can moderate the reviews. And even that isn't perfect. It requires lots of fairly advanced machine learning to determine whether upvotes and downvotes are legitimate, because some people knee-jerk downvote negative reviews without taking the time to learn from them, often doing so preferentially for specific products, which usually means that they're biased for one reason or another, and their votes shouldn't matter much.
For example, there are a couple of good reviews that I've written on Amazon pointing out glaringly obvious design flaws in hardware that I didn't end up buying because of those flaws, and a bunch of trolls downvoted them demanding how I can fairly review a product that I didn't buy, which tells me that they probably worked for the manufacturer. (After all, the flaws were glaringly obvious after spending less than ten seconds with the hardware in question in a brick-and-mortar store; why would I buy a defective-by-design product just to prove that it was designed wrong?)
Has anybody tried to use Apple's new developer documentation website?
Every enumerated constant on a separate page
Breadcrumbs that don't take you back to the list of constants
Search that frequently takes you to those single-item pages instead of to the overarching page
Automatically changing back to Swift mode on every single click that causes a page change
No way to usefully search for keywords within an API reference unless it falls within the first paragraph of content for a given symbol (because they're spread across fifty different web pages instead of one)
And those were just the first few P1 showstoppers that I noticed. This site should never have gone live even for WWDC, much less for non-beta content. It just isn't anywhere *near* ready.
I'm not sure what the Dash app does or how it works, and I'm not sure if it actually improves things in those areas, but between their main developer doc site train wreck and this story, it really feels like Apple has become actively antagonistic towards developers. What the heck is going on over there in Cupertino?
SU was in my original comment that you replied to when you incorrectly claimed that there was an option to install SUs without installing major updates.
Well, by that standard, it's also the fault of Apple's VP team for not making him undead. (Insert obligatory comment about sacrificing engineers here.)
I'm suddenly imagining their VP team chanting, "Theena eesa betta" over and over.
Optical glass is almost invariably coated—usually on both sides—to reduce reflections between lens elements that can cause lens flare, and to reduce reflections between the outside element and any filters (or external zoom/wide-angle converters) that folks might stick on the front of the lens. The lens can be as hard as you want; if the coating isn't equally hard (which it won't be), then the hardness of the glass itself is meaningless marketing drivel.
This is why real camera makers provide lens hoods and lens caps—so that the lens won't be exposed unnecessarily, reducing the risk of it getting scratched. Unfortunately, the iPhone is designed wrong (too thin), resulting in a highly exposed camera lens with no protection—no cap, no hood.
IMO, Apple's engineers need to stop kidding themselves by pretending that users care more about thin than about reliability. They need to use some actual courage and buck the trend, making their phone thicker, with a bigger battery and a properly recessed lens.
On the other hand, if all the cars are autonomous, it won't matter if somebody gets that wrong, because all the cars will be driving the wrong way. So the only thing that makes it dangerous, even when the data is wrong, are the meatbags behind the wheels of the other vehicles.
SU stands for software update, not security update, and refers to point release updates, e.g. 10.12 -> 10.12.1. They almost certainly aren't included in that bucket, or if they are, then it is very poorly named.
That's certainly true. But the point was that you as a programmer are better equipped to find bugs in your own code than in its dependencies, and that the runtime is basically a giant black box to most programmers, whereas libraries are more likely to get compiled from source (though not necessarily, of course).
I did that the first several times. At some point, I realized that if I kept doing their jobs for them, they would keep mis-delivering them, so the only way to keep from becoming their errand boy was to make them come back over and pick up the packages that they incorrectly left. The number of mis-deliveries has dropped significantly as a result.
But that's one specific example, and hardly the only reason C is broken. Just look at the number of potential problems hiding in the way it handles numerical data: implicit conversions, silent truncation, exact comparisons of floating point values, etc.
Much of the above abuse would get flagged by -Wconversion. Trying to compare floating-point numbers to a constant certainly won't work reliably, but it also isn't likely to cause problems in real-world code, because the code would have to have actually worked at least once....:-)
Look at the totally unnecessary potential problems in how pointers are used.
Good luck writing device driver code without them, though. And there are lots of other things that are much easier to write and faster when written in C (e.g. ring buffers) because pointers are so thoroughly exposed. Would we be better off if C had zeroing weak references? Probably. Would they be the right solution for every situation? Definitely not. Can you implement some close approximation of ZWR on top of C if you need them? Yeah, pretty easily. It's just a doubly-reference-counted handle (double pointer).
Look at the number of holes in the type system, even in everyday things like using enumerations.
True, but also true of most other languages in different ways. Most modern languages either aren't much more strongly typed than C. And many have almost no static type checking, but are strongly typed at runtime, greatly increasing the risk of nasty surprises when compared with C. All in all, it isn't perfect, but it isn't *that* bad.:-)
Look at the limitations of the memory model in the presence of modern hardware interactions, concurrency, and so on.
On the other hand, the more complex memory models don't come for free. They all involve additional overhead. The exact amount depends on the technology, of course. And they all seem to "just work" until the moment that they don't, at which point debugging can become nightmarish. Compared with that, the explicit malloc and free actually seems pretty sane. It forces people to define a concept of ownership that makes sense in their code base, and to know when it is appropriate to throw away memory, and to clean up after themselves explicitly. And when that cleanup is done, you know that the data in question absolutely isn't using memory unexpectedly.
Why would you ever want to turn off point releases, though? Those are all small patches, and almost never make major changes to the user experience or severely break your apps. Automatically downloading a major release is a completely different matter....
The problem is that this granularity still isn't sufficient. There's a big difference between downloading a SU and downloading a major OS release. Most people do want to automatically download minor SUs that are typically binary diffs against the previous release (i.e. tens of megabytes). Lots of folks do not want to automatically download major OS releases that are measured in gigabytes.
Slashdot Mirror
These are LiPo batteries we're talking about. AFAIK, they're always a single cell, and I don't think they typically contain any circuitry. If they did, they'd have a four-wire connector like lithium ion packs, rather than two. (Or at least all the flat packs I've seen only have the two wires.)
No, according to the CIA's website, they also accept FOIA requests by snail mail. AFAIK, this has always been the case. However, the only electronic way to submit a FOIA request is by fax (still), AFAIK.
Dendrites are usually caused by overcharging, which as you previously mentioned, would indicate either a charge circuit design flaw (e.g. too high a charge voltage) or a hardware/firmware bug that causes the charger to stay in rapid charge mode for too long. But the GP is also correct in saying that rapid charging makes it more challenging to choose the proper temperature cutoffs to prevent thermal runaway.
One of my former coworkers used to call it "building a monument to yourself".
That first interview is what I've always informally called a "bozo screen". They mainly exist to keep from wasting a bunch of interviewers' time on somebody who has no prayer of getting hired.
This is where it helps to know somebody at the company where you want to work who will vouch for you. Most companies will skip the phone screen if you have good internal recommendations.
The people making the hiring decisions don't see you or your résumé. They just see the comments from the randomly selected interviewers. If you passed that test (answering the questions and being able to explain/defend your answers without coming across as an arrogant jerk), I don't see how an age-related bias could even be possible.
There could, however, be some sort of accidental systemic bias in the nature of the questions themselves. If so, that's worth investigating and fixing.
Maybe you missed the mobile device revolution, but keeping memory and CPU usage within sane bounds matters an awful lot these days.
And quality. Any employer that isn't concerned about that really isn't working for.
Exactly. If you watch enough TV that those 4K streams from Netflix put you over the cap, they'd rather you spend $50 on a cable TV subscription than $50 a month for more data, because additional cable customers give them better negotiating power when it comes time to renegotiate their contracts with the networks.
None. The purpose of caps from cable companies isn't to cover the costs of infrastructure improvements. It is to serve as a disincentive to dropping cable TV service, just as it always was.
I can't possibly have faith in that. It's entirely too easy to throw money at someone and get them to pay a few cents each to a thousand random people to install an app and rate it. The only way to actually get high-quality reviews is to use an Amazon-like system where folks can moderate the reviews. And even that isn't perfect. It requires lots of fairly advanced machine learning to determine whether upvotes and downvotes are legitimate, because some people knee-jerk downvote negative reviews without taking the time to learn from them, often doing so preferentially for specific products, which usually means that they're biased for one reason or another, and their votes shouldn't matter much.
For example, there are a couple of good reviews that I've written on Amazon pointing out glaringly obvious design flaws in hardware that I didn't end up buying because of those flaws, and a bunch of trolls downvoted them demanding how I can fairly review a product that I didn't buy, which tells me that they probably worked for the manufacturer. (After all, the flaws were glaringly obvious after spending less than ten seconds with the hardware in question in a brick-and-mortar store; why would I buy a defective-by-design product just to prove that it was designed wrong?)
With my cynic hat on, I have the sudden urge to start a betting pool on how many months it will be before Apple releases an offline doc viewer app.
Has anybody tried to use Apple's new developer documentation website?
And those were just the first few P1 showstoppers that I noticed. This site should never have gone live even for WWDC, much less for non-beta content. It just isn't anywhere *near* ready.
I'm not sure what the Dash app does or how it works, and I'm not sure if it actually improves things in those areas, but between their main developer doc site train wreck and this story, it really feels like Apple has become actively antagonistic towards developers. What the heck is going on over there in Cupertino?
With a little bit of luck, one company will get its data from a British company and all the roads will be going the wrong way.
SU was in my original comment that you replied to when you incorrectly claimed that there was an option to install SUs without installing major updates.
Well, by that standard, it's also the fault of Apple's VP team for not making him undead. (Insert obligatory comment about sacrificing engineers here.)
I'm suddenly imagining their VP team chanting, "Theena eesa betta" over and over.
Optical glass is almost invariably coated—usually on both sides—to reduce reflections between lens elements that can cause lens flare, and to reduce reflections between the outside element and any filters (or external zoom/wide-angle converters) that folks might stick on the front of the lens. The lens can be as hard as you want; if the coating isn't equally hard (which it won't be), then the hardness of the glass itself is meaningless marketing drivel.
This is why real camera makers provide lens hoods and lens caps—so that the lens won't be exposed unnecessarily, reducing the risk of it getting scratched. Unfortunately, the iPhone is designed wrong (too thin), resulting in a highly exposed camera lens with no protection—no cap, no hood.
IMO, Apple's engineers need to stop kidding themselves by pretending that users care more about thin than about reliability. They need to use some actual courage and buck the trend, making their phone thicker, with a bigger battery and a properly recessed lens.
On the other hand, if all the cars are autonomous, it won't matter if somebody gets that wrong, because all the cars will be driving the wrong way. So the only thing that makes it dangerous, even when the data is wrong, are the meatbags behind the wheels of the other vehicles.
I noticed. It explains why I didn't get my usual daily wakeup call from that a**hole scammer robocalling me and pretending to be the IRS....
SU stands for software update, not security update, and refers to point release updates, e.g. 10.12 -> 10.12.1. They almost certainly aren't included in that bucket, or if they are, then it is very poorly named.
That's certainly true. But the point was that you as a programmer are better equipped to find bugs in your own code than in its dependencies, and that the runtime is basically a giant black box to most programmers, whereas libraries are more likely to get compiled from source (though not necessarily, of course).
I did that the first several times. At some point, I realized that if I kept doing their jobs for them, they would keep mis-delivering them, so the only way to keep from becoming their errand boy was to make them come back over and pick up the packages that they incorrectly left. The number of mis-deliveries has dropped significantly as a result.
Much of the above abuse would get flagged by -Wconversion. Trying to compare floating-point numbers to a constant certainly won't work reliably, but it also isn't likely to cause problems in real-world code, because the code would have to have actually worked at least once.... :-)
Good luck writing device driver code without them, though. And there are lots of other things that are much easier to write and faster when written in C (e.g. ring buffers) because pointers are so thoroughly exposed. Would we be better off if C had zeroing weak references? Probably. Would they be the right solution for every situation? Definitely not. Can you implement some close approximation of ZWR on top of C if you need them? Yeah, pretty easily. It's just a doubly-reference-counted handle (double pointer).
True, but also true of most other languages in different ways. Most modern languages either aren't much more strongly typed than C. And many have almost no static type checking, but are strongly typed at runtime, greatly increasing the risk of nasty surprises when compared with C. All in all, it isn't perfect, but it isn't *that* bad. :-)
On the other hand, the more complex memory models don't come for free. They all involve additional overhead. The exact amount depends on the technology, of course. And they all seem to "just work" until the moment that they don't, at which point debugging can become nightmarish. Compared with that, the explicit malloc and free actually seems pretty sane. It forces people to define a concept of ownership that makes sense in their code base, and to know when it is appropriate to throw away memory, and to clean up after themselves explicitly. And when that cleanup is done, you know that the data in question absolutely isn't using memory unexpectedly.
Why would you ever want to turn off point releases, though? Those are all small patches, and almost never make major changes to the user experience or severely break your apps. Automatically downloading a major release is a completely different matter....
The problem is that this granularity still isn't sufficient. There's a big difference between downloading a SU and downloading a major OS release. Most people do want to automatically download minor SUs that are typically binary diffs against the previous release (i.e. tens of megabytes). Lots of folks do not want to automatically download major OS releases that are measured in gigabytes.