You "don't want to be saddled with an external battery", but you're okay if the thing snaps into your phone rather than outside it? You're the one who is spouting nonsense.
It's usually technically better if the phone lasts longer on a charge, requiring less day-to-day intervention, at the cost of specialized tools and expertise when the battery finally gets too old for the user's convenience, than to make the whole phone less rigid and need more frequent recharging with an easily swapped battery.
People want a phone that weighs nothing with a battery that lasts forever, that basically disappears when they aren't using it, and fits in their hand(s) just so. If they're lucky, they get the last one. For the others, one person's "compromised basic functionality" is another's perfectly justified trade-off.
Frankly, a phone with a non-removable battery and an external battery that plugs into the charging port is better for almost all cases than a phone with a replaceable battery plus a spare battery.
So you can't read, you can't listen, and you don't pay attention. You don't have to be rude about it.
If most people don't have any idea whether their phone has a removable battery, that's a very strong argument for putting non-removable batteries in most phones. A phone with a non-removable battery plus an external battery that plugs into the phone's charging port is technically superior in just about every way to a phone with two removable batteries. You can easily choose the capacity, use the battery with different models of phone, add a hand crank for emergency recharging, and so forth. The phone will be more rigid. But whether most people think about the battery configuration doesn't change the fact that they can tell which phones are thicker and heavier.
Are "the gadget review press" not people? I didn't say users complained, only that (very visible) people complained.
The guts of a Li-Ion battery need some hard container to protect them from puncture and leakage. This can be the phone's case or a battery case. If the battery is inside a battery case, that adds at least two thicknesses of plastic or other material to the phone's dimensions. (Technically, it could be reduced to a millimeter or two of hard plastic minus some number of microns for the kind of foil-like wrapper that is used for non-replaceable batteries, but those microns are negligible compared to the hard plastic case's thickness.)
Beyond that, a non-replaceable battery is not constrained to be roughly a cuboid, so it is easier to make it larger.
As for your other questions, I'll leave answering them to the people who wrote the text you quoted for them. I don't think I know anyone who replaced a functioning phone within 18 months of purchasing it.
People complained about the bulk and weight of having a removable cover and another layer of hard plastic around the battery. Reporters making comparison charts and designers decided that thin and light were more important than a replaceable battery. OEM upper managers approved when they realized people could be convinced to replace the whole phone instead of replacing just a battery.
A lot of video services adapt the bitstream they send based on available bandwidth. So I would guess that if T-Mobile thinks your TCP connection looks like video, they cap it at some 480p-plausible bit rate.
Fine, the answers are: No, it doesn't give me pause, I don't think it was unfair, it doesn't bother me, etc. Most other tabloids know the law and aren't quite so brazen about breaking it.
I've very seldom met anyone who didn't spend at least some money each month that wasn't necessary to live. Nobody owes you (or Pfhorrest) a nice apartment in a big city. If you want to live in a big city or on a nice island while making minimum wage, get a roommate or three. Either he couldn't live enough within his means to have a rainy-day fund, or he thought his case wasn't worth dipping into that, neither of which tells a lawyer that his case is likely to turn out well.
The algorithm won't be able to tell whether a random person's suit has merit. Suits brought by natural persons are a lot more variable than suits brought by firms in that respect (although some firms, such as those with gold-painted logos saying "You're fired!", are unusually litigious). That's probably also why lawyers wouldn't take the case on contingency: If the client can't provide even basic evidence for their theory, it might take a lot of time to find out whether there's a colorable case at all.
"Digic X" vs "Digic Y" tells you which is newer, and whether Canon thinks the newer one is enough better to deserve a bump in the major version number. You do still need to get other stats to decide whether, for you, the cost delta is worth the performance delta.
If you're going to point to federal court rulings, why use a broken Twitter link?
If a court decides that you did $115M worth of tort damages to someone's career, is it fair that you only pay $25M in punitive damages after crowing about how you will ignore court orders, "joking" that a 5 year old's sex tape would be newsworthy, and generally holding a double standard about leaking sex tapes?
Which serious lapse does this guy want Gawker to get a pass on? Publishing a tape that broke state wiretapping laws, publishing a tape that was stolen by a third party, publishing a tape that was being shopped around as part of a blackmail scheme, or one of the things I mentioned above? Can he count serious lapses when they smack him across the face?
How ignorant of law is this "Trevor Timm", that he thinks having to post a bond before appealing a verdict is unusual or unfair?
I could continue, but I got bored of debunking such shoddy apologetics.
I am not sure what you are objecting to: The idea that customers don't have firmly stated requirements when they sign an outsourcing contract? The idea that good contractors should work with customers to clarify, elaborate, and refine requirements, resolving conflicts between stated requirements when they occur? The idea that contractors shouldn't blame the customer if they don't get a sufficiently complete set of requirements? The idea that an MVP can be deployed to help advance the overall contract's progress?
Conflicting requirements are a different problem than being unable to provide requirements (or articulate them correctly). It's lucky when a customer empowers exactly one person (at least for a given scope) to resolve such conflicts. More often, for the political reasons you mention, the customer wants to have too many cooks, and they spoil the requirements soup.
"The customer('s management) couldn't provide requirements" is the excuse of incompetent contractors out to bleed the client dry. The customer almost never has very clear or necessarily realistic requirements -- if they knew enough to create those, they'd probably be able to do the work in-house. Good contractors need to be good at eliciting requirements, and be able to build a set of requirements that will support at least a minimum viable product.
No, that's the weakness of optimizing your data store for simplicity and then sticking with the choice for decades after people identify scalability problems. The format you choose for storing email is not a "component".
Also, databasing email doesn't break "everything but MTAs". Commonly used MUAs use IMAP or something web-oriented to talk to the mail store, so they never know about the change. You're asking for an MDA change, so of course the MDA will change -- but not break.
Do you have numbers or case studies to support your claim about the "on average" outcome? You're talking about a business model of moving valuable (or even critical) information into a third party's control, where you still have the same number of internal end users, the same operational requirements, the same amount of data stored -- but you now have to control the pipe to and from that service, trust in the vendor's employees, and live with their deployment schedules and glitches.
It's like owning your own car versus relying on public buses. You may feel like you're saving money by taking a bus, but you're more exposed to strangers peeking in, it doesn't cover most of the world, you have no real input on available destinations, and you're at the mercy of a third party to go anywhere at all.
Yeah, I get that you don't like email, but basically the entire stack of brokenness that you are complaining of there derives from the fact that mbox is a terrible format for storing email with concurrent read/write access. It's almost impossible to design a good software stack on top of a fundamentally mistaken architecture.
Your misinterpretation of what I said is the ridiculous thing here. The number of bugs reported doesn't indicate why it's a failure of software design -- the nature of those bugs do. But you'd have to do what I said, and look at several of them to follow the finger-pointing and confusion about root causes, to know what I meant.
The fact that systemd has now centralized and complicated a fragile arrangement does not make it an improvement.
Having robust, testable, easily isolated components is even more important when you have a complex system -- and the way you get those is by defining the one thing that each component should do, and making it do that thing well.
Have you ever tried to debug something that has both complex components and complex interactions, either between the components or with external entities (people or machines)? Very frequently, if the designer decomposed it well, the nature of the failure will make it pretty obvious which part is failing. systemd fails in that department; just look at a few of the thousands of bug reports against it.
Do you even Linux, bro? It was handling hot-swap just fine before systemd came along. You didn't even show that you knew about how distros handled it (without needing arbitrary init scripts or the like) before, and your comment about runlevels suggests that you fundamentally misunderstand them.
The only thing you mentioned that could be improved is handling network changes -- but that's something that applications have to do, based on their own patterns of network usage and how they can recover from a change in transport. systemd can't fix that.
Computers would be so secure if people just didn't try to use them!
It's silly to blame security problems on the fact that people are involved. Developers and admins blame users when those developers and admins can't be bothered to design (or deploy) practices and procedures that address the blind spots and habits that users pick up when they use a system.
Slashdot Mirror
You "don't want to be saddled with an external battery", but you're okay if the thing snaps into your phone rather than outside it? You're the one who is spouting nonsense.
It's usually technically better if the phone lasts longer on a charge, requiring less day-to-day intervention, at the cost of specialized tools and expertise when the battery finally gets too old for the user's convenience, than to make the whole phone less rigid and need more frequent recharging with an easily swapped battery.
People want a phone that weighs nothing with a battery that lasts forever, that basically disappears when they aren't using it, and fits in their hand(s) just so. If they're lucky, they get the last one. For the others, one person's "compromised basic functionality" is another's perfectly justified trade-off.
Frankly, a phone with a non-removable battery and an external battery that plugs into the charging port is better for almost all cases than a phone with a replaceable battery plus a spare battery.
So you can't read, you can't listen, and you don't pay attention. You don't have to be rude about it.
If most people don't have any idea whether their phone has a removable battery, that's a very strong argument for putting non-removable batteries in most phones. A phone with a non-removable battery plus an external battery that plugs into the phone's charging port is technically superior in just about every way to a phone with two removable batteries. You can easily choose the capacity, use the battery with different models of phone, add a hand crank for emergency recharging, and so forth. The phone will be more rigid. But whether most people think about the battery configuration doesn't change the fact that they can tell which phones are thicker and heavier.
2007 called and wants its lame retort back.
But hey, if you've been under a rock since then, maybe you didn't notice that people really were complaining about that.
Are "the gadget review press" not people? I didn't say users complained, only that (very visible) people complained.
The guts of a Li-Ion battery need some hard container to protect them from puncture and leakage. This can be the phone's case or a battery case. If the battery is inside a battery case, that adds at least two thicknesses of plastic or other material to the phone's dimensions. (Technically, it could be reduced to a millimeter or two of hard plastic minus some number of microns for the kind of foil-like wrapper that is used for non-replaceable batteries, but those microns are negligible compared to the hard plastic case's thickness.)
Beyond that, a non-replaceable battery is not constrained to be roughly a cuboid, so it is easier to make it larger.
As for your other questions, I'll leave answering them to the people who wrote the text you quoted for them. I don't think I know anyone who replaced a functioning phone within 18 months of purchasing it.
People complained about the bulk and weight of having a removable cover and another layer of hard plastic around the battery. Reporters making comparison charts and designers decided that thin and light were more important than a replaceable battery. OEM upper managers approved when they realized people could be convinced to replace the whole phone instead of replacing just a battery.
A lot of video services adapt the bitstream they send based on available bandwidth. So I would guess that if T-Mobile thinks your TCP connection looks like video, they cap it at some 480p-plausible bit rate.
Fine, the answers are: No, it doesn't give me pause, I don't think it was unfair, it doesn't bother me, etc. Most other tabloids know the law and aren't quite so brazen about breaking it.
I've very seldom met anyone who didn't spend at least some money each month that wasn't necessary to live. Nobody owes you (or Pfhorrest) a nice apartment in a big city. If you want to live in a big city or on a nice island while making minimum wage, get a roommate or three. Either he couldn't live enough within his means to have a rainy-day fund, or he thought his case wasn't worth dipping into that, neither of which tells a lawyer that his case is likely to turn out well.
You can't manage your own money, so a lawyer should help you figure out if someone in your family couldn't manage it either?
Grow up, stop whining, and stop expecting people to donate a lot of time to help you with a questionable legal theory.
The algorithm won't be able to tell whether a random person's suit has merit. Suits brought by natural persons are a lot more variable than suits brought by firms in that respect (although some firms, such as those with gold-painted logos saying "You're fired!", are unusually litigious). That's probably also why lawyers wouldn't take the case on contingency: If the client can't provide even basic evidence for their theory, it might take a lot of time to find out whether there's a colorable case at all.
"Digic X" vs "Digic Y" tells you which is newer, and whether Canon thinks the newer one is enough better to deserve a bump in the major version number. You do still need to get other stats to decide whether, for you, the cost delta is worth the performance delta.
I have some other questions:
I could continue, but I got bored of debunking such shoddy apologetics.
I am not sure what you are objecting to: The idea that customers don't have firmly stated requirements when they sign an outsourcing contract? The idea that good contractors should work with customers to clarify, elaborate, and refine requirements, resolving conflicts between stated requirements when they occur? The idea that contractors shouldn't blame the customer if they don't get a sufficiently complete set of requirements? The idea that an MVP can be deployed to help advance the overall contract's progress?
Conflicting requirements are a different problem than being unable to provide requirements (or articulate them correctly). It's lucky when a customer empowers exactly one person (at least for a given scope) to resolve such conflicts. More often, for the political reasons you mention, the customer wants to have too many cooks, and they spoil the requirements soup.
"The customer('s management) couldn't provide requirements" is the excuse of incompetent contractors out to bleed the client dry. The customer almost never has very clear or necessarily realistic requirements -- if they knew enough to create those, they'd probably be able to do the work in-house. Good contractors need to be good at eliciting requirements, and be able to build a set of requirements that will support at least a minimum viable product.
No, that's the weakness of optimizing your data store for simplicity and then sticking with the choice for decades after people identify scalability problems. The format you choose for storing email is not a "component".
Also, databasing email doesn't break "everything but MTAs". Commonly used MUAs use IMAP or something web-oriented to talk to the mail store, so they never know about the change. You're asking for an MDA change, so of course the MDA will change -- but not break.
Do you have numbers or case studies to support your claim about the "on average" outcome? You're talking about a business model of moving valuable (or even critical) information into a third party's control, where you still have the same number of internal end users, the same operational requirements, the same amount of data stored -- but you now have to control the pipe to and from that service, trust in the vendor's employees, and live with their deployment schedules and glitches.
It's like owning your own car versus relying on public buses. You may feel like you're saving money by taking a bus, but you're more exposed to strangers peeking in, it doesn't cover most of the world, you have no real input on available destinations, and you're at the mercy of a third party to go anywhere at all.
Yeah, I get that you don't like email, but basically the entire stack of brokenness that you are complaining of there derives from the fact that mbox is a terrible format for storing email with concurrent read/write access. It's almost impossible to design a good software stack on top of a fundamentally mistaken architecture.
I was using the common CS definition of component. The lines are not arbitrary at all.
Your misinterpretation of what I said is the ridiculous thing here. The number of bugs reported doesn't indicate why it's a failure of software design -- the nature of those bugs do. But you'd have to do what I said, and look at several of them to follow the finger-pointing and confusion about root causes, to know what I meant.
The fact that systemd has now centralized and complicated a fragile arrangement does not make it an improvement.
Having robust, testable, easily isolated components is even more important when you have a complex system -- and the way you get those is by defining the one thing that each component should do, and making it do that thing well.
Have you ever tried to debug something that has both complex components and complex interactions, either between the components or with external entities (people or machines)? Very frequently, if the designer decomposed it well, the nature of the failure will make it pretty obvious which part is failing. systemd fails in that department; just look at a few of the thousands of bug reports against it.
Do you even Linux, bro? It was handling hot-swap just fine before systemd came along. You didn't even show that you knew about how distros handled it (without needing arbitrary init scripts or the like) before, and your comment about runlevels suggests that you fundamentally misunderstand them.
The only thing you mentioned that could be improved is handling network changes -- but that's something that applications have to do, based on their own patterns of network usage and how they can recover from a change in transport. systemd can't fix that.
Outsourcing security ("as a service") seldom works out well in the end.
Sounds like system's co-dependency logic to me: It can't do anything by itself, and it won't let you do anything without it.
x86_64-systemd-linux-gnu, HTH, HAND.
Computers would be so secure if people just didn't try to use them!
It's silly to blame security problems on the fact that people are involved. Developers and admins blame users when those developers and admins can't be bothered to design (or deploy) practices and procedures that address the blind spots and habits that users pick up when they use a system.